L2TP基本原理

L2TP VPN簡介

L2TP基本概念：

L2TP（Layer 2 Tunneling Protocol） VPN是一種用於承載PPP報文的隧道技術，該技術主要應用在遠程辦公場景中爲出差員工遠程訪問企業內網資源提供接入服務。

目的：

L2TP VPN技術出現以後，使用L2TP VPN隧道“承載”PPP報文在Internet上傳輸成爲了解決上述問題的一種途徑。無論出差員工是通過傳統撥號方式接入Internet，還是通過以太網方式接入Internet，L2TP VPN都可以向其提供遠程接入服務。

L2TP VPN的優點：

• 身份驗證機制

  支持本地認證。

  支持Radius服務器等認證方式

• 多協議傳輸

  L2TP傳輸PPP數據包，PPP本身可以傳輸多協議，而不僅僅是IP可以在PPP數據包內封裝多種協議

• 計費認證地址分配

  可在LAC和LNS兩處同時計費，即ISP處（用於產生賬單）及企業網關（用於付費及審計）。L2TP能夠提供數據傳輸的出入包數、字節數以及連接的起始、結束時間等計費數據，可根據這些數據方便地進行網絡計費

  LNS可放置於企業網的USG之後，對遠端用戶地址進行動態分配和管理，可支持私有地址應用

• 不受NAT限制穿越

• 支持遠程接入

• 靈活的身份驗證及時以及高度的安全性

  L2TP協議本身並不提供連接的安全性，但它可以依賴於PPP提供的認證（CHAP、PAP等），因此具有PP所具有的所有安全特性。

• L2TP隧道可以與IPSec結合，使通過L2TP所傳輸的數據更難被攻擊。

  可根據特定的網絡安全要求，在L2TP之上採用通道加密技術、端對端數據加密或應用層數據加密等方案來提高數據的安全性。

• 可靠性

  L2TP協議支持備份LNS，當一個主LNS不可達之後，LAC可以重新與備份LNS建立連接，增加了VPN服務的可靠性和容錯性

L2TP VPN的原理

L2TP VPN的主要應用場景：

LAC和LNS介紹：

LAC是附屬在交換網絡上的具有PPP端系統和L2TP協議處理能力的設備，主要用於爲PPP類型的用戶提供接入服務
LAC位於LNS和用戶之間，用於在LNS和用戶之間傳遞信息包，它把用戶收到的信息包按照L2TP協議進行封裝並送往LNS，同時也將從LNS收到的信息包進行解封裝並送往用戶。LAC與用戶之間採用本地連接或PPP鏈路，VPDN應用中通常爲PPP鏈路。

LNS既是PPP端系統，又是L2TP協議的服務器端，通常作爲一個企業內部網的邊緣設備。
LNS作爲L2TP隧道的另一側端點，是LAC的對端設備 ，是LAC進行隧道傳輸的PPP會話的邏輯終止端點。通過在公網中建立LAC隧道，將用戶的PPP連接的另一端由原來的LAC在邏輯上延伸了企業網內部的LNS。

L2TP VPN主要有三種應用場景。分別是：

1. NAS-Initiated場景（撥號用戶訪問企業內網）

   NAS（Network Access Server）:是運營商用來向撥號用戶提供PPP/PPPoE接入服務的服務器，撥號用戶通過NAS訪問外部網絡。

   LNS（L2TP Network Server）是企業總部的出口網關。

   用戶通過PPPoE撥入LAC（L2TP Access Concentrator），觸發LAC和LNS之間建立隧道。接入用戶地址由LNS分配，對接入用戶的認證可由LAC側的代理完成，也可兩側都對接入用戶做認證。當所有L2TP用戶都下線時，隧道自動拆除以節省資源，直至再有用戶接入時，重新建立隧道。

   此組網適用於分支機構用戶向總部發起連接，且一般用於分支機構的用戶不經常訪問企業總部的情況。

圖：NAS-Initiated VPN隧道組網圖

