IPsec PPTP L2TP 的差異

穿隧技術 (Tuneling)：穿隧技術是為了將私有數據網路的資料在公眾數據網路上傳輸，所發展出來的一種資料包裝方式(Encapsulation)，亦即在公眾網路上建立一條秘密通道。現在穿隧技術所使用的協定主要有：IPsec、PPTP 及 L2TP 等三種。

• IPsec (IP Secruity)：為第三層的穿隧技術，專門為 IP 所設計不但符合現有 IPv4 的環境，同時也是 IPv6 的標準，它也是 IEIF 所制定的業界標準,目前 IETF 從 1995 年起，陸續公佈許多網路安全之相關技術標準。這些標準統稱為 IPSec (IP Security)，可參考 [RFC 1825]、[RFC 1826]、[RFC 1827]、[RFC 1828]、[RFC 1829]、[RFC 1851]、[RFC 2085]、[RFC 2104]
• PPTP(Point to Point Tunneling Protocol)：定義了一個主從式的架構，主要是由 PNS (PPTP Network Server) 和 PAC (PPTP Access Concentrator) 組成的機制，乃是透過這個機制來支援 VPN 的功能。將 IP、IPX 或 NetBEUI 通訊協定封裝在 IP 封包中，並使用 TCP 方式來交換加密通道的維護訊息。
• L2TP (Layer 2 Tunneling Protocol)：結合 Layer-2 Forwarding (L2F) 和 PPTP 的協定由 IETF 所提出的一個資料連結層的加密通訊協定。

PPTP 與 L2TP 均為第二層的穿隧技術，適合具有 IP/IPX/AppleTalk 等多種協定的環境。IPsec、PPTP、L2TP 三者，最大的不同在於運用 IPsec 的技術，使用者可以同時使用 Internet 與 VPN 的多點傳輸功能 (包括 Internet/Intranet/Extranet/Remote Access...等)，而 PPTP 及 L2TP 只能執行點對點 VPN 的功能，無法同時執行 Internet 的應用，使用時較不方便而在安全性方面，IPSec 會對整個傳輸資料做加密而 PPTP 及 L2TP 則是僅針對封包的再包 (Encapsulation) 並未對資料做加密處理，安全性相對較低。

以下引用微軟的文章
通道可將一種通訊協定類型中的封包封裝在另一個通訊協定的資料包中。例如，VPN 使用 PPTP 透過公用網路 (例如，網際網路) 來封裝 IP 封包。可以設定以「點對點通道通訊協定」(PPTP)、「第二層通道通訊協定」(L2TP) 或「安全通訊端通道通訊協定」(SSTP) 為基礎的 VPN 解決方案。
PPTP、L2TP 和 SSTP 高度倚賴一開始指定給「點對點通道通訊協定」(PPTP) 的功能。PPP 是專為透過撥號或專用點對點連線傳送資料所設計。對於 IP，PPP 將 IP 封包封裝於 PPP 框架內，然後透過點對點連結傳輸封裝的 PPP 封包。PPP 一開始定義為在撥號用戶端和網路存取伺服器之間使用的通訊協定。

PPTP

PPTP 允許加密多重通訊協定流量，然後封裝在 IP 標頭裡，以透過 IP 網路或公用 IP 網路 (例如，網際網路) 傳送。PPTP 可用於遠端存取和站對站 VPN 連線。在使用網際網路作為 VPN 的公用網路時，PPTP 伺服器是啟用 PPTP 的 VPN 伺服器，一個介面在網際網路上，而第二個介面在內部網路上。

封裝

PPTP 將 PPP 框架封裝在 IP 資料包中以便透過網路傳輸。PPTP 使用 TCP 連線進行通道管理，並使用 Generic Routing Encapsulation (GRE) 的修改版來封裝通道資料之 PPP 框架。封裝之 PPP 框架的承載可以加密、壓縮，或兩者皆使用。下圖顯示包含 IP 資料包的 PPTP 封包之結構。
包含 IP 資料包的 PPTP 封包之結構

加密

PPP 框架使用 MS-CHAP v2 或 EAP-TLS 驗證程序產生的加密金鑰，來以 Microsoft 點對點加密 (MPPE) 進行加密。虛擬私人網路用戶端必須用 MS-CHAP v2 或 EAP-TLS 驗證通訊協定，才能夠加密 PPP 框架的承載。PPTP 利用基本 PPP 加密，並封裝先前加密的 PPP 框架。

L2TP

