主页 / unix / 问题 / 671974
Accepted
Nagev
Asked: 2021-10-06 08:30:03 +0800 CST

如何在 traceroute 或 ping 中识别未知设备

  • 772

在尝试排除从 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。仍然欢迎其他建议。

ping traceroute

2 个回答

  1. Best Answer

    192.168.1.19 不存在。192.168.1.17 告诉你它不存在。由于它在同一个子网上并且是第一跳，这表明 192.168.1.17 samsung.station 是您正在运行 traceroute 和 ping 的系统。或者 192.168.1.17 充当代理，任何未知的主机名都将被引用。换句话说，这里没有什么可看的。

    • 1

  2. 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.0

    docker界面不见了。我可以再次从 WSL shell 执行 ping 操作。然后它击中了我：我已经手动启动了 docker 守护进程sudo dockerd &，那时连接中断了！另一个有趣的地方是，VM 使用的是桥接接口，虽然它有自己的 IP 地址并且可以 ping 网络上的所有其他设备，但它无法 ping 主机的 IP。

    好消息是，我现在在虚拟机上运行了 docker，我可以从 WSL SSH 到它，或者甚至更好，直接从 PowerShell，一切正常。

    • 0

相关问题