如何在 traceroute 或 ping 中辨識未知設備
在嘗試排除從 Windows 主機到一台 Linux 來賓虛擬機 (192.168.1.19) 的 IP 地址失敗的 ping 故障時，我做了一個
traceroute：$ traceroute 192.168.1.19 traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets 1 Samsung.station (192.168.1.17) 3132.517 ms !H 3132.491 ms !H 3132.489 ms !H $ ping 192.168.1.19 PING 192.168.1.19 (192.168.1.19) 56(84) bytes of data. From 192.168.1.17 icmp_seq=1 Destination Host Unreachable From 192.168.1.17 icmp_seq=2 Destination Host Unreachable $ ping hostname PING hostname (192.168.1.19) 56(84) bytes of data. From Samsung.station (192.168.1.17) icmp_seq=1 Destination Host Unreachable From Samsung.station (192.168.1.17) icmp_seq=2 Destination Host Unreachable我可以從訪客 ping 主機 IP（192.168.1.15）。問題是，我知道我的網路上有什麼，但我不知道這
Samsung.station台機器應該是什麼。我已登錄 Wi-Fi 路由器，但無法辨識任何具有“192.168.1.17”IP 地址的設備。我已經關閉或斷開了網路上所有少數三星設備的 Wi-Fi，但我仍然得到相同的結果。我的最終目標是讓 ping 雙向工作，但現在我也想知道我是否可以做任何事情來辨識這個神秘的設備！我已經看到了一個相關的問題，但我還沒有嘗試阻止設備，我首先想了解什麼是最好的下一步，然後再重新啟動路由器。如果有人可以自信地說沒有 Linux 工具可以幫助我解決這個問題或獲得更多資訊，那也是一個有效的答案。謝謝你。
更新
主機執行 Windows 10，通過內置 Wi-Fi 介面連接到網路。
虛擬機在 VirtualBox 上。我特意選擇了一個“橋接適配器”，以獲得一個專用的 DHCP IP 地址，這樣可以輕鬆方便地訪問其本地網路伺服器。此設置在以前的 Ubuntu VM 上執行良好，但這裡討論的 VM 是新的 Debian 11 最小（無桌面）安裝。
我還重新啟動了 Wi-Fi 路由器，所以有些事情發生了變化：
- Windows 主機現在位於 192.168.1.16，但它以 VM 的“主機名”顯示在 Wi-Fi 路由器上！這可能與重新啟動之前相同，我可能只是錯過了 Windows 主機的主機名不在設備列表中的事實。
- VM 仍報告 IP 為 192.168.1.19。但現在它也無法 ping 主機 IP (.16) 並且
traceroute192.168.1.16 僅顯示* * *所有 30 個躍點。- 從
traceroute主機到報告的訪客 IP 仍然顯示到點 17 IP 的神秘跳躍，但它旁邊不再有Samsung.station主機名，不知道從哪裡來。這裡是：$ traceroute 192.168.1.19 traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets 1 192.168.1.17 (192.168.1.17) 3121.263 ms !H 3121.242 ms !H 3121.239 ms !H我會粘貼
ip address來自 VM 的輸出，但我沒有剪貼板集成工作，甚至在前一個 VM 上很容易的共享文件夾在這個 VM 上也不可見，所以我也無法將輸出重定向到文件。現在很明顯，連接問題的根源似乎是橋接適配器未能從路由器的 DHCP 伺服器獲取自己的 DHCP IP，由於 VM 主機名出現在 Wi-Fi 列表中，我可能在重新啟動之前錯過了該 IP路由器上的設備。
事實證明，這更像是一個 VirtualBox 故障排除，為此道歉。我可能只是為虛擬機分配一個固定的 IP。關於意外跳躍之謎的任何提示仍然很有趣。
第二次更新
只記得我可以
tcpdump用來獲取更多資訊。多年來，它一直是我最喜歡的網路故障排除工具之一！將根據我的發現發布更新或答案。另外，我還沒有重新啟動 Windows。仍然歡迎其他建議。
192.168.1.19 不存在。192.168.1.17 告訴你它不存在。由於它在同一個子網上並且是第一跳，這表明 192.168.1.17 samsung.station 是您正在執行 traceroute 和 ping 的系統。或者 192.168.1.17 充當代理，任何未知的主機名都將被引用。換句話說，這裡沒有什麼可看的。
**TL;DR：**網路問題是由
dockerd在 WSL 上手動執行引起的。ip address在同一終端上使用並tcpdump提供更高的清晰度。細節
事情已經變得足夠清楚了，所以我正在分享我的故障排除步驟，因為它是值得的。接受的答案是絕對正確的，ping 來自 192.168.1.17。我打開了一個 Windows 終端，並且正在考慮 Powershell 選項卡中的源 IP，即使我是從 Ubuntu WSL 選項卡執行 ping，所以這是我的錯誤。如果我
ip a在 WSL 終端上這樣做，我會看到一個有趣的條目：6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:0b:14:ce:50 brd ff:ff:ff:ff:ff:ff inet 192.168.1.17/8 brd 192.255.255.255 scope global docker0 valid_lft forever preferred_lft forever inet6 fe80::42:bff:fe14:ce50/64 scope link valid_lft forever preferred_lft forever注意神秘192.168.1.17。我可能以前見過它，但忽略了它，因為介面已關閉，並且所有其他介面都發出噪音。事實上，我在 WSL 上安裝了 docker（使用 apt，而不是 Windows 版本），我不確定它是如何與網路互動的，但它似乎已經給出了明顯的跳躍。至於 dot17 旁邊顯示的主機名，我現在看到顯示的名稱不同，因此很明顯應該忽略一些記憶體名稱，因為它具有誤導性。
在 Wireshark 中的 PCAP 文件中更容易查看操作，我使用以下方法擷取了該文件：
sudo tcpdump -i any icmp -w traceroute.pcap第一個數據包：
1 0.000000 192.168.1.17 192.168.1.17 ICMP 104 Destination unreachable (Host unreachable)在 ICMP 中：
Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 1 (Host unreachable) Checksum: 0x7313 [correct] [Checksum Status: Good] Unused: 00000000 Internet Protocol Version 4, Src: 192.168.1.17, Dst: 192.168.1.18 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 60 Identification: 0xa55a (42330) Flags: 0x00 Fragment Offset: 0 Time to Live: 1 Protocol: UDP (17) Header Checksum: 0x90e3 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.1.17 Destination Address: 192.168.1.18 User Datagram Protocol, Src Port: 36470, Dst Port: 33434所以沒有額外的跳躍。我還注意到我可以從 Powershell 選項卡 ping 目標，但不能從 WSL 選項卡。所以我重新啟動了 WSL：
> wsl --list -v NAME STATE VERSION * Ubuntu-20.04 Running 2 Debian Stopped 2 > wsl --shutdown Ubuntu-20.04 > wsl -d Ubuntu-20.04現在，如果我
ip a在新啟動的 WSL shell 上執行，最後一個條目是：5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0docker界面不見了。我可以再次從 WSL shell 執行 ping 操作。然後它擊中了我：我已經手動啟動了 docker 守護程序
sudo dockerd &，那時連接中斷了！另一個有趣的地方是，VM 使用的是橋接介面，雖然它有自己的 IP 地址並且可以 ping 網路上的所有其他設備，但它無法 ping 主機的 IP。好消息是，我現在在虛擬機上執行了 docker，我可以從 WSL SSH 到它，或者甚至更好，直接從 PowerShell，一切正常。