持续 Ping 期间 TTL 发生变化

Question 1

我相信您的答案将来自某种形式的traceroute。但是，正如评论中所讨论的那样，您有一条路径显然没有经过卫星。某些系统有此实用程序名为tracert或tracerout。 tracepath提供类似的功能。

请注意，您可能需要多次运行 traceroute 才能真正捕获意外路径。还请注意，防火墙可能会削弱 traceroute 的有效性。虽然显然 icmp 不会被完全阻止，但安全设备通常配置为不生成 traceroute 在其默认操作模式下所依赖的“目标不可达”icmp 消息。traceroute 对一个 TTL 的回答是 * * * 并不意味着下一个不会有答案。您的 ping 测试已验证 google.com 至少会做出响应。

另一个选项可能是ping -R。但是，我自己尝试了这个选项，似乎 Google 不支持这种用法，因此您需要找到一个支持该用法的其他目标。此选项的工作原理是包含一个标头选项，要求路由器在将数据包传递给目标时记录它们的身份，然后将响应传回源。我没有经常使用此选项，但我猜安全设备也可能会干扰其输出 - 要么只是不提及它们的存在，要么将请求丢弃。

Answer

我相信您的答案将来自某种形式的traceroute。但是，正如评论中所讨论的那样，您有一条路径显然没有经过卫星。某些系统有此实用程序名为tracert或tracerout。 tracepath提供类似的功能。

请注意，您可能需要多次运行 traceroute 才能真正捕获意外路径。还请注意，防火墙可能会削弱 traceroute 的有效性。虽然显然 icmp 不会被完全阻止，但安全设备通常配置为不生成 traceroute 在其默认操作模式下所依赖的“目标不可达”icmp 消息。traceroute 对一个 TTL 的回答是 * * * 并不意味着下一个不会有答案。您的 ping 测试已验证 google.com 至少会做出响应。

另一个选项可能是ping -R。但是，我自己尝试了这个选项，似乎 Google 不支持这种用法，因此您需要找到一个支持该用法的其他目标。此选项的工作原理是包含一个标头选项，要求路由器在将数据包传递给目标时记录它们的身份，然后将响应传回源。我没有经常使用此选项，但我猜安全设备也可能会干扰其输出 - 要么只是不提及它们的存在，要么将请求丢弃。

Question 2

可能是多种原因。首先，我系统上的 ping 手册页对 TTL 进行了如下说明：

在正常操作中，ping 会打印收到的数据包中的 TTL 值。当远程系统收到 ping 数据包时，它可以在响应中对 TTL 字段执行以下三项操作之一：

不改变它；这是 Berkeley Unix 系统在 4.3BSD Tahoe 版本之前所做的。在这种情况下，收到的数据包中的 TTL 值将是 255 减去往返路径中的路由器数量。

将其设置为 255；这是当前 Berkeley Unix 系统的做法。在这种情况下，收到的数据包中的 TTL 值将是 255 减去从远程系统到 ping 主机的路径中的路由器数量。

将其设置为其他值。有些机器对 ICMP 数据包使用与 TCP 数据包相同的值，例如 30 或 60。其他机器可能使用完全不同的值。

其次，从技术上讲，没有什么可以阻止路由器或安全设备对通过它的流量施加最大 TTL，这很容易产生您所看到的影响。

因此，我的第一个建议是，您的流量可能会被负载平衡到使用 TTL 为（例如）60 的目标主机（上面的选项 3）

或者，路由器或其他设备可能会对您的计算机和目的地之间可能路由之一上的 TTL 做出意外操作。请记住，这些路由可能全部通过您的卫星连接；互联网并不保证每次都使用相同的路径发送您的数据包。

使用 traceroute 的建议是合理的。如果反复执行该命令后，从您的主机到目的地的路径没有显示任何变化，那么很可能是目的地修改了 TTL。

请注意，当您在 traceroute 中看到一长串“* * *”响应时，这表明您和您的目的地之间的设备正在对 TTL 执行一些意外的操作，至少对于 traceroute 使用的“目的地不可达”ICMP 消息而言（其处理方式与 ping 使用的“回显请求”数据包略有不同）。

如果您的 ping 命令允许您设置 TTL，您可以尝试几个不同的值来查看您得到的响应 TTL。

Answer