☰

SSH 到设备暂时有效，但一段时间后失败并显示“没有到主机的路由”。

tag-icon • tag-icon networking ssh
SSH 到设备暂时有效，但一段时间后失败并显示“没有到主机的路由”。

我有一台运行 Ubuntu 18.04 的 Jetson Nano edge 设备，我希望通过 ssh 连接到它。它通过 USB WiFi 适配器无线连接到我的家庭网络。在我的桌面上，ssh -v <user>@ip设备启动后，我可以在该设备上待一段时间，但大约三十分钟后，当我尝试连接时，会收到ssh: connect to host <IP> port 22: No route to host错误。输出如下：

$ ssh -v <user>@192.168.0.11
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.0.11 [192.168.0.11] port 22.
debug1: connect to address 192.168.0.11 port 22: No route to host
ssh: connect to host 192.168.0.11 port 22: No route to host

当处于“无法连接”状态时，ping 如下所示：

PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.
From 192.168.0.3 icmp_seq=1 Destination Host Unreachable
From 192.168.0.3 icmp_seq=2 Destination Host Unreachable
From 192.168.0.3 icmp_seq=3 Destination Host Unreachable

这很奇怪。似乎我只能 ping 一次。当处于“可连接”状态时，ping 可以正常工作。

当处于“无法连接”状态时，我必须重新启动我的边缘设备，然后一切就会恢复正常，并且我可以连接一段时间。

其他网络上也发现了同样的行为。因此，我不认为这是网络问题。在尝试 ssh 到边缘设备时，Windows 和 Mac 机器上也会出现此行为。因此，我的直觉告诉我问题出在边缘设备上。我还尝试删除 .ssh 文件夹中 known_hosts 的条目，但没有成功。最后，当处于不良状态时，设备仍然连接到互联网。我可以从边缘设备 ping google 并 ping 台式电脑。

更新：我刚刚注意到更多奇怪的行为。使用边缘设备 ping 我想要 ssh 的机器后，我就可以 ssh 到边缘设备了。

编辑：这是处于“无法连接”状态时的跟踪路由输出：

traceroute to 192.168.0.11 (192.168.0.11), 30 hops max, 60 byte packets
 1  tower (192.168.0.3)  3050.223 ms !H  3050.170 ms !H  3050.141 ms !H

答案1

听起来像是 arp 问题。只有当设备向路由器广播其存在后，路由器才会向网络上的请求设备通告 mac 地址。此信息单播到网络上的其他节点，并在请求一段时间（通常为 60 秒）后存储在本地系统的 arp 缓存中。

设备没有正确地向网络广播，因此您的本地 arp 缓存在一段时间后丢失信息并且不再知道如何连接到它，或者路由器在被请求时没有发送 arp 数据，因此路由器本身的 arp 缓存存在问题。

因此，要弄清楚这一点，您需要检查以下几件事：

  1. 确保设备的广播地址与网络设置一致。通常，这是网络前缀范围的最后一个八位字节（例如192.168.0.255/24）
  2. 在问题发生前后检查设备和系统的本地 arp 缓存。（这会有所不同，在 ubuntu 上，它会arp -a显示本地缓存中的内容）。相应地进行调整。如果是多宿主，请确保预期的 ip 与 arp 表中的正确 mac 地址相关联。
  3. 检查您的路由器。如果广播设置正确且设备上的 arp 处于活动状态，则很可能是路由器在收到请求时无法发送到网络上的其他节点，或者路由器的 arp 缓存持续时间太短。

这就是为什么您的系统在您从设备 ping 之后可以连接到它的原因，因为它会直接与您的系统重新建立第 2 层 mac 信息，然后它会使用设备的 mac 地址更新相关系统上的本地 arp 表，绕过路由器通信。

我会检查该设备以确保它能够正确地进行自我宣传。

如果您无法弄清楚，您可以通过以下方式将静态 arp 条目添加到系统的 arp 表中：

arp -s或者arp -f <filename>

在确认您的错误和我的假设时，我发现了这个参考，其中可能还有其他解决方案：https://networkengineering.stackexchange.com/questions/33397/debugging-no-route-to-host-over-ethernet

更新：我刚刚意识到您正在通过 wifi/无线连接。问题出现后，您可能需要确保信号良好。虽然我仍然认为它与 arp 有关，但 wifi 可能很挑剔，并且并不总是表现正常。您的 traceroute 响应时间会让我认为存在干扰问题，但我可能只是误读了您的执行方式。3050ms 是一个非常长的网络响应时间。

相关内容