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

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

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

圖1 數(shù)據(jù)包來回路徑不一致的典型案例

如果在這個過程中，源地址或者目的地址出現(xiàn)了變化，就會出現(xiàn)“數(shù)據(jù)包來回路徑不一致”，主機之間將無法識別對應(yīng)的連接，導致網(wǎng)絡(luò)故障。

我們遇到的一個典型案例，網(wǎng)絡(luò)結(jié)構(gòu)如圖1。服務(wù)器B 在防火墻上做了地址映射，其內(nèi)網(wǎng)地址是10.0.0.13，映射后的互聯(lián)網(wǎng)公網(wǎng)地址是219.0.0.13，用戶A 的PC 內(nèi)網(wǎng)地址是10.1.1.1，防火墻的內(nèi)網(wǎng)口地址是10.10.2.2。

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

圖2 數(shù)據(jù)包來回路徑不一致示意圖

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

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

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

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

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

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

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