二、Linux中的实现
本人分析的版本是Linux2.0.34（RedHat5.2采用）。
在Linux中，隧道的实现主要基于两个文件new_tunnel.c和ipip.c同时Linux定义了一种新的协议类型--IPIP（IPPROTO_IPIP），与上面所说封包类型类似。
基本思路
在Linux中IP Tunnel的实现也分为两个部件：封装部件和解封部件，分别司职发送和接收。但这两个部分是在不同的层次以不同的方式实现的。封装部件是在数据链路层以虚设备的方式实现。所有源代码见
|
为实现封装，Linux实现一个称为tunl的网络设备（类似loopback设备），此设备具有其他网络设备共有的特征，对于使用此设备的上层应用来说，对这些网络设备 不加区分，调用及处理方法当然也完全一样。
tunnel_init()和tunnel_xmit()是new_tunnel.c中的两个主要过程。
tunnel_init()初始化与设备tunl相关的device结构。
而tunnel_xmit()在从tunl设备发送数据时被调用，tunl设备作为实现IP隧道技术的封装部分，在此过程中完成对相应的数据报进行封装所需的全部操作，形成IPIP类型的IP包，并重新转发此数据包（ip_forward()）。
解封部件在IP的上层实现，系统把它作为一个虚的传输层（实际上与传输层毫无关系），具体处理见文件
|
我们知道，每一个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来说，安全保密是不可缺少的重要功能。我们希望通过隧道的数据可靠且不可窃取和冒充的，那么，加密和认证就必不可少。为实现这一构想，设计以下封包协议头：
|
ver: 版本号，利于扩展
type: 用于建立不同目的的隧道（可能处理上有差别）
OldPacketLen: 进入隧道的原数据包长度
DeviceID: 对数据包进行封装的设备标识
EncapID: 此封包的ID号
Flags: 标志位，共16位，初步定义如下：
上一篇：JohntheRipper简介 下一篇：网络安全技术与黑客攻击威胁 更多相关文章
|
推荐文章
精彩文章
|
