寫這篇文章的初衷很簡單，就是給有需要的人提供一個處理類似問題的思路，這個故障其實很簡單，有經驗的應該可以直接判斷出來了，但是在沒有經驗且沒有遇到過這種問題的情況下，可以稍加借鑑一下，我這裏僅僅是寫出一個思路，有問題可以提出來一塊討論。原諒我塗掉了一些東西，輕拍...
最近在上架新設備的時候，替換舊設備的解析，在下發系統對該設備進行探測時直接報出了探測失敗的錯誤，涉及域名較多，首先我找到了下發系統負責人問他們錯誤原因，他們在下發系統設備上手動wget抓某個域名無法訪問，telnet 80端口是通的。
接着我要來了下發系統ip，查看訪問日誌，發現根本沒有訪問日誌，可是確實是訪問到了這個設備，並且探測設備也沒有收到狀態碼之類的信息，我在探測時候同時查看訪問日誌，也沒發現該ip的訪問記錄，所以判斷問題出在網絡層，沒有建聯成功，也沒有到應用層呢，於是決定抓包分析下原因。
一、
我固定某個域名的ip，打開瀏覽器訪問測試，結果如下：
有經驗的運維看到這個錯誤應該會大概猜出來問題出在哪裏了。
二、
瀏覽器訪問測試，鏈接被重置，直接無法訪問，於是登陸到重慶的一臺服務器，對該設備域名進行curl測試，並且兩端抓包，結果如下：
202爲客戶端，240爲server端
首先大概解釋一下這個三次握手數據包流程。
1、client端給server端發送syn包（無問題）
2、server端給client端發送syn，ack包（無問題）
3、4、client端給server端發送ack確認包和開始get數據（正常）
5、server端給client端發送了一個FIN，ack結束包（不正常）
6、7、client端給server端發送了一個ack確認包和fin，ack結束包（相對上一個包來看正常）
8、9、server端給client端發送了rst，ack包（不正常）
結論：
從以上可以看出在第4個包get數據之後開始出現不正常，且第二個包時候可以看到server端到client端ttl爲52
三、
這裏數據包傳輸就不多說了，我們注意看第5個包，server端到client端的時候，發送了一個FIN,ACK包，我們知道正常情況下這是不應該的，我們在注意看下面，TTL變成了118，與 上面結論中提到的ttl爲52不符合，且結合一中瀏覽器訪問的現象可以得出結果，這個server的機房出口很可能是做了防火牆的限制來控制域名的白名單等情況。
我們在server端查看抓到的數據包爲client端主動向server端發送了rst包，所以說機房出口或者某條路上有中間人在干擾正常訪問。不過要注意的是，“中間人”干擾這種方式並不 一定可以只根據ttl判斷出來，有的時候比較高明的干擾，ttl並不會太明顯的看出來，也存在有時候客戶端抓包中不會看到server端發送過來的FIN等異常數據包，因爲server端根本就懶 得理你。當然我們判斷異常的根本還是看三次握手的情況的。其實我們根據ttl有時候也可以大概的猜測出來這個“中間人”距離哪一端較近。
當然事無絕對，我寫出來這個的目的只是提供一些平時處理故障的思路而已，有不對或者描述不準確的地方還請大家指正。