L2TP 允許加密多重通訊協定流量，然後透過任何支援點對點資料包傳送的媒體 (例如：IP 或非同步傳輸模式 (ATM)) 來傳送。L2TP 是 PPTP 和「第二層轉送」(L2F) 的組合，這是 Cisco Systems, Inc. 所開發的技術。L2TP 可呈現 PPTP 和 L2F 的最佳功能。
和 PPTP 不同，Microsoft 所執行的 L2TP 不使用 MPPE 來加密 PPP 資料包。L2TP 仰賴「傳輸模式」中的「網際網路通訊協定安全性」(IPsec) 來進行加密服務。L2TP 和 IPsec 的組合即所謂 L2TP/IPsec。
VPN 用戶端和 VPN 伺服器都必須支援 L2TP 和 IPsec。L2TP 的用戶端支援內建於 Windows Vista® 和 Windows XP 遠端存取用戶端，而 L2TP 的 VPN 伺服器支援內建於 Windows Server® 2008 和 Windows Server 2003 家族的成員中。
L2TP 是使用 TCP/IP 通訊協定來安裝。

封裝

L2TP/IPsec 封包的封裝包含兩個層級：

第一層：L2TP 封裝

將 PPP 框架 (IP 資料包) 包裝於 L2TP 標頭和 UDP 標頭。
包含 IP 資料包的 L2TP 封包之結構

第二層：IPsec 封裝

然後將結果 L2TP 訊息包裝在 IPsec「封裝安全承載」(ESP) 標頭和尾端、提供訊息完整性及驗證的 IPsec 驗證尾端，然後是最終 IP 標頭。在 IP 標頭中的是對應到 VPN 用戶端和 VPN 伺服器的來源及目的地 IP 位址。
以 IPsec ESP 加密 L2TP 流量

加密

L2TP 訊息可使用「網際網路金鑰交換」(IKE) 交涉處理產生的加密金鑰，以「資料加密標準」(DES) 或「三重資料加密標準」(3DES) 進行加密。

SSTP

「安全通訊端通道通訊協定」(SSTP) 是新的通道通訊協定，透過 TCP 通訊埠 443 使用 HTTPS 通訊協定，將流量傳遞通過可能會封鎖 PPTP 和 L2TP/IPsec 流量的防火牆和網路 Proxy。SSTP 提供透過 HTTPS 通訊協定的「安全通訊端層」(SSL) 通道來封裝 PPP 流量的機制。使用 PPP 可支援強式驗證方法，如 EAP-TLS。SSL 利用增強金鑰交涉、加密和完整性檢查來提供傳輸層安全性。
當用戶端嘗試建立以 SSTP 為基礎的 VPN 連線時，SSTP 首先會建立 SSTP 伺服器的雙向 HTTPS 層。透過此 HTTPS 層，通訊協定封包可如資料承載一般傳送。

封裝

SSTP 將 PPP 框架封裝在 IP 資料包中以便透過網路傳輸。SSTP 使用 TCP 連線 (透過通訊埠 443) 來進行通道管理，和 PPP 資料框架一樣。

加密

SSTP 訊息是以 HTTPS 通訊協定的 SSL 通道進行加密。

選擇通道通訊協定

當您要在 PPTP、L2TP/IPsec 和 SSTP 遠端存取 VPN 解決方案中做選擇時，請考量下列事項：

• 許多 Microsoft 用戶端都能使用 PPTP，包括 Microsoft Windows 2000、Windows XP、Windows Vista 以及 Windows Server 2008。和 L2TP/IPsec 不同，PPTP 不需要使用公開金鑰基礎結構 (PKI)。透過使用加密，以 PPTP 為基礎的 VPN 連線可機密地提供資料 (沒有加密金鑰就無法解譯擷取的封包)。但是，以 PPTP 為基礎的 VPN 連線不提供資料完整性 (證明資料在傳輸途中沒有修改) 或資料來源驗證 (證明資料是由授權的使用者所傳送)。
  
• L2TP 只能夠在執行 Windows 2000、Windows XP 或 Windows Vista 的用戶端電腦使用。L2TP 支援電腦憑證或預先共用金鑰作為 IPsec 的驗證方法。電腦憑證驗證 (建議的驗證方法) 必須要有 PKI 來簽發電腦憑證給 VPN 伺服器電腦和所有 VPN 用戶端電腦。透過使用 IPsec，L2TP/IPsec VPN 連線可提供資料機密性、資料完整性和資料驗證。
  
  和 PPTP 及 SSTP 不同，L2TP/IPsec 在 IPsec 層啟用機器驗證，而在 PPP 層啟用使用者層級驗證。
  
• SSTP 只能夠在執行 Windows Vista Service Pack 1 (SP1) 或 Windows Server 2008 的用戶端電腦使用。透過使用 SSL，SSTP VPN 連線可提供資料機密性、資料完整性和資料驗證。
  
• 三種通道類型均將 PPP 框架攜帶於網路通訊協定堆疊的最上層。因此，PPP 的一般功能 (例如，驗證機制、第四版網際網路協定 (IPv4)、第六版網際網路協定 (IPV6) 交涉，以及網路存取保護 (NAP)) 仍然和三種通道類型一樣。
  

