☰

資料包返回但追蹤路由失敗

tag-icon • tag-icon wireshark networking
資料包返回但追蹤路由失敗

我從追蹤路由得到這個輸出：

#traceroute -i eth1 -s 192.168.12.14 192.168.1.72

1  192.168.12.1 (192.168.12.1)  1.410 ms  2.076 ms  2.251 ms
2  * * *
3  * * *
etc..

但在另一個終端中，我可以看到來自目標主機的正確回應（連接埠無法存取）：

9.964867 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)     
9.964879 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964886 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964904 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964923 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964927 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)

起初我以為這是防火牆問題，但我檢查後發現沒有封包被丟棄。唯一想到的是這是第二個網卡...

如果我在第一個網卡上對同一台主機運行traceroute，我會得到與上面相同的wireshark跟踪（顯然具有不同的來源IP）——但是traceroute命令會成功。

我不明白wireshark如何看到回复，但traceroute在第二個網卡上失敗。

我想我在這裡錯過了一些非常基本的東西...

答案1

Wireshark 將顯示到達網路介面的內容。核心顯然已經看到了這些資料包，但由於某種原因決定不將它們傳遞給traceroute命令。

有一些事情可能會出錯，導致核心決定不傳送這些資料包。

  • 您可能有不適合反向路徑過濾的非對稱路由，但已rp_filter啟用。
  • 核心可能無法將 ICMP 錯誤訊息的內容與本機套接字進行比對。發生這種情況的原因可能是封包已被截斷，而沒有足夠的資訊可用於做出此類決定。發生這種情況也可能是由於某些 NAT 配置損壞，其中一個方向的資料包會透過 NAT 路由，但另一個方向則不路由。
  • 由於校驗和錯誤，核心可能會丟棄資料包。

我認為這rp_filter聽起來是最有可能的解釋。您沒有指定作業系統，但看起來可能是 Linux 系統，所以請嘗試以下命令：head /proc/sys/net/ipv4/conf/*/rp_filter。您可能會1在其中每一個上看到，這表示過濾器已啟用。嘗試將 a 寫入0與丟棄資料包的介面相對應的介面以及all設備名稱。

答案2

你能在這裡發布每個盒子的路由表的輸出嗎？如果預設路由無效/缺失，封包將沒有返迴路徑。請發布以下輸出：

#ip路由列表

在每個 Linux 機器上。

相關內容