☰

traceroute -T -p 如何工作？

tag-icon • tag-icon traceroute
traceroute -T -p 如何工作？

我的目标是检查目标端口（MySQL 3306）是否能够连接。

首先，我尝试使用 telnet，但它显示No route to host

$ telnet dest.com 3306
Trying <dest_ip>...
telnet: Unable to connect to remote host: No route to host

但是可以连接80端口。

$ telnet dest.com 80
Trying <dest_ip>...
Connected to dest.com.
Escape character is '^]'.

因此，我尝试使用常规跟踪路由，但无法到达目的地。

$ traceroute dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.283 ms 0.553 ms 0.345 ms
2 * * *
3 * * *
...

但是，当我尝试使用 traceroute -T -p 时，目的地似乎是可以到达的。

$ traceroute -T -p 3306 dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.270 ms 0.374 ms 0.468 ms
2 <public_ip> (<public_ip>) ....
3 <public_ip2> (<pubice_ip2>) ...
4 ...
5 <dest_ip> (dest_ip) 4.144 ms !X 4.217 ms !X 3.996 !X

而且，当我尝试使用其他端口时，路由是不同的（仅一跳之差）。

$ traceroute -T -p 80 dest.com
traceroute to dest.com (<dest_ip>), 30 hops max, 60 byte packets
1 172.16.101.1 (172.16.101.1) 0.327 ms 0.438 ms 0.568 ms
2 <dest_ip> (dest_ip) 0.711 ms 0.865 ms 0.974 ms

所以，我想知道traceroute -T -p每个步骤是如何工作的以及结果的原因是什么？

答案1

您的结果表明路由发生了变化。这与操作方式无关traceroute。请重新运行测试，如果路由出现不同，请再次重新运行测试。没有到主机的路由，可能是防火墙阻止了端口 3306。

traceroute -T尝试使用增加的 TTL 打开 TCP 连接。如果您连接到允许的端口，这在大多数情况下应该可以绕过防火墙。输出中描述了该机制man traceoute。

当防火墙处于基本关闭的配置时，第一个输出是正常输出。除非有规则允许，否则正常的 UDP 跟踪路由将失败。

您的第二个请求显示了一条较长的路径。根据您的防火墙配置，这可能是正常路由。或者可能是尚未发现较短的路径。路由与 无关traceroute。!X每次之后的注释都表示通信是adminstratively prohibited。ae 注释也包含在 traceroute 的手册页中。

第三个请求使用了一条较短的路径。这可能是防火墙上的发夹 NAT 配置。或者可能是发现了一条较短的路径。TCP 服务器似乎正在响应。

几点说明：

  • telnet是您正在运行的测试的有效工具。我经常在命令前加上 ，echo |以便立即关闭连接。
  • 初始失败表示您没有通往服务器的路由。在这种情况下，测试不会告诉您有关服务器连接的任何有用信息。
  • 运行此类测试时，如果结果不一致，重试会很有帮助。在这种情况下，您有不同的路由。通常，路径应该在第一次请求时已知或发现。
  • netstat -ant | grep 3306服务器上的 会告知 MySQL 是否正在监听可访问端口。 和127.0.0.1都无法::1从服务器外部访问。

答案2

您的输出traceroute dest.com显示从第二跳开始数据包丢失率为 100%。最有可能的解释是连接端的防火墙配置不当。它可能会丢弃传出的 UDP 数据包。

您的输出 fromtelnet dest.com 3306和traceroute -T -p 3306 dest.com是一致的。from!X表示traceroute没有到主机的路由，就像telnet告诉您的一样。但是，有关没有到主机的路由的消息源自您尝试访问的 IP 地址。这意味着要么该 IP 在欺骗您，要么另一端正在发生某种 NAT，导致真实 IP 地址对您隐藏。

输出traceroute -T -p 80 dest.com显示了一条更短的路由。这看起来就像是连接端的某些东西劫持了发往端口 80 的流量。

由于症状表明连接两端都出现了问题，因此可能存在两个不同的问题，您应该分别调试它们。为了帮助分别调试这些问题，您可以访问第三台具有互联网连接的主机，并且没有任何异常情况。这意味着用于调试的第三台主机上没有 NAT 和防火墙。

答案3

这不是您的问题的答案，但可能会解决您的实际问题。

您是否需要确保 MySQL 除了本地主机接口之外还监听实际的面向互联网的接口？

相关内容