其他參考資料

• PPTP 記載於 IETF RFC 資料庫的 RFC 2637 文件 (可能為英文網頁)
  
• L2TP 記載於 IETF RFC 資料庫的 RFC 2661 文件 (可能為英文網頁)
  
• L2TP/IPsec 記載於 IETF RFC 資料庫的 RFC 3193 文件 (可能為英文網頁)

ref:http://life.different.idv.tw/index.php?op=printView&articleId=37&blogId=1

PPPoE Operation

Stages

PPPoE has two stages:

• Discovery stage - a client discovers all available access concentrators and selects one of them to establish PPPoE session.This stage has four steps: initialization, offer, request and session confirmation . PPPoE Discovery uses special Ethernet frames with their own Ethernet frame type 0x8863.

To initiate discovery, PPPoE client sends PADI frame to the broadcast Ethernet address (FF:FF:FF:FF:FF:FF) and may specify particular service name.

When server receives PADI frame, it responds with PADO frame to Client's unicast Ethernet address. There can be more than one server in broadcast range of the client. In such case client collects PADO frames and picks one (in most cases it picks the server which responded first) to start session.

Client sends PADR frame to unicast Ethernet address of the server it chose. If server agrees to set up a session with this particular client, it allocates resources to set up PPP session and assigns Session ID number. This number is sent back to client in PADS frame. When client receives PADS frame, it knows servers mac address and Session ID, it allocates resources and session can begin.

• Session - When discovery stage is completed, both peers know PPPoE Session ID and other peer's Etehrnet (MAC) address which together defines PPPoE session. PPP frames are encapsulated in PPPoE session frames, which have Ethernet frame type 0x8864.
  When server sends confirmation and client receives it, PPP Session stage is started that consists of following steps:
  • LCP negotiation
  • Authentication
  • IPCP negotiation - client is assigned with an IP address.

PPPoE server sends Echo-Request packets to the client to determine the state of the session, otherwise server will not be able to determine that session is terminated in cases when client terminates session without sending Terminate-Request packet.

More detailed description of PPPoE protocol can be found in RFC 2516

Used Packet Types

Packet	Description
PADI	PPPoE Active Discovery Initialization The PPPoE client sends out a PADI packet to the broadcast address. This packet can also populate the "service-name" field if a service name has been entered on the dial-up networking properties of the PPPoE broadband connectoid. If a service name has not been entered, this field is not populated
PADO	PPPoE Active Discovery Offer The PPPoE server, or Access Concentrator, should respond to the PADI with a PADO if the Access Concentrator is able to service the "service-name" field that had been listed in the PADI packet. If no "service-name" field had been listed, the Access Concentrator will respond with a PADO packet that has the "service-name" field populated with the service names that the Access Concentrator can service. The PADO packet is sent to the unicast address of the PPPoE client
PADR	PPPoE Active Discovery Request When a PADO packet is received, the PPPoE client responds with a PADR packet. This packet is sent to the unicast address of the Access Concentrator. The client may receive multiple PADO packets, but the client responds to the first valid PADO that the client received. If the initial PADI packet had a blank "service-name" field filed, the client populates the "service-name" field of the PADR packet with the first service name that had been returned in the PADO packet.
PADS	PPPoE Active Discovery Session confirmation When the PADR is received, the Access Concentrator generates a unique session identification (ID) for the Point-to-Point Protocol (PPP) session and returns this ID to the PPPoE client in the PADS packet. This packet is sent to the unicast address of the client.
PADT	PPPoE Active Discovery Terminate might be sent anytime after a session is established to indicate that a PPPoE session terminated. It can be sent by either server or client.

MTU

Typically largest Ethernet frame that can be transmitted without fragmentation is 1500 bytes. PPPoE adds another 6 bytes of overhead and PPP field adds two more bytes, leaving 1492 bytes for IP datagram. Therefore max PPPoE MRU and MTU values must not be larger than 1492.

TCP stacks try to avoid fragmentation, os they use an MSS (Maximum Segment Size). By default MSS is chosen as MTU of the outgoing interface minus the usual size of the TCP and IP headers (40 bytes), which results in 1460 bytes for an Eternet interface. Unfortunately there may be intermediate links with lower MTU which will cause fragmentation. In such case TCP stack performs path MTU discovery. Routers which cannot forward the datagram without fragmentation are supposed to drop packet and send ICMP-Fragmentation-Required to originating host. When host receives such ICMP, it tries lower MTU. This should work in ideal world, however in real world many routers do not generate fragmentation-required datagrams, also many firewalls drop all ICMP datagrams.

Workaround for this problem is to adjust MSS if it is too big. By default RouterOS adds mangle rules to intercept TCP SYN packets and silently adjust any advertised MSS option so they will be appropriate for the PPPoE link.

Additional information on maximum supported MTUs for routerboards are listed here.