2. LAC自動撥號

   LAC與LNS之間建立一條永久性L2TP會話。客戶端不用PPP撥號，而通過IP連接即可在隧道中傳輸數據。

   用戶通過配置觸發建立LAC與LNS之間的永久性L2TP會話。LAC使用存儲在本地的用戶名和LNS建立一個永久存在的L2TP隧道，此時的L2TP隧道就相當於一個物理連接。用戶與LAC之間的連接就不受限於PPP連接，而只需IP連接，LAC即可將用戶的IP報文轉發到LNS。

   這種組網也適用於分支機構接入總部，用於分支機構員工訪問總部頻率較高的情況。與NAS-Initiated VPN場景相比：

   • 分支機構員工感知不到隧道存在，不需要使用用戶名接入。LAC爲分支機構的多個用戶提供L2TP服務，免去了每個用戶使用L2TP都需要先撥號的麻煩。
   • 這種組網下，LNS只對LAC進行認證。其缺點爲：分支機構用戶只要能夠連接LAC即可使用L2TP隧道接入總部，而不需被認證。存在一定的安全隱患。此時用戶接入總部以通過設備的用戶認證功能對接入總部的用戶進行認證，從而提高安全性。

圖：LAC自動撥號組網示例

3. Client-Initiated場景（移動辦公用戶訪問企業內網）

   直接由接入用戶（可爲支持L2TP協議的PC）發起連接。此時接入用戶可直接向LNS發起隧道連接請求，無需再經過一個單獨的LAC設備。接入用戶地址的分配由LNS來完成。

   由於LNS端需要爲每個遠程用戶建立一條隧道，與NAS-Initiated VPN場景相比，LNS端配置更復雜一些。與其他兩種場景相比，其優點在於接入用戶不受地域限制。

   此場景適用於出差員工使用PC、手機等移動設備接入總部服務器，實現移動辦公。

圖：Client-Initiated組網示意圖

隧道和會話建立原理：

隧道和會話的概念：

在LNS和LAC對之間存在着兩種類型的連接。

隧道（Tunnel）連接：它定義了互相通信的兩個實體LNS和LAC。

• 在一對LAC和LNS之間可以建立多條隧道。隧道由一個控制連接和至少一個會話組成。

• L2TP首先需要建立L2TP隧道，然後在L2TP隧道上建立會話連接，最後建立PPP連接。所有的L2TP需要承載的數據信息都是在PPP連接中進行傳遞的。

會話（Session）連接：它複用在隧道連接之上，用於表示承載隧道連接中的每個PPP連接過程。

• 會話是有方向的，從LAC向LNS發起的會話叫做Incoming會話，從LNS向LAC發起的會話叫做Outgoing會話。

隧道和會話的關係：

• NAS-Initiated VPN場景中，一對LAC和LNS的鏈接可以存在多條隧道；一條隧道中可承載多條會話。即：多個用戶可以共用一條隧道。

• LAC自動撥號場景中，LAC和LNS建立永久的隧道。且僅承載一條永久的L2TP會話和PPP連接。

• Client-Initiated VPN場景中，每個接入用戶和LNS之間均建立一條隧道；每條隧道中僅承載一臺L2TP會話和PPP連接。

控制消息和數據消息：

**控制消息：**控制消息用於隧道和會話連接的建立、維護以及傳輸控制；位於隧道和會話建立過程中。控制消息的傳輸是可靠傳輸，並且支持對控制消息的流量控制和擁塞控制；主要的控制消息包括控制報文、會話報文等。

控制報文用於建立和拆除、維持隧道，主要包括：

• SCCRQ（Start-Control-Connection-Request）：控制連接發啓請求。由LAC或者LNS向對端發送，用來初始化LAC和LNS之間的隧道，開始隧道的建立過程。NGFW的應用場景中，一般都是由LAC向LNS發起請求。
• SCCRP（Start-Control-Connection-Reply）：表示接受了對端的連接請求，隧道的建立過程可以繼續。
• SCCCN（Start-Control-Connection-Connected）：對SCCRP的迴應，完成隧道的建立。
• StopCCN（Stop-Control-Connection-Notification）：由LAC或者LNS發出，通知對端隧道將要停止，控制連接將要關閉。另外，所有活動的會話都會被清除。
• HELLO：隧道保活控制消息。L2TP使用Hello報文來檢測隧道的連通性。LAC和LNS定時向對端發送Hello報文，如果在一段時間內未收到Hello報文的應答，隧道將被清除。

