Linux下的IP隧道研究（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的耗費中做選擇。）使用這樣的協議，根據你的需求不同，你可有不同的使用方法，下面列舉一些：

跨Internet的公司多個內部網之間進行通訊，保密性並不重要直接使用原架構機制，無任何加密措施這樣速度快、效率高，公司也不用申請多個IP地址，方便可行
一般性的商業應用，具有保密要求利用事先產生的序列密碼，每次對原資料包加密安全度提高了，是一種十分實用的方法。只要強度足夠，一般很難破譯速度快
密碼不變的方式你認為不夠安全你可以自己實現一種密碼傳送方法，每隔一段時間更換一次密碼。其中一些握手關係需要完善，有興趣的歡迎探討。如果發展成熟，此法相信很有前途。
高度機密領域:敬請使用一次一密，並進行每次簽名。每次產生新密鑰和簽名十分費時，在目前我國Internet網路的速度下幾乎不可行。但相信有此需要的部門也能夠設法提高其網路頻寬，讓網路狀況適合這種應用。另外，當然還可以就加密強度自身作出選擇，比如選擇128位，還是512位、1024位
四、待完善
主要牽涉到隧道的管理，在封包的傳送過程中如果出現錯誤是十分正常的，當一台路由器檢測到錯誤時，它會發送一個ICMP包給隧道的發送端，但遺憾的是ICMP返回的資料除了IP頭外，只含8個位元組的上層協議資訊。只憑這個難以對ICMP資訊作出反應，因此，在隧道端保留一些狀態資訊是必須的。這些資訊主要包括：

隧道的另一端的可達性
隧道的擁塞狀況
隧道的MTU
同時所發送的封包資訊也是需要保留的，舉例說，當一個路由不可達資訊到來時，封包的寄件者要能夠找出所封裝的資料來自何方，並發送相應的ICMP包。