轉自：http://lijt100616.blog.51cto.com/1338011/341144
這個協議是早前做防火牆測試工作時主要負責測試的協議，雖然只做了幾個月，但感覺如果把當時的一些學習筆記和經驗整理好放在網絡中，不僅可以使自己的協議理解得到鞏固，也讓自己有機會在和別人交流中互相學習。
當初學習時，看的資料大部分都是先簡介協議然後直接就開始抽象的介紹各種報文格式、報文每個字段的作用，光是大量報文名稱看着頭就很大了，所以在這裏先介紹了L2TP的大框，知道是幹什麼的、有哪些概念、整體運作的過程大概是什麼樣的，然後在針對每一個步驟涉及的報文進行深入研究，看着一個協商報文可以形象的想象出其在這個L2TP建立過程中的位置和作用。
L2TP協議簡介
Layer
2 Tunneling Protocol （第二層隧道協議）
該協議是一種工業標準的Internet隧道協議，功能大致和PPTP協議類似，比如同樣可以對網絡數據流進行加密。不過也有不同之處，比如PPTP要求網絡爲IP網絡，L2TP要求面向數據包的點對點連接；PPTP使用單一隧道，L2TP使用多隧道；L2TP提供包頭壓縮、隧道驗證，而PPTP不支持。L2TP協議是由IETF起草，微軟、Ascend、Cisco、3COM等公司參予制定的二層隧道協議，它結合了PPTP和L2F兩種二層隧道協議的優點，爲衆多公司所接受，已經成爲IETF有關2層通道協議的工業標準，基於微軟的點對點隧道協議
(PPTP)和思科2層轉發協議(L2F)之上的，被一個因特網服務提供商和公司使用使這個虛擬私有網絡的操作能夠通過因特網。
此段說明來自百度百科，如果想要更詳細瞭解L2TP的相關介紹，可在搜索引擎中搜索，介紹的很詳細這裏就不重複描述了。
一、L2TP實現的兩種方式
名詞解釋：
LAC(L2TP
Access Concentrator L2TP訪問集中器)
是附屬在交換網絡上的具有PPP端系統和L2TP協議處理能力的設備。LAC一般是一個網絡接入服務器NAS，主要用於通過PSTN/ISDN網絡爲用戶提供接入服務。
LNS(L2TP
Network Server L2TP網絡服務器）
是PPP端系統上用於處理L2TP協議服務器端部分的設備。
VPDN（Virtual
Private Dial Network，虛擬私有撥號網）
指利用公共網絡（如ISDN和PSTN）的撥號功能及接入網來實現虛擬專用網。
注：如下示例中使用的防火牆（Firewall，FW）既可以當做LAC也可以作爲LNS使用。
1、PC直接撥號到LNS，組網如圖1所示
圖1
2、PC通過LAC撥號連接到LNS，組網如圖2所示
圖2
因爲一般都使用用PC---LAC---LNS組網，且此種組網包含了PC---LNS的組網形態，故後續描述均已PC---LAC---LNS爲例。
LAC位於LNS和主機之間，用於在LNS和主機之間傳遞信息包，把從主機收到的信息包按照L2TP協議進行封裝並送往LNS，將從LNS收到的信息包進行解封裝並送往遠端系統。LAC與主機之間可以採用本地連接或PPP鏈路，VPDN應用中通常爲PPP鏈路。LNS作爲L2TP隧道的另一側端點，是LAC的對端設備，是被LAC進行隧道傳輸的PPP會話的邏輯終止端點。
二、L2TP封裝位置分析
如下圖3所示，從圖中至上而下的分析，爲PC的報文在PPP內網環境中發送到LAC，由LAC封裝L2TP，再通過外網的報文正常轉發給LNS的報文封裝過程。
注：設計的網絡環境爲PC---LAC爲內網使用PPP協議，LAC---LNS爲外網使用協議由服務供應商自定。
![]()
圖3
三、理解L2TP幾個重要的概念
1、隧道和會話的概念
在一個LNS和LAC對之間存在着兩種類型的連接，一種是隧道（Tunnel）連接，一對LAC和LNS中可以有多個L2TP隧道；另一種是會話（Session）連接，它複用在隧道連接之上，用於表示承載在隧道連接中的每個PPP會話過程。
隧道由一個控制連接和一個或多個會話（Session）組成。會話連接必須在隧道建立（包括身份保護、L2TP版本、幀類型、硬件傳輸類型等信息的交換）成功之後進行，每個會話連接對應於LAC和LNS之間的一個PPP數據流。控制消息和PPP數據報文都在隧道上傳輸。
-
L2TP使用Hello報文來檢測隧道的連通性。LAC和LNS定時向對端發送Hello報文，若在一段時間內未收到Hello報文的應答，該隧道連接將被斷開。
-
L2TP報文頭中包含隧道標識符（Tunnel ID）和會話標識符（Session ID）信息，用來標識不同的隧道和會話。隧道標識相同、會話標識不同的報文將被複用在一個隧道上，報文頭中的隧道標識符與會話標識符由對端分配。
隧道（tunnel）和會話（session）的關係，如圖4所示；可以形象的理解爲會話是建立在隧道之中的，隧道想成一個有10個車道的高速公路，一臺撥號PC的數據流爲一個會話，相當於佔用了一個車道（告訴公路有多少車道是設備規定好的），這個車道只能跑這個運載這個PC的報文的卡車。（比如某型號設備每條隧道最多支持1000個會話）。
![]()
圖4
2、控制消息和數據消息的概念
L2TP中存在兩種消息：控制消息和數據消息。
-
控制消息：用於隧道和會話連接的建立、維護以及傳輸控制；控制消息的傳輸是可靠傳輸，並且支持對控制消息的流量控制和擁塞控制。
-
數據消息：用於封裝PPP幀並在隧道上傳輸；數據消息的傳輸是不可靠傳輸，若數據報文丟失，不予重傳，不支持對數據消息的流量控制和擁塞控制。
控制消息和數據消息共享相同的報文頭。
四、L2TP隧道的呼叫建立流程
1、L2TP隧道的呼叫建立流程
![]()
圖5
(1) 用戶端PC機發起呼叫連接請求；
(2) PC機和LAC端進行PPP LCP協商；
(3) LAC對PC機提供的用戶信息進行PAP或CHAP認證；
(4) LAC將認證信息（用戶名、密碼）發送給RADIUS服務器進行認證；
(5) RADIUS服務器認證該用戶，如果認證通過則返回該用戶對應的LNS地址等相關信息，並且LAC準備發起Tunnel連接請求；
(6) LAC端向指定LNS發起Tunnel連接請求；
(7) LAC端向指定LNS發送CHAP challenge信息，LNS回送該challenge響應消息CHAP response，併發送LNS側的CHAP challenge，LAC返回該challenge的響應消息CHAP
response；
(8) 隧道驗證通過；
(9) LAC端將用戶CHAP response、response identifier和PPP協商參數傳送給LNS；
(10) LNS將接入請求信息發送給RADIUS服務器進行認證；
(11) RADIUS服務器認證該請求信息，如果認證通過則返回響應信息；
(12) 若用戶在LNS側配置強制本端CHAP認證，則LNS對用戶進行認證，發送CHAP challenge，用戶側迴應CHAP response；
(13) LNS再次將接入請求信息發送給RADIUS服務器進行認證；
(14) RADIUS服務器認證該請求信息，如果認證通過則返回響應信息；
(15) 驗證通過，用戶訪問企業內部資源。
注：此節如下附加內容涉及到報文協商，前面沒有介紹，可以先了解L2TP筆記2中關於報文格式與協商的相關內容，再回頭深入分析此節，此節放在這裏是爲了便於對於整體協商過程進行深入分析。
附加:2、針對流程中步驟7、步驟12的Challenge驗證過程的分析
(1)LAC向LNS發SCCRQ請求消息時，會產生一個隨機的字符串做爲本端CHAP Challenge發給LNS。
(2)LNS收到這個Challenge後，再加上本端配置的密碼及SCCRP產生一個新的字符串，用MD5算出一個16個字節的Response，在SCCRP消息中發給LAC。
同時也產生一個隨機的字符串(LNS Challenge)放在SCCRP中一起發給LAC。
(3)LAC將自己的CHAP Challenge加上本端配置的密碼，再加上SCCRP產生一個新字符串，用MD5算出一個16字節的字符串，並與LNS發來的SCCRP中帶的LNS
CHAP Response比較，相同通過，不同斷掉。
(4)同理LNS也要驗證LAC，LAC用在SCCRP中發現的LNS CHAP Challenge加上本端密碼和SCCCN組合，再用MD5算出一個16字節的字符串做爲LAC
CHAP Response在SCCCN中發給LNS。
(5)LNS用自己發的Challenge+本端密碼+SCCCN用MD5算出一個16字節字符串，與收到的作比較，相同通過，不同斷掉。
附加:3、LAC代LNS與PC協商LCP(即認證代理)和用於認證的AVPS
正常用戶認證方式：
當LAC檢測到有用戶撥入電話的時候，向LNS發送ICRQ，請求在已經建立的tunnel中開始session的建立，LAC可以一直等到接收到了LNS迴應的ICRP後，表明session可以建立的時候再回答遠端(撥號用戶)的呼叫，這樣LNS可獲得足夠的信息來決定是否回答這個遠端的呼叫。
LAC代LNS與PC協商LCP(即認證代理)：
LAC在接收到ICRP之前，自行先回答遠端(撥號用戶)的呼叫，代替LNS與其進行LCP協商和PPP認證，用獲得的信息來決定選擇哪個LNS(此處對應流程圖中步驟5)，這種情況下LAC對呼叫的指示和呼叫的回答只是哄騙性質的。在session可以建立時，LAC向LNS發送ICCN時會攜帶着先前與呼叫用戶進行的LCP協商和PPP認證涉及的特性信息(此處對應流程圖中步驟9)，包含這些信息的AVP如下：
①Inital
Received LCP CONFREQ(ICCN\屬性26)：爲LNS提供LAC從PPP對端(即撥號用戶)接收到初始的conf-request。
②Last
Sent LCP CONFREQ(ICCN\屬性27)：提供LAC發送到PPP對端最後的conf-request。
③Last Received
LCP CONFREQ(ICCN\屬性28)：提供LAC從PPP對端接收到的最後的conf-request。
④Proxy
Authen Type(ICCN\屬性29)：標識是否使用驗證代理，驗證的類型
0---Reserved 1---Textual username/password exchange
2---PPP CHAP 3---PPP PAP
4---No Authentication 5---Microsoft CHAP Version 1(MSCHAPv1)
⑤Proxy
Authen Name(ICCN\屬性30)：驗證時客戶端響應的名稱。
⑥Proxy
Authen Challenge(ICCN\屬性31)：LAC發送到PPP對端的Challenge。
⑦Proxy
Authen ID(ICCN\屬性32)：爲LAC和PPP對端的驗證定了一個ID。
⑧Proxy
Authen Response(ICCN\屬性33)：LAC從PPP對端接收到的PPP Authentication Response。
參考文獻:
1、H3C產品手冊
2、華爲培訓資料
3、百度知道
4、學習筆記
