一次VPN隧道建立異常分析

一、故障現象：

    賓館無線上網使用者使用VPN客戶端無法與VPN閘道器正常建立VPN隧道， VPN客戶端一直停留在如下狀態：

 

二、環境介紹

1、賓館無線上網使用者經過運營商的NAT裝置（使用NAT POOL做的地址轉換）雙鏈路訪問網際網路；

2、無線使用者使用天融信的IPSEC VPN遠端客戶端，經過：運營商NAT裝置->網際網路->伺服器端路由器（目的地址轉化為天融信VPN外部介面地址）->天融信VPN閘道器（IP地址為：10.0.36.200通過路由器對外對映為公網地址61.54.245.3）建立VPN隧道；

三、隧道建立異常分析

1、通過故障現象，可以發現隧道無法建立時，顯示為正在協商，並且停止在協商第一階段：野蠻模式正在傳送第一個協商包，說明IPSEC VPN隧道建立異常，問題是出在協商過程；

2、從VPN客戶端截圖可以看到用於隧道內通訊的虛擬IP地址172.31.1.194已經獲取，表明客戶端在VPN閘道器注冊是成功的。到底是什麼原因造成的協商問題，一時無法定位，我們只能通過抓取異常時的資料包來分析了。
3、抓包分析（分別在VPN客戶端和VPN閘道器上抓包）

3.1、抓包之前，先了解下天融信VPN客戶端隧道建立過程

    天融信VPN客戶端與天融信VPN閘道器建立IPSEC VPN隧道的主要流程如下：

        1）VPN客戶端通過VPN閘道器的TCP 2012埠，在閘道器上進行註冊；這個過程閘道器上會判斷（可以通過使用者名稱+口令的形式，也可以通過證書的形式）該VPN客戶端使用者是否為閘道器上預先定義的合法使用者，如果是，將給客戶端分配一個虛擬地址用於加密隧道內的通訊；

2）VPN客戶端註冊成功後，客戶端會向閘道器的UDP 2012埠傳送通告，閘道器則向VPN客戶端傳送反向通告；

3）VPN客戶端通過野蠻模式進行第一階段協商；

4）第一階段協商成功的話，則通過快速模式進行第二階段協商；

5）如果第二階段協商成功，則IPSEC VPN隧道建立成功；

6）隧道建立成功，則可以實現VPN隧道內的安全訪問。

3.2、客戶端抓包分析

1）14—25資料包清晰的顯示了VPN客戶端向VPN閘道器注冊（使用的是TCP2012埠）的通訊過程，其中14—16三次握手建立通訊，17—21雙向傳輸資料包，22—25四次握手拆除連線。

2）314為VPN客戶端向VPN閘道器通告的通訊資料包，使用的是UDP 2012埠；

3）328為VPN客戶端與VPN閘道器之間相互協商的資料包，使用的是UDP500埠；

至此，僅從VPN客戶端抓包分析還無法定位故障，下面將繼續在VPN閘道器抓包分析。

3.3、VPN閘道器抓包分析

1）連線順序降序排列，從最下面第一個連線開始，很清晰得看到賓館客戶端出口地址222.88.150.43已經與服務端地址10.0.36.200在UDP 500埠上協商；
2）接著往上走發現資料包通訊埠由UDP 500變成UDP 4500（這是由於VPN客戶端是經過NAT訪問網際網路的，天融信的IV VPN客戶端支援NAT-T協議，所以在野蠻模式下，第三個資料包自動漂移到UDP 4500埠進行通訊了，具體參見RFC3947），大家看仔細啦，這裡不僅僅通訊埠變成4500，IP地址也變成218.28.16.242（聯通地址），繼續向上發現最頂端的那個UDP 500連線，IP地址是變化後的218.28.16.242，已經不是最早建立連線的出口地址222.88.150.43（電信地址），而這不是我們所期望的地址，看來這就是導致異常的原因啦。

    通過上面的資料包分析，我們可以清楚的發現：無線使用者在跟VPN閘道器建立隧道時，經過NAT裝置後，VPN客戶端資料包是以兩個不同的IP地址來跟VPN閘道器通訊的，因此VPN閘道器會將來自222.88.150.43的資料包丟棄，並且給218.28.16.242重傳資料包，導致隧道協商異常。

四、故障解決

    既然找到了故障根源，故障解決就比較好辦了，可以使用兩種方式：

1、讓 運營商修改其NAT裝置上的NAT POOL轉換、鏈路選擇演算法；　　
2、讓運營商給無線上網使用者採用固定鏈路地址NAT訪問網際網路。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26008584/viewspace-1098242/，如需轉載，請註明出處，否則將追究法律責任。