MTU/MSS導(dǎo)致網(wǎng)站無法訪問

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

網(wǎng)絡(luò)結(jié)構(gòu)

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

故障現(xiàn)象

由于工作需要，近來網(wǎng)絡(luò)中新增了若干分支節(jié)點。為了減少兼容性問題，新增節(jié)點的網(wǎng)絡(luò)設(shè)備也采用與現(xiàn)有設(shè)備統(tǒng)一品牌產(chǎn)品。但是，由于原有設(shè)備型號已經(jīng)停產(chǎn)，只能選擇該品牌設(shè)備的后續(xù)型號。

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

故障分析

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

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

通過抓包發(fā)現(xiàn)，此次Web訪問過程中，完成了一次TCP三次握手，先后發(fā)出了兩次http數(shù)據(jù)get請求，并得到了一次響應(yīng)。第二次的get請求之后就發(fā)生了“Tcp Previous segment not captured”后續(xù)數(shù)據(jù)丟失，直至發(fā)送FIN指令終止連接。通過這次抓包可以看出，Web訪問實際上在網(wǎng)絡(luò)中已經(jīng)發(fā)生，但是由于某種原因?qū)е潞罄m(xù)數(shù)據(jù)丟失，才造成了我們無法訪問Web頁面的事實。

為排除網(wǎng)絡(luò)安全設(shè)備阻斷HTTP數(shù)據(jù)傳輸?shù)目赡?，我們做了一個試驗。將一臺視頻會商設(shè)備直接接到核心路由器的一個以太網(wǎng)接口，并訪問該設(shè)備的Web管理頁面，發(fā)現(xiàn)可以正常訪問Web頁面。這就排除中心節(jié)點安全設(shè)備攔截了那些數(shù)據(jù)表的可能。

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

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

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

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

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

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

故障解決

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

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

經(jīng)驗總結(jié)

其實，MTU長度差異導(dǎo)致的網(wǎng)絡(luò)故障在日常維護(hù)中也是時常會遇到的。對于本案例來說，新增節(jié)點時選擇同一品牌產(chǎn)品的目的，就是盡可能減少設(shè)備兼容性問題。然而，因為不同時期的產(chǎn)品技術(shù)實現(xiàn)細(xì)節(jié)上的差異，卻造成了組網(wǎng)過程中的怪異現(xiàn)象。

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