☰

Traceroute 未返回结果，而 ssh 工作正常

tag-icon • tag-icon networking ssh traceroute
Traceroute 未返回结果，而 ssh 工作正常

也许这是一个愚蠢的问题，所以请耐心等待，因为我是网络新手。今天，在尝试调试与服务器的连接问题时，我观察到以下两件事 -

我可以成功地在目标服务器上 ssh（端口 22）但是，当我运行 tracert 时，我得到了“请求超时”的结果。这有意义吗？我的意思是，如果我能够使用 FQDN 进行 ssh，那么我也应该能够进行 tracert（Windows 的跟踪路由版本），对吗？我在这里遗漏了什么？

如果我需要提供更多详细信息，请告诉我。

答案1

我可以成功地在目标服务器上 ssh（端口 22）但是，当我运行 tracert 时，我得到了“请求超时”的结果。这有意义吗？我的意思是，如果我能够使用 FQDN 进行 ssh，那么我也应该能够进行 tracert（Windows 的跟踪路由版本），对吗？我在这里遗漏了什么？

这完全说得通。如果服务器（以及服务器前面的任何防火墙）允许 SSH 流量进入服务器，但禁止 ICMP 流量进入服务器，那么您的结果正是我所期望的。我并不是说这里的情况绝对如此，但听起来确实如此。

答案2

traceroute或者tracert在 Windows 中，使用 几乎总是错误的工具来调试任何类型的应用程序，特别是最知名的应用程序，例如所有基于 TCP 的应用程序，都使用其默认设置。

这是因为它们默认使用 UDP 和/或 ICMP 数据包来跟踪路径，通过逐步增加数据包的 TTL 并期望每个被达到 TTL 的数据包击中的中间节点都使用以其自己的 IP 地址作为源的 ICMP 数据包进行回复，这样它就会被检测到，并最终发现整个路径。

如今，这种方法失败的次数比起作用的次数多，而且即使能起作用，其结果（特别是应答时间和丢弃百分比）也几乎毫无意义，并且总是与您想要调试的实际协议无关，例如在您的情况下，对于 ssh，TCP 端口 22 就是如此。

因为大多数网络都会过滤 ICMP 数据包（并且通常会错误地基于一些现在已成为神话的旧攻击）并且通常以不同于 TCP 的方式路由 UDP，并且应用不同的优先级。

因此，默认看到的路径可能与应用程序实际流量完全不同，包括根本不可用。

因此，我建议永远不要这样使用此工具（出于同样的原因，也不要ping）。相反，任何现代工具都可以传递参数，例如-T --port=22（有时只是tcptraceroute $host 22），以强制它在您需要的特定端口上使用 TCP 数据包，ssh 为 22。通过这样做，您将准确观察到打开 ssh 连接时发生的情况（某些网络甚至可能针对这种情况应用一些过滤，通过“检测”与正常情况略有不同的跟踪路由流量，特别是如果您还进行 DPI，但这种情况比 ICMP 过滤或 UDP 和 TCP 的不同路径/优先级更少见）。

答案3

只是为了补充关于现代工具的评论，您可以查看使用 TCP 而不是 ICMP 的特定工具：

相关内容