☰

為什麼追蹤路由在目的地之後以額外的躍點結束？

tag-icon • tag-icon traceroute
為什麼追蹤路由在目的地之後以額外的躍點結束？

如果沒有任何東西阻止流量，traceroute通常會以目標 IP 作為最後一跳結束。 （本例為 10.1.1.10）

正常的話traceroute會是這樣的。

user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
 1  10.2.8.2 (10.2.8.2)  0.572 ms  0.692 ms  0.837 ms
 2  10.1.9.50 (10.1.9.50)  202.638 ms 10.1.9.78 (10.1.9.78)  202.547 ms 10.1.9.50 (10.1.9.50)  202.139 ms
 3  10.1.4.9 (10.1.4.9)  202.508 ms  202.483 ms 10.1.4.13 (10.1.4.13)  204.149 ms
 4  10.1.1.10 (10.1.1.10)  202.133 ms  202.100 ms  202.692 ms
user@linux:~$

最近，我遇到一個問題，輸出中存在額外的躍點 (10.1.1.9) traceroute（查看躍點 5）。

來源IP位址：10.2.8.8

user@linux:~$ ifconfig | head -2
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.2.8.8  netmask 255.255.255.0  broadcast 10.2.8.255
user@linux:~$

目標IP位址：10.1.1.10

附加躍點：10.1.1.9 ???

user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
 1  10.2.8.2 (10.2.8.2)  0.572 ms  0.692 ms  0.837 ms
 2  10.1.9.50 (10.1.9.50)  202.638 ms 10.1.9.78 (10.1.9.78)  202.547 ms 10.1.9.50 (10.1.9.50)  202.139 ms
 3  10.1.4.9 (10.1.4.9)  202.508 ms  202.483 ms 10.1.4.13 (10.1.4.13)  204.149 ms
 4  10.1.1.10 (10.1.1.10)  202.133 ms  202.100 ms  202.692 ms
 5  10.1.1.9 (10.1.1.9)  6201.720 ms !H * *
user@linux:~$

此外，如果查看第 2 跳和第 3 跳，還會發現其他 IP 位址（10.1.9.78 和 10.1.9.50）

為什麼會發生這種情況？我以前從未見過這樣的事情。

這是因為伺服器配置嗎？

答案1

traceroute透過發送具有連續增加的生存時間 (TTL) 欄位的 UDP 或 ICMP Echo 封包來運作。每個處理資料包的路由器都會將 TTL 減 1。

它期望對其探測有兩種類型的響應。

  • 如果當路由器遞減 TTL 時 TTL 達到 0，它將使用 ICMP 逾時訊息進行回應，並且不會轉送封包。
  • 最終目的地以 ICMP 連接埠不可達訊息（在 UDP 情況下）或 ICMP 回顯回應訊息（在 ICMP 情況下）回應。

當它收到第二種類型時，它知道它已經到達目的地，並停止發送具有更高 TTL 的探測。請注意，它不該決定是基於回應來自的位址——如果它從目標位址接收到逾時訊息，它將繼續遞增。

因此，您的追蹤表明路由器以超時回應並將目標位址作為其來源。這可能意味著它是一個執行NAT的路由器，目標位址是其後面的私人位址對應的公共位址。

但奇怪的是，最終的回應來自於不同的地址。通常，您希望回應透過路由器傳回，因此其私人 IP 將轉換回公用 IP。在本例中，您會看到兩行位址為 10.1.1.10。

顯然，在這種情況下，從 10.1.1.9 到原始電腦的路徑不需要經過 NAT 路由器，因此其位址不會被轉換。非對稱路由通常會產生異常traceroute結果。在這種情況下，您的所有電腦都位於 10.0.0.0/8 私有位址空間內，因此存在可用的直接路徑並不完全令人驚訝。

答案2

如果不知道路由器的配置，則無法確定 - 然而，一個可能的原因是目標 NAT 又稱為反向 NAT 又稱為連接埠轉發，或者 - 在這種情況下 - 暴露的主機。

10.1.1.10 路由器可以設定為轉送/DNAT一切到 10.1.1.9 主機（=公開主機），包括來自私有 IP 的請求。從公用 IP 您會看到雙最後一跳，因為實際目標 10.1.1.9 被 NAT 路由器隱藏。在這種情況下，可能只有請求被 DNATed，而回覆則按原樣轉發。

10.1.1.10 和 10.1.1.9 也可能在其他地方進行 DNAT 解析，而後者是預設回覆位址。這可以解釋 RTT 大幅增加的原因。

答案3

請注意時間。 Traceroute 發送封包，要求交換器或路由器回答來源並回覆「我正在處理」。但此資料包可能以各種順序到達目的地（本例中為您的電腦），具體取決於 TTL 和回應時間配置，也取決於裝置之間的配置、路由表和網路拓撲。

相關內容