會話報文用於建立和拆除會話，主要包括：

• ICRQ（Incoming-Call-Request）：當LAC檢測到有用戶撥入電話的時候，向LNS發送ICRQ，請求在已經建立的隧道中建立會話。
• ICRP（Incoming-Call-Reply）：用來回應ICRQ，表示ICRQ成功，LNS也會在ICRP中標識L2TP會話必要的參數。
• ICCN（Incoming-Call-Connected）：用來回應ICRP，L2TP會話建立完成。
• CDN（Call-Disconnect-Notify）：由LAC或者LNS發出，通知對端會話將要停止。

數據消息：用於承載用戶的PPP連接數據報文，並在隧道上進行傳輸。數據消息的傳輸是不可靠傳輸，若數據報文丟失，不予重傳。不支持對數據消息的流量控制和擁塞控制。

NAS-Initiated VPN隧道和會話建立過程：

圖：NAS-Initiated VPN隧道和會話建立過程

1. 建立PPPoE連接

2. LAC對用戶進行認證。

3. 建立L2TP隧道

   L2TP數據以UDP報文形式發送。L2TP註冊了UDP端口1701，但是這個端口僅用於初始的隧道建立過程。L2TP隧道發起方（LAC）任選一個空閒端口（未必是1701）向接收方（LNS）的1701端口發送報文；LNS收到報文後，使用1701端口給LAC的指定端口回送報文。至此，雙方的端口選定，並在隧道保持連通的時間段內不再改變。

   1. LAC檢查用戶的LCP協商中的認證信息（Domain、Username等），查找能夠匹配的L2TP組，根據L2TP組的配置對某個LNS進行L2TP呼叫建立L2TP隧道。如果此時LAC發現L2TP隧道已經建立，則LAC發起會話連接，否則首先建立L2TP隧道。

   2. LAC端向指定的LNS發送CHAP challenge信息，LNS回送該challenge響應消息CHAP response，併發送LNS側的CHAP challenge，LAC返回該challenge的響應消息CHAP response。

      LAC和LNS之間通過SCCRQ、SCCRP和SCCCN消息完成L2TP隧道的建立，並且雙方都知道對方的Tunnel ID等信息，後續的數據報文都會添加Peer的Tunnel ID信息，這樣接收者就可以知道收到的L2TP報文屬於本地的哪個隧道。

4. 建立L2TP會話

   LAC和LNS使用ICRQ、ICRP和ICCN消息建立L2TP會話，這些消息都在前面建立的L2TP隧道中傳遞，並且都會添加隧道對端的Tunnel ID信息。

   在ICCN消息中，LAC端將用戶CHAP response、response identifier和PPP協商參數傳送給LNS，以便後續LNS與用戶建立PPP連接。

5. LNS根據用戶名、密碼等信息對用戶進行認證。

6. LNS對用戶進行二次認證（可選）

7. LNS對用戶在此認證（可選）

8. 用戶與LNS之間建立PPP連接。

   完成了L2TP會話以後，LAC會將Client的相關PPP參數通過L2TP會話轉發給LNS，LNS和用戶進行PPP的認證。

   LNS向用戶分配地址然後建立PPP連接，注意此時的PPP連接在用戶和LNS之間建立，並不是在LAC和LNS之間。

   此時的LAC也保持着和用戶的PPP連接，用於將來自LNS的L2TP數據報文解封裝以後通過PPP連接傳遞給Client。

9. 用戶訪問內網資源。

LAC自動撥號隧道和會話的建立：

與觸發建立隧道的方式不同，LAC自動撥號場景是無需觸發的永久隧道。一旦配置完畢，即可建立永久隧道，並承載唯一的一條永久會話。LAC爲LNS的唯一的客戶端。

圖：LAC自動撥號的隧道和會話建立過程

Client-Initiated VPN隧道和會話的建立：

Client-Initiated VPN場景下，隧道建立過程與NAS-Initiated VPN相似。與NAS-Initiated VPN場景相比，Client-Initiated VPN場景相當於將Client和LAC合爲了一個整體。

圖：Client-Initiated VPN隧道和會話建立過程

L2TP VPN的報文封裝：

