在尝试解决从 Windows 主机到一个 Linux 来宾虚拟机的 IP 地址 (192.168.1.19) 的 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 路由器,但无法识别任何 IP 地址为“192.168.1.17”的设备。我已关闭或断开网络上所有几台三星设备的 Wi-Fi,但仍然得到相同的结果。
我的最终目标是让 ping 双向工作,但现在我还想知道是否可以做些什么来识别这个神秘设备!我见过一个相关问题但我还没有尝试阻止设备,我首先想了解在重新启动路由器之前最好的下一步是什么。如果有人可以自信地说没有 Linux 工具可以帮助我解决这个问题或获得更多信息,那也是一个有效的答案。谢谢。
更新
主机运行Windows 10,通过内置Wi-Fi接口连接到网络。
虚拟机位于 VirtualBox 上。我特意选择了“桥接适配器”,以获得专用的 DHCP IP 地址,这样可以轻松方便地访问其本地网络服务器。此设置在以前的 Ubuntu VM 上运行良好,但这里涉及的 VM 是新的 Debian 11 最小(无桌面)安装。
我还重新启动了 Wi-Fi 路由器,所以有些事情发生了变化:
- Windows 主机现在位于 192.168.1.16,但它在 Wi-Fi 路由器上显示为虚拟机的“主机名”!这可能与重新启动之前相同,我可能只是忽略了 Windows 主机的主机名不在设备列表中这一事实。
- VM 仍报告 IP 192.168.1.19。但现在它也无法 ping 通主机 IP (.16),并且
traceroute
仅显示* * *
所有 30 个跃点的 192.168.1.16。 - 从
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
,但我没有剪贴板集成工作,甚至在上一个虚拟机上很容易的共享文件夹在这个虚拟机上也不可见,所以我也无法将输出重定向到文件。
现在很明显,连接问题的根源似乎是桥接适配器无法从路由器的 DHCP 服务器获取自己的 DHCP IP,由于 VM 主机名出现在 Wi-Fi 列表中,我可能在重新启动之前错过了该 IP路由器上的设备。
事实证明,这更多的是 VirtualBox 故障排除,对此表示歉意。我可能只会为虚拟机分配一个固定的IP。任何关于意外跳跃之谜的提示仍然很有趣。
第二次更新
只是记得我可以用来tcpdump
获取更多信息。多年来,它一直是我最喜欢的网络故障排除工具之一!将根据我的发现发布更新或答案。另外,我还没有重新启动Windows。仍然欢迎其他建议。
答案1
192.168.1.19 不存在。 192.168.1.17 告诉您它不存在。由于它位于同一子网上并且是第一跳,因此表明 192.168.1.17、samsung.station 是您正在运行 Traceroute & ping 的系统。或者 192.168.1.17 充当代理,任何未知的主机名都将引用它。换句话说,这里没有什么可看的。
答案2
长话短说:网络问题是由于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.0
docker 界面消失了。我可以再次从 WSL shell 执行 ping 操作。然后我突然意识到:我已经使用 手动启动了 docker 守护进程sudo dockerd &
,就在那时连接中断了!另一个有趣的地方是,虚拟机使用桥接接口,虽然它有自己的 IP 地址并且可以 ping 通网络上的所有其他设备,但它无法 ping 通主机的 IP。
好消息是,我现在在虚拟机上运行了 docker,并且可以从 WSL 或直接从 PowerShell 通过 SSH 连接到它,而且一切正常。