TTL (-190) 遠低於 ICMP 逾時封包的 ICMP 回顯應答封包

TTL (-190) 遠低於 ICMP 逾時封包的 ICMP 回顯應答封包

當我最後三跳從我的位置到 facebook.com 的追蹤路由路徑,我收到的 ICMP 回顯回覆封包都有一個TTL分別為58、57 和 56。有問題的躍點是我的機器的第 6、7 和 8 躍點。

另一方面,ICMP 超時訊息的 TTL對於在這三個躍點上過期的資料包,都具有合理的值:246、248、249。

現在回程路徑很可能與前進的道路不同類型的ICMP封包的情況也可能不一樣。

但這樣的差異又從何而來呢? 200跳循環沿著路徑?或使用低 TTL 產生 ICMP 回顯應答封包(遠低於 255:這會發生嗎?)?

答案1

根據使用者 kwaio 的建議,產生時使用的預設(或通用)TTL 值ICMP 回顯請求回顯回复數據包是64.

就我而言,我選擇的路徑上的第一個路由器使用 TTL=255(在來源處)的回顯回覆訊息進行回應,而最後一個路由器則使用 TTL=64。

相反,看起來ICMP 逾時在所有情況下創建的訊息的 TTL 均為 255。

經過一番挖掘,我發現不同的供應商和不同的作業系統對不同的協定採用不同的初始 TTL:binbert.com/blog/2009/12/default-time-to-live-ttl-values

一個有趣的含義是,您可以透過讓封包在該路由器上過期並向其發送 ping 來識別給定路由器的製造商。更多詳細資訊請參閱此處: 基於 TTL 的指紋辨識和 MPLS以及全文:“網路指紋:基於 TTL 的路由器簽章”

相關內容