在Linux中,隧道的实现主要基于两个文件new_tunnel.c和ipip.c
同时Linux定义了一种新的协议类型--IPIP(IPPROTO_IPIP),与上面所说封包类型类似。
基本思路
在Linux中IP Tunnel的实现也分为两个部件:封装部件和解封部件,分别司职发送和接收。但这两个部分是在不同的层次以不同的方式实现的。封装部件是在数据链路层以虚设备的方式实现。所有源代码见
/usr/src/linux/drivers/net/new_tunnel.c
为实现封装,Linux实现一个称为tunl的网络设备(类似loopback设备),此设备具有其他网络设备共有的特征,对于使用此设备的上层应用来说,对这些网络设备不加区分,调用及处理方法当然也完全一样。
tunnel_init()和tunnel_xmit()是new_tunnel.c中的两个主要过程。
tunnel_init()初始化与设备tunl相关的device结构。
而tunnel_xmit()在从tunl设备发送数据时被调用,tunl设备作为实现IP隧道技术的封装部分,在此过程中完成对相应的数据报进行封装所需的全部操作,形成IPIP类型的IP包,并重新转发此数据包(ip_forward())。
解码器在IP的上层实现,系统把它作为一个虚的传输层(实际上与传输层毫无关系),具体处理见文件
/usr/src/linux/net/ipv4/ipip.c。
我们知道,每一个IP数据包均交由ip_rcv函数处理,在进行一些必要的判断后,ip_rcv对于发送给本机的数据包将交给上层处理程序。对于IPIP包来说,其处理函数是ipip_rcv(就如TCP包的处理函数是tcp_rcv一样,IP层不加区分)。也就是说,当一个目的地址为本机的封包到达后,ip_rcv函数进行一些基本检查并除去IP头,然后交由ipip_rcv解封。ipip_rcv所做的工作就是去掉封包头,还原数据包,然后把还原后的数据包放入相应的接收队列(netif_rx())。
从以上IP Tunnel实现的思想来看,思路十分清晰,但由于IP Tunnel的特殊性,其实现的层次并不单纯。实际上,它的封装和解封部件不能简单地象上面所说的那样分层。tunl设备虽应算进链路层,但其发送程序中做了更多的工作,如制作IPIP头及新的IP头(这些一般认为是传输层或网络层的工作),调用ip_forward转发新包也不是一个网络设备应当做的事。可以说,tunl借网络设备之名,一把抓干了不少工作,真是‘高效’。而解封部件宏观上看在网络层之上,解出IPIP头,恢复原数据包是它分内的事,但在它解出数据包(即原完整的协议数据包)后,它把这个包放入相应的协议接收队列。这种事可不是一个上层协议干的,这是网络设备中断接收程序的义务。看到了,在这点上,它好象到了数据链路层。
三、为实现VPN的扩展
实际上Linux只为实现隧道机制提供了一个框架,图二中的封包协议头在Linux中被忽略了,也就是说,封包头只含封包IP头,其后紧跟原IP数据包。这样的结构用于传输公开数据没有关系,但对于一个VPN来说,安全保密是不可缺少的重要功能。我们希望通过隧道的数据可靠且不可窃取和冒充的,那么,加密和认证就必不可少。为实现这一构想,设计以下封包协议头:
0 4 8 16 24 31
+-----+-----+-----------+------------------------+
| ver |type | hlen | OldPacketLen |
+-----------------------+------------------------+
| DeviceID | EncapID |
+-----------------------+------------------------+
| Flags | CheckSum |
+------------------------------------------------+
| IPIP Options( If any ) |
+------------------------------------------------+
. | padding |
. .
+------------------------------------------------+
图三、 IPIP头设想图
ver: 版本号,利于扩展
type: 用于建立不同目的的隧道(可能处理上有差别)
OldPacketLen: 进入隧道的原数据包长度
DeviceID: 对数据包进行封装的设备标识
EncapID: 此封包的ID号
Flags: 标志位,共16位,初步定义如下:
0 保留
1 有否加密
2 有否做摘要
3 有否签名
4 保留
5 有否传送消息密钥
6 消息密钥有否加密
7 消息密钥是否需保留
8-15 保留
CheckSum: 头校验
IPIP Options: 用来传送一些必要的数据,比如消息密钥、签名等
格式:
+-------------------------------------+
| 类型 | 长度 | 数据 ... |
+-------------------------------------+
好了,有了这个东西,我们就可以扩展Linux IP Tunnel为我们的VPN服务了。首先,改写new_tunnel.c和ipip.c两个文件,加入对IPIP头的处理。
接着,我们要实现一种密钥的管理和传送机制。
当然,对称密钥是必需的,而对IP数据包加密要使用序列密码。从全体考虑,
我们可以提出建立VPN的逻辑步骤;
1、准备工作:建网安装系统完成配置等等
2、隧道的两端分别向对方发送自己的公开密码和设备号
3、如有必要,产生序列密码,后加密签名传给对方
4、正常通信,----放心,你的数据已经很保险了。
在一个VPN的隧道中,一个封包的格式应如图四所示。
/ +-----------------+
| | 封包IP头 |
封包头 | +-----------------+
| | 封包协议头 |
+-----------------+
/ | |
| | 原协议头 |
| | 及 |
封包数据 | | 原协议数据 |
| . (密文) .
| . .
| | |
+-----------------+
图四. VPN封包结构
你的几种使用方法
事情往往不能两全其美,你在安全强度和通信速度上必须作出选择,(不然你就需要在安全强度和Money的耗费中做选择。)使用这样的协议,根据你的需求不同,你可有不同的使用方法,下面列举一些:
跨Internet的公司多个内部网之间进行通信,保密性并不重要直接使用原框架机制,无任何加密措施这样速度快、效率高,公司也不用申请多个IP地址,方便可行
一般性的商业应用,具有保密要求利用事先产生的序列密码,每次对原数据包加密安全度提高了,是一种十分实用的方法。只要强度足够,一般很难破译速度快
密码不变的方式你认为不够安全你可以自己实现一种密码传送方法,每隔一段时间更换一次密码。其中一些握手关系需要完善,有兴趣的欢迎探讨。如果发展成熟,此法相信很有前途。
高度机密领域:敬请使用一次一密,并进行每次签名。每次产生新密钥和签名十分费时,在目前我国Internet网络的速度下几乎不可行。但相信有此需要的部门也能够设法提高其网络带宽,让网络状况适合这种应用。另外,当然还可以就加密强度自身作出选择,比如选择128位,还是512位、1024位
四、待完善
主要牵涉到隧道的管理,在封包的传送过程中如果出现错误是十分正常的,当一台路由器检测到错误时,它会发送一个ICMP包给隧道的发送端,但遗憾的是ICMP返回的数据除了IP头外,只含8个字节的上层协议信息。只凭这个难以对ICMP信息作出反应,因此,在隧道端保留一些状态信息是必须的。这些信息主要包括:
隧道的另一端的可达性
隧道的拥塞状况
隧道的MTU
同时所发送的封包信息也是需要保留的,举例说,当一个路由不可达信息到来时,封包的发送者要能够找出所封装的数据来自何方,并发送相应的ICMP包。
同时Linux定义了一种新的协议类型--IPIP(IPPROTO_IPIP),与上面所说封包类型类似。
基本思路
在Linux中IP Tunnel的实现也分为两个部件:封装部件和解封部件,分别司职发送和接收。但这两个部分是在不同的层次以不同的方式实现的。封装部件是在数据链路层以虚设备的方式实现。所有源代码见
/usr/src/linux/drivers/net/new_tunnel.c
为实现封装,Linux实现一个称为tunl的网络设备(类似loopback设备),此设备具有其他网络设备共有的特征,对于使用此设备的上层应用来说,对这些网络设备不加区分,调用及处理方法当然也完全一样。
tunnel_init()和tunnel_xmit()是new_tunnel.c中的两个主要过程。
tunnel_init()初始化与设备tunl相关的device结构。
而tunnel_xmit()在从tunl设备发送数据时被调用,tunl设备作为实现IP隧道技术的封装部分,在此过程中完成对相应的数据报进行封装所需的全部操作,形成IPIP类型的IP包,并重新转发此数据包(ip_forward())。
解码器在IP的上层实现,系统把它作为一个虚的传输层(实际上与传输层毫无关系),具体处理见文件
/usr/src/linux/net/ipv4/ipip.c。
我们知道,每一个IP数据包均交由ip_rcv函数处理,在进行一些必要的判断后,ip_rcv对于发送给本机的数据包将交给上层处理程序。对于IPIP包来说,其处理函数是ipip_rcv(就如TCP包的处理函数是tcp_rcv一样,IP层不加区分)。也就是说,当一个目的地址为本机的封包到达后,ip_rcv函数进行一些基本检查并除去IP头,然后交由ipip_rcv解封。ipip_rcv所做的工作就是去掉封包头,还原数据包,然后把还原后的数据包放入相应的接收队列(netif_rx())。
从以上IP Tunnel实现的思想来看,思路十分清晰,但由于IP Tunnel的特殊性,其实现的层次并不单纯。实际上,它的封装和解封部件不能简单地象上面所说的那样分层。tunl设备虽应算进链路层,但其发送程序中做了更多的工作,如制作IPIP头及新的IP头(这些一般认为是传输层或网络层的工作),调用ip_forward转发新包也不是一个网络设备应当做的事。可以说,tunl借网络设备之名,一把抓干了不少工作,真是‘高效’。而解封部件宏观上看在网络层之上,解出IPIP头,恢复原数据包是它分内的事,但在它解出数据包(即原完整的协议数据包)后,它把这个包放入相应的协议接收队列。这种事可不是一个上层协议干的,这是网络设备中断接收程序的义务。看到了,在这点上,它好象到了数据链路层。
三、为实现VPN的扩展
实际上Linux只为实现隧道机制提供了一个框架,图二中的封包协议头在Linux中被忽略了,也就是说,封包头只含封包IP头,其后紧跟原IP数据包。这样的结构用于传输公开数据没有关系,但对于一个VPN来说,安全保密是不可缺少的重要功能。我们希望通过隧道的数据可靠且不可窃取和冒充的,那么,加密和认证就必不可少。为实现这一构想,设计以下封包协议头:
0 4 8 16 24 31
+-----+-----+-----------+------------------------+
| ver |type | hlen | OldPacketLen |
+-----------------------+------------------------+
| DeviceID | EncapID |
+-----------------------+------------------------+
| Flags | CheckSum |
+------------------------------------------------+
| IPIP Options( If any ) |
+------------------------------------------------+
. | padding |
. .
+------------------------------------------------+
图三、 IPIP头设想图
ver: 版本号,利于扩展
type: 用于建立不同目的的隧道(可能处理上有差别)
OldPacketLen: 进入隧道的原数据包长度
DeviceID: 对数据包进行封装的设备标识
EncapID: 此封包的ID号
Flags: 标志位,共16位,初步定义如下:
0 保留
1 有否加密
2 有否做摘要
3 有否签名
4 保留
5 有否传送消息密钥
6 消息密钥有否加密
7 消息密钥是否需保留
8-15 保留
CheckSum: 头校验
IPIP Options: 用来传送一些必要的数据,比如消息密钥、签名等
格式:
+-------------------------------------+
| 类型 | 长度 | 数据 ... |
+-------------------------------------+
好了,有了这个东西,我们就可以扩展Linux IP Tunnel为我们的VPN服务了。首先,改写new_tunnel.c和ipip.c两个文件,加入对IPIP头的处理。
接着,我们要实现一种密钥的管理和传送机制。
当然,对称密钥是必需的,而对IP数据包加密要使用序列密码。从全体考虑,
我们可以提出建立VPN的逻辑步骤;
1、准备工作:建网安装系统完成配置等等
2、隧道的两端分别向对方发送自己的公开密码和设备号
3、如有必要,产生序列密码,后加密签名传给对方
4、正常通信,----放心,你的数据已经很保险了。
在一个VPN的隧道中,一个封包的格式应如图四所示。
/ +-----------------+
| | 封包IP头 |
封包头 | +-----------------+
| | 封包协议头 |
+-----------------+
/ | |
| | 原协议头 |
| | 及 |
封包数据 | | 原协议数据 |
| . (密文) .
| . .
| | |
+-----------------+
图四. VPN封包结构
你的几种使用方法
事情往往不能两全其美,你在安全强度和通信速度上必须作出选择,(不然你就需要在安全强度和Money的耗费中做选择。)使用这样的协议,根据你的需求不同,你可有不同的使用方法,下面列举一些:
跨Internet的公司多个内部网之间进行通信,保密性并不重要直接使用原框架机制,无任何加密措施这样速度快、效率高,公司也不用申请多个IP地址,方便可行
一般性的商业应用,具有保密要求利用事先产生的序列密码,每次对原数据包加密安全度提高了,是一种十分实用的方法。只要强度足够,一般很难破译速度快
密码不变的方式你认为不够安全你可以自己实现一种密码传送方法,每隔一段时间更换一次密码。其中一些握手关系需要完善,有兴趣的欢迎探讨。如果发展成熟,此法相信很有前途。
高度机密领域:敬请使用一次一密,并进行每次签名。每次产生新密钥和签名十分费时,在目前我国Internet网络的速度下几乎不可行。但相信有此需要的部门也能够设法提高其网络带宽,让网络状况适合这种应用。另外,当然还可以就加密强度自身作出选择,比如选择128位,还是512位、1024位
四、待完善
主要牵涉到隧道的管理,在封包的传送过程中如果出现错误是十分正常的,当一台路由器检测到错误时,它会发送一个ICMP包给隧道的发送端,但遗憾的是ICMP返回的数据除了IP头外,只含8个字节的上层协议信息。只凭这个难以对ICMP信息作出反应,因此,在隧道端保留一些状态信息是必须的。这些信息主要包括:
隧道的另一端的可达性
隧道的拥塞状况
隧道的MTU
同时所发送的封包信息也是需要保留的,举例说,当一个路由不可达信息到来时,封包的发送者要能够找出所封装的数据来自何方,并发送相应的ICMP包。