本期分享的案例是有線網絡的相關問題。

背景介紹

一朋友在是某單位的IT管理，出口路由用的是某P的設備靜態公網IP，其一直耿耿于懷，我也不知道為什么。近期發現，遠程PC通過互聯網訪問出口路由器的web管理頁面失敗，表現為能加載一部分信息，但是沒有彈窗登錄頁面：

于是很高興地瘋狂投訴某P售后，結果人家檢查了設備沒問題而是線路問題。很不甘心，求助于我，如果是產品問題直接走法律程序賠償。我不知道為何他執念為何那么深，給他做了簡單的排查。

排查分析

第一步：對比測試

原拓撲：

測試結果：PC打開瀏覽器，通過路由器公網IP+端口號，無法打開路由Web管理頁面和登錄。

對比拓撲：

測試結果：PC打開瀏覽器，通過路由器公網IP+端口號，正常打開路由Web管理頁面并正常登錄

一般情況來講，正常人到這一步大概差不多了，是否經過ISP運營鏈路導致的異常其實對比很明顯。此人又較真：“路由器接入了寬帶后自己功能異常了，兼容性太垃圾，直連PC這種做不得數。需要專業的排障，抓個包看看。”我：“有道理，那就在原拓撲下，抓個包看看”

第二步：報文分析

抓包自然是要抓取鏈路收尾兩端的報文，第一個是遠程PC接口報文，第二個是路由器GE1（WAN）口報文，同時比對丟包情況才能分析出問題，如下：

抓取訪問Web頁面異常時遠程筆記本出接口的報文，如下：

可以看到加載部分資源的TCP會話一直SYN重傳沒有建立起來，并結合瀏覽器F12調試可分析應該是嘗試去加載jpg圖片、JS文件資源時握手失敗。下面就看看路由器那邊有沒有收到握手的請求了。

抓取訪問Web頁面異常時某P路由器出口GE1接口的報文，如下：

發現會話都是正常的，沒有異常的會話，說明客戶端請求圖片、JS資源的TCP SYN請求沒有過來。

綜合分析：

訪問路由器Web頁面的部分會話是成功了，但是部分資源會話的請求卻沒有過來，也就是路由器的GE1接口沒有收到，基本確認是中間運營商鏈路丟包導致。

解決方案

找運營商確認或者更換鏈路對比試一下，但這老哥覺得我分析可能漏了些細節，欺負他看不懂報文。So，what can i say？朋友們，對于一個品牌你們會有這么大的惡意么？