NAS-Initiated VPN組網數據封裝過程：

圖：NAS-Initiated VPN場景組網報文封裝過程

NAS-Initiated VPN組網中，接入用戶訪問內網服務器時：

1. 當隧道和會話均建立完成後，接入用戶已獲取LNS分配的地址，並用此地址來訪問內網服務器。
2. 接入用戶向LAC發起PPPoE撥號，爲數據添加私有IP、PPP報文頭和PPPoE報文頭，並添加太網頭後，發送給LAC。
3. LAC收到報文後，依次剝離以太網頭、PPPoE報文頭，並對報文依次封裝L2TP報文頭、UDP報文頭，並添加公網IP，發送給LNS。
4. LNS收到報文後，首先對報文進行L2TP解封裝，依次剝離公網IP、UDP報文頭、L2TP報文頭。之後進行PPP解封裝，剝離PPP報文頭。最後添加以太網頭，並根據私有IP的目的地址將報文發送給內網服務器。
5. 服務器接收報文後，獲取報文數據，並將響應報文發送給LNS。

LAC自動撥號組網數據封裝過程：

圖：LAC自動撥號場景組網報文封裝過程

LAC自動撥號組網中，PPP封裝和L2TP封裝僅限於LAC和LNS之間的報文交互。

Client-Initiated VPN組網數據封裝過程：

圖：Client-Initiated VPN場景組網報文封裝過程

L2TP VPN的認證：

L2TP支持使用PAP和CHAP兩種方式進行PPP認證。

VT（Virtual-Template）接口：

PPP、Ethernet都是二層協議，它們之間不能直接互相承載。當用戶配置PPPoE等二層協議時，這些二層協議之間需要通過虛擬訪問接口VA（Virtual-Access）進行通信。前面已經提到，L2TP中會使用PPPoE協議。VT接口是用於配置虛擬訪問接口的模板。在L2TP會話連接建立之後，LAC、LNS均需要創建虛擬訪問接口用於和對端（即用戶）交換數據。此時，系統將按照用戶的配置，選擇VT接口，根據該模板的配置參數（包括接口IP地址、PPP認證方式等）動態地創建虛擬訪問接口。

命令行配置中，VT接口下可選擇CHAP或PAP認證方式來對用戶進行PPP認證。Web配置中不支持手工配置認證方式，系統優先選擇CHAP方式，其次選擇PAP方式。

LAC自主撥號場景：

LAC自主撥號場景中，LAC側不對用戶進行認證，只在LNS側對LAC配置的用戶進行PPP認證（PAP或CHAP）。在命令行配置中，體現在VT接口下配置的PPP認證方式。

Client-Initiated VPN場景：

Client-Initiated VPN場景中，在LNS側對用戶進行PPP認證（PAP或CHAP）。在命令行配置中，體現在VT接口下配置的PPP認證方式。

NAS-Initiated VPN場景：

NAS-Initiated VPN場景中，L2TP可對用戶進行兩次PPP認證：第一次發生在LAC側，第二次發生在LNS側。只有一種情況LNS側不對接入用戶進行二次認證：啓用LCP重協商後，不在相應的VT接口上配置認證。這時，用戶只在LAC側接受一次認證。

另外，不論對於LAC或LNS，如果其配置的用戶認證方式爲“不認證”，則不論VT接口中使用何種認證方式，都不對用戶進行認證。

以下對於認證方式的描述都是基於配置的用戶認證方式不爲“不認證”的情況。

• LAC端認證方式

  LAC端可對用戶進行PAP或CHAP認證。在命令行配置中，使用VT接口下配置的PPP認證方式。

