荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: georgehill (佐治·希尔【多情网虫无情网】), 信区: Linux
标 题: Linux中IP隧道的分析与建议
发信站: BBS 荔园晨风站 (Sat Mar 11 19:59:16 2000), 转信
资料整理·中国程序员网站
Linux中IP隧道的分析与建议
作者信箱: xiaoman04@hotmail.com
O、由于网络的日益普及，网络的安全成为目前的热门话题。本文对隧道技术的分析，
就侧重安全领域，对利用隧道技术实现虚拟专网提出建议。
为什么需要IP隧道？没有接触过这个概念的人自然提出这样的疑问。实际上概念最初
的提出很简单，为了在TCP/IP网络中传输其他协议的数据包。设想IPX协议或X.25封装
的数据包如何通过Internet网进行传输，在已经使用多年的桥接技术中是通过在源协
议数据包上再套上一个IP协议头来实现，形成的IP数据包通过Internet后卸去IP头，
还原成源协议数据包，传送给目的站点。对源协议数据来说，就如被IP带着过了一条
隧道。这种技术在业余无线网络（Amateur Packet Radio network，应该怎么翻，请
告诉我）得到了最广泛的应用。利用IP隧道来传送的协议包也包括IP数据包，本文主
要分析的IPIP封包就是如此，从字面来理解IPIP就对了，就是把一个IP数据包又套在
一个IP包里。为什么要这么做呢？多此一举嘛。其实不然，见过一些应用就会明白，
移动IP（Mobile-IP）和IP多点广播（IP-Multicast）是两个通常的例子。目前，IP隧
道技术在构筑虚拟专网（ Virtual Private Network）中也显示出极大的魅力。本文
也将对利用IP隧道技术构筑VPN做简单设想。
背景：隧道的多种理解和实现
Internet的研究者多年前就感到需要在网络中建立隧道，最初的理解是在网络中建立
一条固定的路径，以绕过一些可能失效的网关。可以说，隧道就是一条特定的路径。
这样的隧道是通过IP报头中的源路由选项来实现的，在目前看来，这个方法的缺陷十
分明显。要设置源路由选项就必须知道数据包要经过的确切路径，而且目前多数路由
实现中都不支持源路由。
另一个实现隧道的机制是开发一种新的IP选项，用来表明源数据包的信息，原IP头可
能成为此选项的一部分。这种隧道的意义与我们所说的隧道已十分接近。但它的不足
在于要对目前IP选项的实现和处理做较大的修改，也缺乏灵活性。
最后常用的一种实现方法是开发一种新的IP封包协议，仍然套用当前的IP头格式。通
过IP封包，不须指明网络路径，封包就能透明地到达目的地。也可以通过封包空间把
未直接连接的机器绑在一起，从而创建虚拟网络。这种方法易行、可靠、可扩展性强
，Linux采用了这一方法，这也是目前我们所理解的隧道思想。
一、封包协议的结构和实现
封包协议的实现原理十分简单。先看看通过隧道传送的数据报在网络中如何流动，如
图一。为了叙述简便，我把在隧道中传送的IP数据包称为封包。
-------------- -----------
/ 子网A \ / 子网C \
/ \ / \
| | | |
| & | | |
| + +++++ | | ***** |
| +++++ + | | * * |
| + | | ***** * |
\ + / ----------- \ * * / ----------
\ ++> # * **>(#) * ***> # ++++ \
-------------- / * * \ ------------ / + \
| * * | | + |
| * * | | + |
| ***** * | | +++++++ |
| ***** | | V |
| | | & |
\ / \ /
\ 子网B / \ 子网D /
----------- ----------
++++++ 原数据报
****** 封装后的数据包（封包）
# 封装/解封
& 用户主机
图一. 封包协议实现模型
看图中的设备 #，分别处于隧道的两端，分别起打包（封装）和解包（解封）的作用，
在整个数据包的传送路径中，除了隧道两端的 # 设备，其他网关把数据包看成一个普
通的IP包进行转发。设备 # 就是一个封包基于的两个实现部件--封装部件和解封部件。
封装和解封部件（设备）都应当同时属于两个子网。封装部件对接收到的数据报加上
封包头，然后以解封部件地址作为目的地址转发出去；而解封部件则在收到封包后，
还原原数据报，转发到目的子网。
隧道的源端（封装部件）对进入隧道的数据包进行封装，形成封包。一个完整的封包
如图二所示。
/ +-----------------+
| | 封包IP头 |
封包头 | +-----------------+
| | 封包协议头 |
\ +-----------------+
/ | 原协议头 |
| +-----------------+
| | |
原数据报 | | 原协议数据 |
| . .
| . .
| | |
\ +-----------------+
图二. 封包结构
二、Linux中的实现
本人分析的版本是Linux2.0.34（RedHat5.2采用）。
在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的耗费中做选择。）
使用这样的协议，根据你的需求不同，你可有不同的使用方法，下面列举一些：
0、跨Internet的公司多个内部网之间进行通信，保密性并不重要
直接使用原框架机制，无任何加密措施
这样速度快、效率高，公司也不用申请多个IP地址，方便可行
1、一般性的商业应用，具有保密要求
利用事先产生的序列密码，每次对原数据包加密
安全度提高了，是一种十分实用的方法。只要强度足够，一般很难破译
速度快
2、密码不变的方式你认为不够安全
你可以自己实现一种密码传送方法，每隔一段时间更换一次密码。
其中一些握手关系需要完善，有兴趣的欢迎探讨。
如果发展成熟，此法相信很有前途。
4、高度机密领域
敬请使用一次一密，并进行每次签名。
每次产生新密钥和签名十分费时，在目前我国Internet网络的速度下
几乎不可行。
但相信有此需要的部门也能够设法提高其网络带宽，让网络状况适合
这种应用。
另外，当然还可以就加密强度自身作出选择，比如选择128位，还是512位、1024位
四、待完善
主要牵涉到隧道的管理，在封包的传送过程中如果出现错误是十分正常的，当一台路
由器检测到错误时，它会发送一个ICMP包给隧道的发送端，但遗憾的是ICMP返回的数
据除了IP头外，只含8个字节的上层协议信息。只凭这个难以对ICMP信息作出反应，
因此，在隧道端保留一些状态信息是必须的。这些信息主要包括：
隧道的另一端的可达性
隧道的拥塞状况
隧道的MTU
同时所发送的封包信息也是需要保留的，举例说，当一个路由不可达信息到来时，封
包的发送者要能够找出所封装的数据来自何方，并发送相应的ICMP包。
强调一点，MTU的更新对隧道来将很重要，因为一个灵活的隧道的下一级设备是不定的
，同时一些数据包本身也要求更改MTU。
所有这些，在Linux中的处理都不够或根本没有处理。大家努力呀！
--
那你可不可以教我，
有什么办法可以不去喜欢一个人呢？
-- Bye 赤明莉香 --
我是来自大富翁的小美！^_^
※ 来源:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.1.115]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店