Linux中IP隧道的分析與建議
2024-07-26 00:31:33
供稿：網(wǎng)友
****************************************************************
作者的話：
本文系在閱讀linux源碼及一些相關(guān)資料的基礎(chǔ)上寫成的。
歡迎就文章的各個(gè)方面提出建議和批評(píng)意見，作者希望更多的交流和探討。
歡迎在保留原文完整性的前提下在網(wǎng)上轉(zhuǎn)貼，需部分引用請(qǐng)通知作者。
傳統(tǒng)媒體轉(zhuǎn)載和引用此文，請(qǐng)務(wù)必經(jīng)過作者同意。
歡迎在實(shí)際的應(yīng)用中使用此文提出的思想，希望同時(shí)知會(huì)作者。
作者信箱: xiaoman04@hotmail.com
歡迎來信！！
*****************************************************************
O、
由于網(wǎng)絡(luò)的日益普及，網(wǎng)絡(luò)的安全成為目前的熱門話題。本文對(duì)隧道技術(shù)的分析，
就側(cè)重安全領(lǐng)域，對(duì)利用隧道技術(shù)實(shí)現(xiàn)虛擬專網(wǎng)提出建議。
為什么需要ip隧道？沒有接觸過這個(gè)概念的人自然提出這樣的疑問。實(shí)際上概念
最初的提出很簡單，為了在TCP/IP網(wǎng)絡(luò)中傳輸其他協(xié)議的數(shù)據(jù)包。設(shè)想IPX協(xié)議或
X.25封裝的數(shù)據(jù)包如何通過Internet網(wǎng)進(jìn)行傳輸，在已經(jīng)使用多年的橋接技術(shù)中是
通過在源協(xié)議數(shù)據(jù)包上再套上一個(gè)IP協(xié)議頭來實(shí)現(xiàn)，形成的IP數(shù)據(jù)包通過Internet后
卸去IP頭，還原成源協(xié)議數(shù)據(jù)包，傳送給目的站點(diǎn)。對(duì)源協(xié)議數(shù)據(jù)來說，就如被IP
帶著過了一條隧道。這種技術(shù)在業(yè)余無線網(wǎng)絡(luò)（Amateur Packet Radio network，
應(yīng)該怎么翻，請(qǐng)告訴我）得到了最廣泛的應(yīng)用。
利用IP隧道來傳送的協(xié)議包也包括IP數(shù)據(jù)包，本文主要分析的IPIP封包就是如此，從字
面來理解IPIP就對(duì)了，就是把一個(gè)IP數(shù)據(jù)包又套在一個(gè)IP包里。為什么要這么做呢？
多此一舉嘛。其實(shí)不然，見過一些應(yīng)用就會(huì)明白，移動(dòng)IP（Mobile-IP）和IP多點(diǎn)廣播
（IP-Multicast）是兩個(gè)通常的例子。目前，IP隧道技術(shù)在構(gòu)筑虛擬專網(wǎng)（ Virtual
PRivate Network）中也顯示出極大的魅力。本文也將對(duì)利用IP隧道技術(shù)構(gòu)筑VPN做
簡單設(shè)想。
背景：隧道的多種理解和實(shí)現(xiàn)
Internet的研究者多年前就感到需要在網(wǎng)絡(luò)中建立隧道，最初的理解是在網(wǎng)絡(luò)
中建立一條固定的路徑，以繞過一些可能失效的網(wǎng)關(guān)。可以說，隧道就是一條
特定的路徑。
這樣的隧道是通過IP報(bào)頭中的源路由選項(xiàng)來實(shí)現(xiàn)的，在目前看來，這個(gè)方法的缺陷
十分明顯。要設(shè)置源路由選項(xiàng)就必須知道數(shù)據(jù)包要經(jīng)過的確切路徑，而且目前
多數(shù)路由實(shí)現(xiàn)中都不支持源路由。
另一個(gè)實(shí)現(xiàn)隧道的機(jī)制是開發(fā)一種新的IP選項(xiàng)，用來表明源數(shù)據(jù)包的信息，原IP頭
可能成為此選項(xiàng)的一部分。這種隧道的意義與我們所說的隧道已十分接近。但它的
不足在于要對(duì)目前IP選項(xiàng)的實(shí)現(xiàn)和處理做較大的修改，也缺乏靈活性。
最后常用的一種實(shí)現(xiàn)方法是開發(fā)一種新的IP封包協(xié)議，仍然套用當(dāng)前的IP頭格式。
通過IP封包，不須指明網(wǎng)絡(luò)路徑，封包就能透明地到達(dá)目的地。也可以通過封包空
間把未直接連接的機(jī)器綁在一起，從而創(chuàng)建虛擬網(wǎng)絡(luò)。這種方法易行、可靠、可擴(kuò)
展性強(qiáng)，Linux采用了這一方法，這也是目前我們所理解的隧道思想。
一、
封包協(xié)議的結(jié)構(gòu)和實(shí)現(xiàn)
封包協(xié)議的實(shí)現(xiàn)原理十分簡單。先看看通過隧道傳送的數(shù)據(jù)報(bào)在網(wǎng)絡(luò)中如何流動(dòng)，
如圖一。
為了敘述簡便，我把在隧道中傳送的IP數(shù)據(jù)包稱為封包。
-------------- -----------
/ 子網(wǎng)A / / 子網(wǎng)C /
/ / / /
| | | |
| & | | |
| + +++++ | | ***** |
| +++++ + | | * * |
| + | | ***** * |
/ + / ----------- / * * / ----------
/ ++> # * **>(#) * ***> # ++++ /
-------------- / * * / ------------ / + /
| * * | | + |
| * * | | + |
| ***** * | | +++++++ |
| ***** | | V |
| | | & |
/ / / /
/ 子網(wǎng)B / / 子網(wǎng)D /
----------- ----------
++++++ 原數(shù)據(jù)報(bào)
****** 封裝后的數(shù)據(jù)包（封包）
# 封裝/解封
& 用戶主機(jī)
圖一. 封包協(xié)議實(shí)現(xiàn)模型
看圖中的設(shè)備 #，分別處于隧道的兩端，分別起打包（封裝）和解包（解封）
的作用，在整個(gè)數(shù)據(jù)包的傳送路徑中，除了隧道兩端的 # 設(shè)備，其他網(wǎng)關(guān)把
數(shù)據(jù)包看成一個(gè)普通的IP包進(jìn)行轉(zhuǎn)發(fā)。
設(shè)備 # 就是一個(gè)封包基于的兩個(gè)實(shí)現(xiàn)部件--封裝部件和解封部件。封裝和解封
部件（設(shè)備）都應(yīng)當(dāng)同時(shí)屬于兩個(gè)子網(wǎng)。封裝部件對(duì)接收到的數(shù)據(jù)報(bào)加上封包頭
，然后以解封部件地址作為目的地址轉(zhuǎn)發(fā)出去；而解封部件則在收到封包后，還
原原數(shù)據(jù)報(bào)，轉(zhuǎn)發(fā)到目的子網(wǎng)。
隧道的源端（封裝部件）對(duì)進(jìn)入隧道的數(shù)據(jù)包進(jìn)行封裝，形成封包。一個(gè)完整
的封包如圖二所示。
/ +-----------------+
| | 封包IP頭 |
封包頭 | +-----------------+
| | 封包協(xié)議頭 |
/ +-----------------+
/ | 原協(xié)議頭 |
| +-----------------+
| | |
原數(shù)據(jù)報(bào) | | 原協(xié)議數(shù)據(jù) |
| . .
| . .
| | |
/ +-----------------+
圖二. 封包結(jié)構(gòu)
二、
Linux中的實(shí)現(xiàn)
本人分析的版本是Linux2.0.34（RedHat5.2采用）。
在Linux中，隧道的實(shí)現(xiàn)主要基于兩個(gè)文件new_tunnel.c和ipip.c
同時(shí)Linux定義了一種新的協(xié)議類型--IPIP（IPPROTO_IPIP），與上面所說封包
類型類似。
基本思路
在Linux中IP Tunnel的實(shí)現(xiàn)也分為兩個(gè)部件：封裝部件和解封部件，分別司職發(fā)送和接
收。但這兩個(gè)部分是在不同的層次以不同的方式實(shí)現(xiàn)的。
封裝部件是在數(shù)據(jù)鏈路層以虛設(shè)備的方式實(shí)現(xiàn)。所有源代碼見
/usr/src/linux/drivers/net/new_tunnel.c
為實(shí)現(xiàn)封裝，Linux實(shí)現(xiàn)一個(gè)稱為tunl的網(wǎng)絡(luò)設(shè)備（類似loopback設(shè)備），此設(shè)備
具有其他網(wǎng)絡(luò)設(shè)備共有的特征，對(duì)于使用此設(shè)備的上層應(yīng)用來說，對(duì)這些網(wǎng)絡(luò)設(shè)備
不加區(qū)分，調(diào)用及處理方法當(dāng)然也完全一樣。
tunnel_init()和tunnel_xmit()是new_tunnel.c中的兩個(gè)主要過程。
tunnel_init()初始化與設(shè)備tunl相關(guān)的device結(jié)構(gòu)。
而tunnel_xmit()在從tunl設(shè)備發(fā)送數(shù)據(jù)時(shí)被調(diào)用，tunl設(shè)備作為實(shí)現(xiàn)IP隧道
技術(shù)的封裝部分，在此過程中完成對(duì)相應(yīng)的數(shù)據(jù)報(bào)進(jìn)行封裝所需的全部操作，
形成IPIP類型的IP包，并重新轉(zhuǎn)發(fā)此數(shù)據(jù)包（ip_forward()）。
解封部件在IP的上層實(shí)現(xiàn)，系統(tǒng)把它作為一個(gè)虛的傳輸層（實(shí)際上與傳輸層毫無
關(guān)系），具體處理見文件
/usr/src/linux/net/ipv4/ipip.c。
我們知道，每一個(gè)IP數(shù)據(jù)包均交由ip_rcv函數(shù)處理，在進(jìn)行一些必要的判斷后，ip_rcv
對(duì)于發(fā)送給本機(jī)的數(shù)據(jù)包將交給上層處理程序。對(duì)于IPIP包來說，其處理函數(shù)是
ipip_rcv（就如TCP包的處理函數(shù)是tcp_rcv一樣，IP層不加區(qū)分）。也就是說，當(dāng)
一個(gè)目的地址為本機(jī)的封包到達(dá)后，ip_rcv函數(shù)進(jìn)行一些基本檢查并除去IP頭，然后
交由ipip_rcv解封。
ipip_rcv所做的工作就是去掉封包頭，還原數(shù)據(jù)包，然后把還原后的數(shù)據(jù)包放入相應(yīng)的
接收隊(duì)列（netif_rx()）。
從以上IP Tunnel實(shí)現(xiàn)的思想來看，思路十分清晰，但由于IP Tunnel的特殊性，其
實(shí)現(xiàn)的層次并不單純。實(shí)際上，它的封裝和解封部件不能簡單地象上面所說的那樣
分層。tunl設(shè)備雖應(yīng)算進(jìn)鏈路層，但其發(fā)送程序中做了更多的工作，如制作IPIP頭
及新的IP頭（這些一般認(rèn)為是傳輸層或網(wǎng)絡(luò)層的工作），調(diào)用ip_forward轉(zhuǎn)發(fā)新包
也不是一個(gè)網(wǎng)絡(luò)設(shè)備應(yīng)當(dāng)做的事。可以說，tunl借網(wǎng)絡(luò)設(shè)備之名，一把抓干了不少
工作，真是‘高效’。而解封部件宏觀上看在網(wǎng)絡(luò)層之上，解出IPIP頭，恢復(fù)原數(shù)據(jù)包
是它分內(nèi)的事，但在它解出數(shù)據(jù)包（即原完整的協(xié)議數(shù)據(jù)包）后，它把這個(gè)包
放入相應(yīng)的協(xié)議接收隊(duì)列。這種事可不是一個(gè)上層協(xié)議干的，這是網(wǎng)絡(luò)設(shè)備中斷
接收程序的義務(wù)。看到了，在這點(diǎn)上，它好象到了數(shù)據(jù)鏈路層。
是不是有點(diǎn)亂，隧道機(jī)制就是這樣，你有沒有更好的辦法？
三、
為實(shí)現(xiàn)VPN的擴(kuò)展
實(shí)際上Linux只為實(shí)現(xiàn)隧道機(jī)制提供了一個(gè)框架，圖二中的封包協(xié)議頭在
Linux中被忽略了，也就是說，封包頭只含封包IP頭，其后緊跟原IP數(shù)據(jù)包。
這樣的結(jié)構(gòu)用于傳輸公開數(shù)據(jù)沒有關(guān)系，但對(duì)于一個(gè)VPN來說，安全保密是
不可缺少的重要功能。我們希望通過隧道的數(shù)據(jù)可靠且不可竊取和冒充的，
那么，加密和認(rèn)證就必不可少。
為實(shí)現(xiàn)這一構(gòu)想，設(shè)計(jì)以下封包協(xié)議頭：
0 4 8 16 24 31
+-----+-----+-----------+------------------------+
| ver |type | hlen | OldPacketLen |
+-----------------------+------------------------+
| DeviceID | EncapID |
+-----------------------+------------------------+
| Flags | CheckSum |
+------------------------------------------------+
| IPIP Options( If any ) |
+------------------------------------------------+
. | padding |
. .
+------------------------------------------------+
圖三、 IPIP頭設(shè)想圖
ver: 版本號(hào)，利于擴(kuò)展
type: 用于建立不同目的的隧道（可能處理上有差別）
OldPacketLen: 進(jìn)入隧道的原數(shù)據(jù)包長度
DeviceID: 對(duì)數(shù)據(jù)包進(jìn)行封裝的設(shè)備標(biāo)識(shí)
EncapID: 此封包的ID號(hào)
Flags: 標(biāo)志位，共16位，初步定義如下：
0 保留
1 有否加密
2 有否做摘要
3 有否簽名
4 保留
5 有否傳送消息密鑰
6 消息密鑰有否加密
7 消息密鑰是否需保留
8-15 保留
CheckSum: 頭校驗(yàn)
IPIP Options: 用來傳送一些必要的數(shù)據(jù)，比如消息密鑰、簽名等
格式： +-------------------------------------+
| 類型 | 長度 | 數(shù)據(jù) ... |
+-------------------------------------+
好了，有了這個(gè)東西，我們就可以擴(kuò)展Linux IP Tunnel為我們的VPN服務(wù)了。
首先，改寫new_tunnel.c和ipip.c兩個(gè)文件，加入對(duì)IPIP頭的處理。
接著，我們要實(shí)現(xiàn)一種密鑰的管理和傳送機(jī)制。
當(dāng)然，對(duì)稱密鑰是必需的，而對(duì)IP數(shù)據(jù)包加密要使用序列密碼。從全體考慮，
我們可以提出建立VPN的邏輯步驟；
1、準(zhǔn)備工作：建網(wǎng)安裝系統(tǒng)完成配置等等
2、隧道的兩端分別向?qū)Ψ桨l(fā)送自己的公開密碼和設(shè)備號(hào)
3、如有必要，產(chǎn)生序列密碼，后加密簽名傳給對(duì)方
4、正常通信，----放心，你的數(shù)據(jù)已經(jīng)很保險(xiǎn)了。
在一個(gè)VPN的隧道中，一個(gè)封包的格式應(yīng)如圖四所示。
/ +-----------------+
| | 封包IP頭 |
封包頭 | +-----------------+
| | 封包協(xié)議頭 |
/ +-----------------+
/ | |
| | 原協(xié)議頭 |
| | 及 |
封包數(shù)據(jù) | | 原協(xié)議數(shù)據(jù) |
| . （密文） .
| . .
| | |
/ +-----------------+
圖四. VPN封包結(jié)構(gòu)
你的幾種使用方法。
事情往往不能兩全其美，你在安全強(qiáng)度和通信速度上必須作出選擇，
（不然你就需要在安全強(qiáng)度和Money的耗費(fèi)中做選擇。）
使用這樣的協(xié)議，根據(jù)你的需求不同，你可有不同的使用方法，下面列舉
一些：
0、跨Internet的公司多個(gè)內(nèi)部網(wǎng)之間進(jìn)行通信，保密性并不重要
直接使用原框架機(jī)制，無任何加密措施
這樣速度快、效率高，公司也不用申請(qǐng)多個(gè)IP地址，方便可行
1、一般性的商業(yè)應(yīng)用，具有保密要求
利用事先產(chǎn)生的序列密碼，每次對(duì)原數(shù)據(jù)包加密
安全度提高了，是一種十分實(shí)用的方法。只要強(qiáng)度足夠，一般很難破譯
速度快
2、密碼不變的方式你認(rèn)為不夠安全
你可以自己實(shí)現(xiàn)一種密碼傳送方法，每隔一段時(shí)間更換一次密碼。
其中一些握手關(guān)系需要完善，有興趣的歡迎探討。
如果發(fā)展成熟，此法相信很有前途。
4、高度機(jī)密領(lǐng)域
敬請(qǐng)使用一次一密，并進(jìn)行每次簽名。
每次產(chǎn)生新密鑰和簽名十分費(fèi)時(shí)，在目前我國Internet網(wǎng)絡(luò)的速度下
幾乎不可行。
但相信有此需要的部門也能夠設(shè)法提高其網(wǎng)絡(luò)帶寬，讓網(wǎng)絡(luò)狀況適合
這種應(yīng)用。
另外，當(dāng)然還可以就加密強(qiáng)度自身作出選擇，比如選擇128位，還是512位、1024位
四、
待完善
主要牽涉到隧道的管理，在封包的傳送過程中如果出現(xiàn)錯(cuò)誤是十分正常的，
當(dāng)一臺(tái)路由器檢測到錯(cuò)誤時(shí)，它會(huì)發(fā)送一個(gè)ICMP包給隧道的發(fā)送端，但遺憾的是
ICMP返回的數(shù)據(jù)除了IP頭外，只含8個(gè)字節(jié)的上層協(xié)議信息。只憑這個(gè)難以對(duì)
ICMP信息作出反應(yīng)，因此，在隧道端保留一些狀態(tài)信息是必須的。這些信息
主要包括：
隧道的另一端的可達(dá)性
隧道的擁塞狀況
隧道的MTU
同時(shí)所發(fā)送的封包信息也是需要保留的，舉例說，當(dāng)一個(gè)路由不可達(dá)信息
到來時(shí)，封包的發(fā)送者要能夠找出所封裝的數(shù)據(jù)來自何方，并發(fā)送相應(yīng)的ICMP包。
強(qiáng)調(diào)一點(diǎn)，MTU的更新對(duì)隧道來將很重要，因?yàn)橐粋€(gè)靈活的隧道的下一級(jí)設(shè)備是
不定的，同時(shí)一些數(shù)據(jù)包本身也要求更改MTU。
所有這些，在Linux中的處理都不夠或根本沒有處理。大家努力呀！