• LNS端認證方式

  LNS對用戶的認證方式除由PPP認證方式決定外，還取決於配置的L2TP認證方式。L2TP認證方式有三種：代理認證、強制CHAP認證和LCP重協商。其中，LCP重協商的優先級最高，代理認證優先級最低。

  • LCP重協商

    如果需要在LNS側進行比LAC側更嚴格的認證，或者LNS側需要直接從用戶獲取某些信息（當LNS與LAC是不同廠商的設備時可能發生這種情況），則可以配置LNS與用戶間進行LCP重協商。LCP重協商使用相應VT接口配置的認證方式。此時將忽略LAC側的代理認證信息。

  • 強制CHAP認證

    如果只配置強制CHAP認證，則LNS對用戶進行CHAP認證，如果認證不通過，會話就不能建立成功。

  • 代理認證

    代理認證就是LAC將它從用戶得到的所有認證信息及LAC配置的認證方式傳給LNS，LNS會利用這些信息和LAC端傳來的認證方式對用戶進行認證。

    NAS-Initiated VPN中，在PPP會話開始時，用戶先和LAC進行PPP協商。若協商通過，則由LAC初始化L2TP隧道連接，並將用戶信息、認證信息等傳遞給LNS，由LNS根據收到的代理認證信息判斷用戶是否合法。

    代理認證與VT接口的PPP認證方式的關係：

    • LNS的PPP認證方式不能比LAC複雜。例如，如果LAC端配置的認證方式爲PAP，而LNS配置的PPP認證方式爲CHAP，則由於LNS要求的CHAP認證級別高於LAC能夠提供的PAP認證，認證將無法通過，會話也就不能正確建立。
    • 其他情況下，如果LNS與LAC的認證方式不一致，LNS將採用LAC發送過來的認證方式進行協商，忽略VT接口配置的認證方式。

---

三種組網模式的對比

三種組網對比：

• Client-Initiated VPN：其優點在於接入用戶不受地域限制。此場景適用於員工使用PC、手機等移動設備接入總部服務器，實現移動辦公。
• NAS-Initiated VPN：接入用戶（PC）通過PPPoE撥入LAC，由LAC通過Internet向LNS發起建立隧道連接請求。接入用戶地址由LNS分配，對接入用戶的認證可由LAC側代理完成，也可兩側都對接入用戶做認證。當所有L2TP用戶都下線時，隧道自動拆除以節省資源，直至再有用戶接入時，重新建立隧道。此組網適用於分支機構用戶向總部發起連接，且一般用於分支機構的用戶不經常訪問企業總部的情況。
• LAC-Auto：分支機構員工感知不到隧道存在，不需要使用用戶接入。LAC爲分支機構的多個用戶提供L2TP服務，免去了每個用戶使用L2TP都需要先拔號的麻煩
  這種組網下，LNS只對LAC進行認證。其缺點爲：分支機構用戶只要能夠連接LAC即可使用L2TP隧道接入總部，而不需被認證。存在一定的安全隱患。此時用戶接入總部以通過設備的用戶認證功能對接入總部的用戶進行認證，從而提高安全性

L2TP和PPTP區別：

• L2TP：公有協議、UDP1701、支持隧道驗證，支持多個協議，多個隧道，壓縮字節，支持三種模式
• PPTP：私有協議、TCP1723、不支持隧道驗證，只支持IP、只支持點到點

PPTP：

點對點隧道協議（PPTP）是由包括Microsoft和3com等公司組成的PPTP論壇開發的，一種點對點隧道協議，基於拔號使用的PPP協議使用PAP或CHAP之類的加密算法，或者使用Microsoft的點對點加密算法MPPE。

L2TP：

第二層隧道協議（L2TP）是IETF基於L2F（Cisco的2層轉發協議）開發的PPTP後續版本，是一種工業標準Internet隧道協議。

兩者的主要區別主要有以下幾點：

1. PPTP只能在兩端間建立單一隧道，L2TP支持在兩端點間使用多隧道，這樣可以針對不同的用戶創建不同的服務質量
2. L2TP可以提供隧道驗證機制，而PPTP不能提供這樣的機制，但當L2TP或PPTP與IPSec共同使用時，可以由IPSec提供隧道驗證，不需要在第二層協議上提供隧道驗證機制
3. PPTP要求互聯網絡爲IP網絡，而L2TP只要求隧道媒介提供面向數據包的點對點連接，L2TP可以在IP（使用UDP），FR，ATM，x.25網絡上使用
4. L2TP可以提供包頭壓縮。當壓縮包頭時，系統開銷（voerhead）佔用4個字節，而PPTP協議下要佔用6個字節

L2TP什麼情況下需要強制認證？

在NAS模式下。且LNS不信任LAC，配置了強制認證的情況下

---

參考文檔：華爲HedEx文檔。

---