Linux中IP隧道的分析与建议

作者的话：

　　本文系在阅读Linux源码及一些相关资料的基础上写成的。

　　欢迎就文章的各个方面提出建议和批评意见，作者希望更多的交流和探讨。

　　欢迎在保留原文完整性的前提下在网上转贴，需部分引用请通知作者。

　　传统媒体转载和引用此文，请务必经过作者同意。

　　欢迎在实际的应用中使用此文提出的思想，希望同时知会作者。

　　作者信箱: 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借网络设备之名，一把抓干了不少

　　工作，真是‘高效’。而解封部件宏观上