【正文】 應用環(huán)境加以說明： ○ 1 LACLNS 組合 圖 中，一方面， LAC 接收 二層 的數(shù)據(jù)流。 圖 自建隧道示意圖 自建隧道是依靠 LAC Client，其區(qū)別于非自建隧道主要在于：它的終端扮演了使用隧道的用戶以及建立隧道的 LAC 的雙重角色，由用戶來自行創(chuàng)建隧道。 LNS 在收到 IP 包后，拆封還原出 L2TP，根據(jù) L2TP 協(xié)議的進行處理，拆封還原出 PPP 幀，最后對 PPP 西南交通大學碩士研究生學位論文 第 4 頁 PSTN： 公用電話交換網(wǎng) 圖 非自建隧道示意圖 幀拆封，把還原出來的網(wǎng)絡層的數(shù)據(jù)包交給 LNS 的網(wǎng)絡層。非自建隧道示意如圖 所示。 LAC 是（遠端）用戶終端（計算機）利用 PPP 接入 L2TP 隧道的訪問集中器。對隧道功能的形象表達可以用“過渡”（ Ferrying）來描述，公用數(shù)據(jù)網(wǎng)可以看作是河流，隧道視為“渡船”（ Ferry），而過渡的乘客或車輛則是用戶期望過河的數(shù)據(jù)。結合作者所在研究小組的工作和 L2TPv3，本論文反映的工作的重點為對 L2TPv3 的研究和相關軟件開發(fā)工作?！八淼纻鬏敗被蛘摺斑^渡”的思想 [5]實際上有更廣泛的應用前景。 L2TPv2結合了 L2F和 PPTP的優(yōu)點，其應用對象與 PPTP類似，也是專門針對點到點協(xié)議（ PPP – PointtoPoint Protocol） [6]進行隧道傳輸和中繼的協(xié)議。在隧道內建立 PPP連接時， PPTP需要對訪問者的身份進行認證（如用戶名，口令和域名等）。 PPTP[9]是由多家公司（其中包括 Microsoft， 3Com， ECI Telematics以及 ）專門為支持 VPN而開 發(fā)的一種技術。 Inter環(huán)境提供了兩種典型的 VPN技術：安全 IP協(xié)議（ IPSec） [2]和二層隧道協(xié)議 [7～ 9]。所謂 VPN是一種物理資源為多個網(wǎng)絡或單機系統(tǒng)共用，但可以根據(jù)需要限定用戶 /網(wǎng)絡間相互訪問能力，對非受限網(wǎng)絡或用戶之間，其效果就像在使用自己的專用網(wǎng)絡。 最后作者對所作的工作做了簡短的總結，并對該技術提出了展望。 論文作者的工作包括： ○ 1 對 3 個版本的隧道傳輸協(xié)議的產(chǎn)生背景、各版本的異同進行了較為詳細的分析。二層隧道技術則是一種利用公用數(shù)據(jù)網(wǎng)建立通信隧道實現(xiàn)對公用數(shù)據(jù)網(wǎng)兩端的第 2層協(xié)議（特別是 PPP）進行中繼的組建第 2 層 VPN 的方法。采用 VPN 技術，網(wǎng)絡建設者可以利用公用數(shù)據(jù)網(wǎng)提供的服務，在敷設或租用用戶（長途）專線的條件下組建安全專用網(wǎng)絡。該思路比 2020 年 IETF 的建議草案，即 L2TPv3覆蓋的范圍更廣。其中，在協(xié)議實現(xiàn)方面，作者的工作重點是數(shù)據(jù)的封裝與中繼傳輸?shù)脑O計與實現(xiàn)，這部分功能主要體現(xiàn)在系統(tǒng)的內核數(shù)據(jù)層模塊中。但是，這種組網(wǎng)方式的成本往往太高，于是虛擬專用網(wǎng)絡（ VPN – Virtual Private Network）技術應運而生。利用這一服務可以將聯(lián)入以 部小組進行信息交換 ,而非該內部小組的成員不得與該組內成員交換信息。 第一版的二層隧道協(xié)議以 L2F和 PPTP為代表。在 PNS與 PAC之間利用于 TCP/IP建立 “隧道控制連接”來控制基于 GRE上的隧道的建立。 第二版 的二層隧道協(xié)議 RFC 2661[7]是由 Cisco、 Ascedn、微軟和 RedBack的專家提出的，并正式采用了第 2層隧道協(xié)議的名稱（ L2TP Layer 2 Tunneling Protocol），后來被成為 L2TPv2。 通過對 L2TPv2[2]協(xié)議的學習和深入研究，作者與其他幾位研究組成員都認為： L2TPv2 試圖解決的僅限于撥號或專線用戶訪問遠端服務器的問題，只是遠程互聯(lián)的一種特殊情況。在相關研究工作 進展的過程中，作者發(fā)現(xiàn) Cisco 公司也在作類似的研究，并在 2020 年發(fā)現(xiàn)了 IETF 建議草案 西南交通大學碩士研究生學位論文 第 3 頁 L2TPv3[18～ 19]，即二層隧道協(xié)議的第三版。利用公用數(shù)據(jù)網(wǎng)建立的連接被稱為“隧 道”（ Tunnel），利用隧道傳送或中繼的功能被稱為隧道傳輸（ Tunneling）；而被隧道運載的數(shù)據(jù)或連接的協(xié)議層則被用于標識隧道的用途，例如第 2 層隧道協(xié)議則表示被運送的連接或數(shù)據(jù)與第 2 層的協(xié)議相聯(lián)系。 L2TPv2（本小節(jié)內，為描述方便使用 L2TP 之處皆指 L2TPv2）是為支持 C/S 模式而定義的訪問協(xié)議， L2TP 隧道兩端的兩個組成部件為非對稱的LAC（ L2TP Access Concentrator）和 LNS（ L2TP Network Server）。 L2TP 的隧道分為非自建隧道（ Compulsory Tunnel） 和自建隧道兩種。 Remote System 先將網(wǎng)絡層送來的數(shù)據(jù)包封裝在 PPP 幀中，通過它與 LAC 之間的撥號連接將 PPP 幀送給 LAC，如果 L2TP 隧道是基于 Inter 的話， LAC 先將 PPP 幀封裝在 L2TP中，再進行 IP 封裝，通過 Inter 傳送給 LNS。 自建隧道示意如下圖所示。因此，隧道兩端的設備連接關系就出現(xiàn)了 三種組合： LACLNS， LACLAC 和 LNSLNS，在不需要區(qū)L2TP 隧道 PPP 連接 LAC Client LNS Inter 主機 主機 Remote System PSTN LAC LNS Inter 主機 主機 L2TP 隧道 PPP 連接 西南交通大學碩士研究生學位論文 第 5 頁 別是 LAC 還是 LNS 時，則統(tǒng)稱為“ L2TP 控制連接終端” （ LCCE —— L2TP Control Connection Endpoint）。 如圖 所示。而且一個 LAC 僅僅作為遠端系統(tǒng)與 L2TP 隧道間的連接點。 LNS 除了負責傳送數(shù)據(jù)流外，而且還可以終止 L2TP 會話。 值得注意的是：如果一個 LNS 由于事件驅動而建立一個會話，那么則把LNS 作為 LAC 客戶來看待。L2TPv2 只支持 PPP 數(shù)據(jù)幀的封裝， L2TPv3 擴展的目的是制訂一個能夠對所有數(shù)據(jù)鏈路層協(xié)議進行隧道傳輸?shù)耐ㄓ脜f(xié)議。 論文結構 論文總體上對 L2TP 協(xié)議的概念，一個典型實現(xiàn)以及對該實現(xiàn)的測試進行了描述。第三章是協(xié)議相關部分的分析和設計。第五章是對系統(tǒng)的測試，重點在作者所負責的模塊方面的測試。 Call (Circuit Up)－呼叫 呼叫用來激活 LAC 上電路的狀態(tài)為“ up”或“ active”。 Circuit－電路 2 層連接的總稱。 Ining Call－呼入呼叫 呼入呼叫是指 LAC 上接收到一個呼叫的（電路的 up 事件）的行為。 Outgoing Call Request －呼出呼叫請求（ OCRQ） 是指向 LAC 發(fā)出的一個請求，以發(fā)起一個呼出呼叫。同樣LNS 的端也可能是 LAC 或另一個 LNS。 Session－會話 當一個電路成功建立后，兩個 LCCE 之間通過一個特殊的控制連接建立起一個 L2TP會話。 ZLB 報文用于在可靠控制信道上對報文的應答。這類的報文采用可靠的控制信道來 發(fā)送。而且，在需要的情況下，數(shù)據(jù)信道可以在沒有控制信道的情況下使用?？刂茍笪脑谝粋€可靠的信道上發(fā)送，穿過同樣的 PSN。盡管本節(jié)是以 L2TPv3 為對象進行討論的，但除了前面已提到的差別外，本節(jié)討論的內容原則上也適用于 L2TPv2。 L2TP over IP 在 L2TPv3 中對 over IP 專門作了定義， L2TPv3 over IP 采用了 IANA 分配的 IP 協(xié)議 ID 為 115。假定網(wǎng)絡的拓撲結構采用 LACLNS， LAC 在接收到遠端系統(tǒng)發(fā)送過來的 PPP數(shù)據(jù)包后，則對其進行封裝，封裝可以分別采用 L2TP over UDP 或者 L2TP over IP 兩種方式，具體根據(jù)系統(tǒng)的配置。 DATA IP UDP/IP DATA IP PPP L2TP DATA IP 西南交通大學碩士研究生學位論文 第 12 頁 TCP/IP 協(xié)議棧內部的數(shù)據(jù)流向分析 正常情況下，數(shù)據(jù)鏈路層協(xié)議（以下簡稱 L2P）的功能是為網(wǎng)絡層提供服務。 加入 L2TP 協(xié)議后內部數(shù)據(jù)流向分析 內核中加入 L2TP 協(xié)議以后，在 L2TP 內核中進行數(shù)據(jù)的處理，通過TCP/IP 的內核來路由 L2 數(shù)據(jù)。數(shù)據(jù)包也就是二層的數(shù)據(jù)，如 PPP 的幀，在隧道建立完成后，通過 L2TP 的內核來完成封裝，再通過 TCP/IP 的內核路由到目的端。如果由 LNS 發(fā)起呼叫，則功能類似于 LAC。目的是為了本章最后所作的系統(tǒng) 設計的需要，包括系統(tǒng)的框架設計以及模塊的劃分等。 ① 控制報文頭格式 控制報文的頭格式如下圖所示： 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 T L X X S X X X X X X X Ver Length Control Connection ID Ns Nr 圖 控制報文的頭格式 默認情況下，控制報文和數(shù)據(jù)報文在底層介質里一并傳輸，也就是帶內傳輸。 X 域是保留位作為將來的擴展用，如果是呼出報文的話，保留位則設定為 0，如果是呼入報文則忽略。這個標識符只具有本地意義，同一個控制連接的兩個 LCCE 分別具有唯一的連接標識符。 Nr 表示下一個收到的控制報文所期望的序列號，也就是說 Nr 的值被設定為 Ns 加 1。 不同類型的 PSN 必須定義自身的會話頭，能夠明確地區(qū)分頭的格式以及建立會話所需的參數(shù)。會話標識符只具有本地的意義，也就是說在會話的生命期內，控制連接的兩端可以具有不同的會話 ID。 Cookie提供了一種確保數(shù)據(jù)報文直接與會話相關的機制， Cookie 選擇恰當可以防止掉隊的報文與會話 ID 的錯誤關聯(lián)。數(shù)據(jù)報文頭后緊跟著 所要入隧的二層幀。 X 為保留位，以為將來擴展使用。圖 所示為控制報文頭。 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 M H rsvd Length Vendor ID Attribute Type Attribute Value ... (until Length is reached) 圖 AVP 格式 前六位描述了 AVP 的一般屬性，其中前兩位被定義，而后四位作為保留位以為將來擴展用。如果一個與特殊會話或者控制連接相關的控制報文 AVP 無法識別或者是畸形，且 M 位被設定，則這個會話或連接以及綁定到這個連接上的所有會話必須被終止。 長度字段（ Length）表示這個 AVP 中的字節(jié)長度，一般為屬性值加 6。本文中采用的是 0。 屬性值（ Attribute Type）用以表明具體的 AVP 屬性。在定義這種 AVP 時應該要考慮到這個問題。 在接收端，當收到的控制報文中的 AVP 不可識別或是畸形時，應當只檢查 這個 AVP 的 M 位，反之則不用檢查。 H 位在以下兩種情況下必須采用：（ 1）兩個 LCCE 之間存在一個共享密鑰；（ 2） LCCE 認證已經(jīng)完成。如果在一個給定的控制報文中的任何 AVP 的 H 位被設定，一個隨機向量 AVP 必須出現(xiàn)在報文中并且在第一個帶有 H 位為 1的 AVP 之前。當增加了 Padding 后，有必要知道原始數(shù)據(jù)的長度。 Padding 并不改變Length of Original Attribute Value 域，但是改變了合成的 AVP 的長度。 第二步，對如下的串進行 MD5 哈希算法。如果不同的隨機向量應用于并發(fā) AVP 的隱藏時，那么在第一個 AVP 應用前，必須在命令報文中設置一個新的隨機向量 AVP。 如果子格式大于 16 字節(jié)，下一個單向的 MD5 哈希值是通過共享密鑰組成的字節(jié)流 以及其后所跟的第一次異或的結果計算得到的。把值域分成 16 字節(jié)的數(shù)據(jù)塊 p p2 等，最后的塊用隨機數(shù)填充到 16 字節(jié)。然后再按照上面介紹的處理過程的逆過程來獲得原始的值。 控制報文類型 下表是定義的文本定義的控制報文類型。例如發(fā)送端在發(fā)送一個報文后，如果在隨后的相應報文中沒有收到確認報文，那么就要發(fā)送一個 ZLB ACKs 確認包