數據包來回路徑不一致造成網絡不穩定

■湖北廣播電視大學教育技術中心 熊迪

隨著近年來高校信息化應用的不斷深入，對校園網絡的質量要求也日益增加。筆者作為一名高校網絡運維人員，在工作中遇到很多網絡上的“疑難雜癥”。其中“數據包來回路徑不一致”就是一個非常典型的校園網絡故障，我們對此現象進行了分析和研究，摸索出了一套解決辦法。

我們知道TCP/IP 協議中，兩臺主機要建立網絡連接，需要進行“三次握手”。“三次握手”的過程實質上就是來源主機與目的主機之間交互特定TCP 報文的過程。TCP 報文中包含“源地 址”（Source Port）和“目的地址”（Destination Port），分別反映了來往主機的地址及端口信息。建立連接時，主機A（簡稱A）向服務器B（簡稱B）發送SYN數據包，該數據包中源地址是A 的IP，目的地址是B 的IP；B 收到SYN 請求，將回復SYN+ACK 數據包，此時源地址是B 的IP，目的地址是A 的IP；A 收到以上數據包后，將發送ACK 確認包，連接成功。

圖1 數據包來回路徑不一致的典型案例

如果在這個過程中，源地址或者目的地址出現了變化，就會出現“數據包來回路徑不一致”，主機之間將無法識別對應的連接，導致網絡故障。

我們遇到的一個典型案例，網絡結構如圖1。服務器B 在防火墻上做了地址映射，其內網地址是10.0.0.13，映射后的互聯網公網地址是219.0.0.13，用戶A 的PC 內網地址是10.1.1.1，防火墻的內網口地址是10.10.2.2。

用戶A 反映：每次在校園網內訪問服務器B（219.0.0.13）上的應用，響應速度極慢，多數時候無法正常使用，偶爾能用，詢問其他的同事，少數人能正常訪問，多數人和他的網絡癥狀類似，奇怪的是當大家通過手機4G 網絡或在校外訪問服務器B 時一切正常。

圖2 數據包來回路徑不一致示意圖

通過對A、B 之間數據流的分析，我們發現用戶A 發出的請求數據包通過網關交換機傳遞到防火墻，防火墻將目的地址（服務器B的公網IP）進行NAT轉換變成服務器B 的內網地址，然后從防火墻的內網口經網關交換機傳送到服務器B。此時服務器B 收到的數據報文中“源地址”是10.1.1.1，“目的地址”是10.0.0.13。服務器B產生回應數據包，“源地址”是自身的10.0.0.13，“目的地址”是用戶A 的內網地址10.1.1.1。當此數據包到達網關交換機時，交換機發現“目的地址”是直連VLAN 中的IP，于是將直接轉發給用戶A，而不再經過防火墻。用戶A 將收到一個來自10.0.0.13（而非當初的請求地址219.0.0.13）的數據包，它將認為這是一個全新的連接，造成A、B 間通訊異常。如圖2 所示，這就是一個典型的“來回路徑不一致”造成的故障案例。由于4G 網絡用戶的IP 在校園網內無法轉發，所以未受到影響，訪問一切正常。

對于這種情況，市場上有些防火墻或路由設備設置了一些“保護措施”，筆者單位的防火墻設備正是如此。當防火墻發現對服務器B 的請求是來自內網接口（trust域）將觸發一條SNAT，將“來源地址”轉變成防火墻的內網口地址（即10.10.2.2），再以此為來源訪問服務器B。用這種方式保證服務器B 回包時數據流必須回到防火墻，從而回包路徑與請求包路徑保持一致。

這樣一來雖然解決了“來回路徑不一致”的問題，但又引發了一個新的問題。經抓包監測，服務器此時接收到大量來自防火墻內網口10.10.2.2 的訪問請求。服務器上的網絡安全系統將這些請求判定為異常的攻擊行為，采取了大量的“丟包”處理。這就是前文中提到的“少量用戶可以訪問服務器B，其他用戶訪問速度很慢”的原因。

對此，我們摸索出了兩套不同的解決方案：

1.在防火墻（或相應路由設備）上將來源地址進行一次主動的SNAT 處理，將用戶A 的IP 地址映射到校園網中“不可達”的某一網段中，迫使回應數據包必須依賴防火墻做轉發。同時，由于進行了主動的SNAT，所以即便訪問申請來自內網口，防火墻也不會觸發默認的地址轉換策略，避免出現統一訪問來源的現象。

2.如果是通過域名訪問服務器B，則在校內的DNS 服務器上進行域名劫持設置，直接將域名解析成服務器的內網地址，這樣校內用戶對服務器B 的訪問數據流只在校園網內（即網關交換機以下）流轉，相對安全且高效。

至此，問題得以解決。總結下來，網絡數據在傳輸過程中可能遇到各式各樣的問題，運維人員只有掌握原理，仔細分析才能找到有效的解決辦法。