前言：
這篇隨筆是最近處理的一起真實網絡故障分析案例，特此分享給身邊同行的朋友。
故障介紹：
公網這台服務器通過http協議與分支內部的一台服務器做業務交易，當公網服務器向分支這台內部服務器發起http請求做交易時，結果無響應，這也意味着是一次失敗的業務交易。多次嘗試，結果依然是無響應，由此展開了故障排查工作。排查的過程中客戶回憶到是在某一個時刻打完網站補丁后，出的交易故障，客戶建議卸載補丁試試看能不能恢復，此時服務器管理員卸載了補丁后，業務交易正常。（最后通過排查實際上並不是因為服務器補丁問題，而是網絡問題導致的，打補丁只是恰巧碰到了問題。）
網絡架構如下：
1、總部內部詳細網絡結構忽略不計，兩台服務器的交互流量不經忽略的網絡節點
2、此網絡原本是高可靠冗余設備架構，為方便描述，在圖中省略了備份設備，可忽略。
3、抗DDoS設備可當做流量透傳，無業務口IP無路由，只做安全防護。
4、負載均衡設備配置公網IP、並配置有SNAT、DNAT轉換。公網服務器訪問到總部經過總部負載均衡時，源目IP以及源目端口都將被轉換。
5、兩台山石防火牆通過各自的負載均衡端口映射來建立ipsec vpn。
6、分支山石防火牆與天融信防火牆都做了地址轉換與端口映射。
7、以下圖片是服務器交互流量路徑示意圖。
故障處理過程：（以下描述中客戶端側表示公網服務器，服務器側表示分支內網的服務器）
1、向客戶了解業務故障的基礎信息，由於是http協議，那么切入點直接從tcp連接是否正常開始，經確認兩端tcp連接正常。這個時候基本可以判斷以下幾點：
負載均衡未充當代理，只做網絡層IP地址和傳輸層端口轉換：
①兩台服務器的tcp連接正常，可以排除異步路由問題。
②兩台服務器的tcp連接正常，可以排除到傳輸層的安全策略問題。
2、由於向客戶了解到是ipsec vpn環境，那么接下來思考的問題應該是MTU問題，我們知道在ipsec vpn的場景中會增加鏈路的開銷，其表現為數據經過ipsec封裝以后會增加 額外的ESP頭部、AH頭部、UDP頭部以及外層IP頭部。這個時候我們應該采取手段使數據被ipsec封裝以后的數據包大小小於MTU大小（1500字節）
①默認情況下，接口MTU=1500，所以兩台服務器建立TCP連接的時候，TCP MSS=1460字節（1500字節-IP頭部20字節-TCP頭部20字節），最終TCP MSS也會協商為1460 字節。
②由於協商的TCP MSS為1460字節，那么也就意味着當服務器產生大包的時候，tcp的payload最大為1460字節，再加上常規tcp頭部20字節和常規ip頭部20字節，總共為1500字節。當這個數據路由到山石防火牆時，山石防火牆通過ipsec封裝數據以后，那么數據包大小應接近1600字節，此時已超過接口MTU最大值1500字節，會發生丟包。
③通過以上分析，可以調節客戶端側或者服務器側的MTU值為1400字節，建議調節客戶端側，服務器不止對這一個客戶提供服務（影響較大）
④當客戶端側更改MTU為1400字節以后，業務依然無響應，此時可以排除ipsec vpn環境MTU值影響丟包。
3、通過基礎的診斷和測試以后，那么最后只剩下通過抓包來一探究竟。
抓包節點選取：
①客戶端側和服務器側，都抓取本地業務接口流量。
②總部山石防火牆上行接口流量抓取。
③分支山石防火牆和天融信防火牆不限定接口流量抓取。
④負載均衡不需要抓，因為流量經過了ipsec封裝，看不到實際數據。
在進行抓包的過程中，需要考慮以下問題：
①數據的訪問都經過了NAT轉換，由於定義的地址池不確定接下來的數據包會轉換成什么地址，這個時候定義的抓包規則最適合的也就是根據目的IP和目的端口來抓，抓取雙向流量，則定義兩條。
②由於此服務器不僅對接這一個客戶，當訪問的流量經過地址轉換過后，很難確定發起者的數據包是哪一個。那么如何能夠准確的找到業務發起者的數據包呢？
4、把抓包的環境都准備好后，那么緊接着就是客戶端側發包測試了。抓包結果如下：
分析思路：
由於交互的數據經過網絡設備轉發的時候經過了NAT轉換，如果想要找到交互的流量包絕非易事。
①可以通過在NAT設備上查詢NAT會話信息來確定數據包的源IP以及端口信息，因為這種方式需要在每一層NAT設備上查看會話信息才能找到數據包，而且是依靠上一個NAT會話信息來到下一個設備上再查詢NAT會話，以此類推。過程繁瑣且復雜（此種方式不推薦 ）
②可以通過客戶側發起端的數據包來定位其他節點抓取的業務交互數據包，這樣即快速又准確。
客戶端側抓包如下：避免暴露用戶信息，交互的IP地址被隱
根據以上截圖信息可以得到什么結果呢？
①根據標記的紅色窗體數據，服務器回應的seq 918，ack 1136就可以初步判斷服務器回的包有丟失現象。為什么單憑這個信息就可以判斷服務器的回復包有丟失呢？
因為，根據以上紅色窗體數據，客戶端總共發了379+756=1135字節的數據，而服務器回復的包seq 918，ack 1136。ack這個字段沒任何問題，有問題的是seq 918，因為這意味着服務器之前是有發過一個數據seq 1，ack=1136，tcp length=917的數據，但在客戶端側卻未抓取到。
②接下來就要分析其他節點抓取的數據包了，看看在哪里發生了丟包。那么我們如何依靠客戶端側的抓的流量來快速准確的定位其他節點抓到的對應數據包了？
我們的網絡環境並沒有代理的環境，那么想找到數據包是輕而易舉的。雖然數據包在傳輸的過程中經過了N多次地址轉換和端口轉換，但僅僅改變的只是IP頭部中源IP和目的IP值，TCP頭部中源端口和目的端口的值。這樣就可以根據頭部中的其他字段來定位數據包。有以下一些字段可以使用定位：
IP頭部中：Identification（截圖中的ID字段）
TCP頭部中：seq、ack數值，tcp length長度（不是非常准確，可能會與其他客戶端發的數據大小一致），以及tcp option中的等等字段
③定位到數據流以后，就直接找丟失的數據包（seq 1，ack 1136 tcp length 917）
服務器抓包信息有此丟失的數據包，天融信防火牆也有此丟失的數據包，山石防火牆上也有此丟失的數據包（並且顯示進了ipsec vpn隧道），但在總部山石上未找到此丟失的數據包。這個時候就可以縮小故障節點范圍了。
可能在這些節點發生丟包：分支負載均衡-分支抗DDoS-運營商-總部抗DDos-總部負載均衡
④從負載均衡上抓包幾乎沒有意義，數據包通過ipsec封裝后，數據被加密無法判斷是否有丟失的數據包經過
⑤運營商丟包的可能性極小，因為ipsec隧道中的流量僅僅只是（seq 1，ack 1136 tcp length 917）這個數據包被丟棄
⑥進而將目標轉移到抗DDoS上，通過查看抗DDoS上的日志信息，竟然有丟棄ipsec使用的公網源目IP的流量，而且還很頻繁。單憑這個日志信息無法確定有沒有丟棄我們所關注的數據包。
⑦隨后在抗DDoS上新增了一條訪問控制規則，將ipsec使用的源目公網IP添加到放行規則，再觀察日志丟棄情況，觀察了2-3分鍾，發現沒有了丟棄現象。
⑧接下來讓客戶端側再發起交易的流量，竟有了響應。也就說明了客戶端側與服務器的交互流量正常，未丟失。反復測了幾次都正常。
⑨關於抗DDoS上的丟包日志無實際參考意義，提示的日志信息是無效的udp頭部，可以肯定的是數據包的組包結構是沒有問題的，數據也是正常的大小。為什么那么多數據包每次都丟（seq 1，ack 1136 tcp length 917）這個數據包呢？令人匪夷所思！！！
⑩由於測試在抗DDoS上添加的放行規則有安全風險（如果分支或總部內部主機失陷被控制的話，發出大量flood包會被抗DDoS直接放行不會攔截），最后通過升級抗DDoS的軟件版本徹底解決了無腦丟棄數據包問題，也隨之取消了放行規則。