MTU/MSS導致網站無法訪問

MTU即最大傳輸單元（Maximum Transmission Unit），該 值 是TCP/IP協 議中的一個重要參數值，用于描述協議數據單元承載的有效數據大小。MSS（Maximum Segment Size，最大報文長度），是TCP協議定義的一個選項，MSS選項用于在TCP連接建立時，收發雙方協商通信時每一個報文段所能承載的最大數據長度。超過MSS值的TCP報文在傳輸過程終將會被分段。對于不同類型的網絡，甚至同種類型網絡中不同品牌網絡設備默認定義MTU/MSS的大小都可能不同，設置合適的MTU/MSS值，可以解決部分“網站打不開”、“網速慢”等問題。本文就是由于一個典型的MTU/MSS值差異導致網站無法訪問的典型案例。

網絡結構

筆者單位的網絡結構如圖1所示，這是一個構建在共享網絡上的星型VPN網絡。核心路由器與每一個分支節點的接入路由器之間構建隧道模式的IPSec VPN網絡，所有分支節點之間的通信均通過核心路由器中轉，網絡中主要承載數據業務和視頻會商業務。為了便于業務管理和保證視頻會商質量，將每一個節點的局域網劃分為為20和30的兩個VLAN，兩個VLAN之間通過路由器以單臂路由形式互通。在核心路由器出接口配置服務質量控制，使視頻會商業務能夠擁有足夠的帶寬保證。

故障現象

由于工作需要，近來網絡中新增了若干分支節點。為了減少兼容性問題，新增節點的網絡設備也采用與現有設備統一品牌產品。但是，由于原有設備型號已經停產，只能選擇該品牌設備的后續型號。

采購設備到貨后，VPN很快就搭建完成。新增設備部署IPSec VPN時，除配置安全提議過程中有少數命令發生變化外，其余配置變化不大，這就是選擇統一品牌設備組網的好處。新增分支節點網絡中數據業務和視頻會商業務均工作正常，但奇怪的是，中心節點始終無法通過網絡訪問分支節點的視頻會商設備的Web管理頁面。為排查問題，詳細對比了新老設備構建VPN的安全提議、安全策略和默認參數配置，均未發現不同。在中心節點使用telnet工具連接新增分支節點的TCP 80端口，有正常響應。

故障分析

在這個組網方案中，新增節點與網絡中原有節點的差異是造成視頻設備Web管理頁面無法訪問的直接原因，這一點是十分明確的。解決這一故障的關鍵也在于找出新老節點之間的這種差異。

為了佐證上述判斷，做一個簡單的測試。由新增節點分別訪問新老節點的視頻設備Web管理頁面，我們發現，無論是新舊節點，都無法遠程訪問新節點的視頻設備Web管理頁面。那么，在訪問過程中到底發生了什么呢？這就需要用到抓包工具了。圖2是訪問新節點視頻會商設備Web管理頁面時的WireShark工具抓包截圖。

通過抓包發現，此次Web訪問過程中，完成了一次TCP三次握手，先后發出了兩次http數據get請求，并得到了一次響應。第二次的get請求之后就發生了“Tcp Previous segment not captured”后續數據丟失，直至發送FIN指令終止連接。通過這次抓包可以看出，Web訪問實際上在網絡中已經發生，但是由于某種原因導致后續數據丟失，才造成了我們無法訪問Web頁面的事實。

為排除網絡安全設備阻斷HTTP數據傳輸的可能，我們做了一個試驗。將一臺視頻會商設備直接接到核心路由器的一個以太網接口，并訪問該設備的Web管理頁面，發現可以正常訪問Web頁面。這就排除中心節點安全設備攔截了那些數據表的可能。

找出這些后續數據報文被攔截的位置，是查找問題的一條途徑。由于IPSec VPN采用的是隧道模式，數據在隧道中傳輸過程中是被加密的，很難定位數據報文被攔截的準確位置。另一條途徑就是通過兩次http請求后響應數據報文的差異，來分析后續數據報文被丟棄的原因。

通過對TCP協議的摘要信息進行比較，除了索引號外，最大區別就在于TCP數據報文長度。第一次響應的TCP數據報文大小為451，而被丟棄的數據報文是1460。接下來出場的就是ping工具，格式為“ping -f -l[承載數據大小] IP地址 ]”，“-f” 參數強制 ICMP協議數據負載不會被拆分。經過反復嘗試，發現承載數據為1415是一個分界點。

只有小于等于1415的負載能夠通過VPN網絡。而在原有分支節點和中心節點網絡中，這個分界點是1472。有了這一結論，嘗試對視頻會商設備的MTU進行修改，將其改為1400，再訪問其Web，果然管理頁面正常打開了。

修改視頻設備MTU值起到了限制承載數據大小的目的，但這不是問題的癥結，問題仍在新增加的路由器上。因為我們不能每次增加一個設備都去調整設備的MTU值，這樣太不人性化了。MTU只是規定了這個設備的TCP數據報最大負載，只有像使用ping -f時明確配置了報文不分段的情況下，超過協商值的數據報文將會被丟棄。

顯然，視頻會商設備的Web頁面不太可能進行這種配置，那么問題就很可能出現在報文分段尺寸上。默認情況下，MSS值通常被設為1460，即超過載荷超過1460bit時數據報文將會在進行IP封裝時被分段。我們之前使用Wireshark進行抓包比較時也發現，被丟棄的數據報文大小一致。試想，如果以1460的MSS來拆分TCP報文，那么產生的IP報文將無法通過載荷只有1415bit的IPSec隧道。這也能夠解釋為什么客戶端和服務器之間完成了TCP協議的三次握手和HTTP協議的兩次get通信，并在報文丟失后發送了FIN信號終止連接。因為，這些報文承載數據長度都很小，遠遠沒有達到1415bit的最大傳輸單元的尺寸。

為什新增分支節點可以訪問原有節點的Web管理頁面呢？我想那是因為原有設備的最大分段長度是小于1415的，產生的分段報文能夠正常通過隧道。

故障解決

已經明確了問題的癥結所在，所要做的就是調整新增節點路由設備出口的MSS，通過調整TCP報文分段保證產生的T報文長度小于VPN隧道最大傳輸單元長度，即可防止長生超過限制的超大數據載荷。

具體做法是，在新增節點路由器外網口配置“tcp mss1400”，將路由器最大分段長度設為1400，這樣超過1400bit的載荷TCP報文將會被拆分。經測試，調整后所有節點的視頻設備Web管理頁面均可以正常訪問了，至此問題圓滿解決。

經驗總結

其實，MTU長度差異導致的網絡故障在日常維護中也是時常會遇到的。對于本案例來說，新增節點時選擇同一品牌產品的目的，就是盡可能減少設備兼容性問題。然而，因為不同時期的產品技術實現細節上的差異，卻造成了組網過程中的怪異現象。

對于這樣的問題，要求維護人員能夠準確理清數據流向，綜合利用多種工具和方法，定位故障，盡可能在網絡基礎設施層面解決問題。不要將解決問題的著力點放到終端服務中，否則結果很可能是摁倒了葫蘆瓢又起。