什么可能导致发送 TTL 为 64 的请求在连接到 traceroute 显示距离为 33 跳的目标 IP 时失败？

从在 AWS ECS 上运行的 docker 容器（运行 ubuntu 18）中，我试图建立与外部数据中心的连接。我们已将问题解决到我们认为是本地 docker 网络添加的额外跃点导致故障的地方。支持这一点的事实是，从 docker 主机 EC2 实例成功完成对目标 IP 的 curl 请求，以及在部署到距离目标 IP 不到 33 跳的子网时从同一个 docker 容器内部完成。

traceroute <destination_ip>从容器内运行时，我看到 33 个跃点：

root@1cfbdf43c8f5:~# traceroute -m36 <destination_ip>
traceroute to <destination_ip> (<destination_ip>), 36 hops max, 60 byte packets
 1  ip-172-17-0-1.us-east-2.compute.internal (172.17.0.1)  0.039 ms  0.014 ms  0.013 ms
 2  ip-10-133-216-197.us-east-2.compute.internal (10.133.216.197)  1.185 ms  1.146 ms  1.107 ms
 3  ec2-52-15-0-157.us-east-2.compute.amazonaws.com (52.15.0.157)  8.188 ms ec2-52-15-0-169.us-east-2.compute.amazonaws.com (52.15.0.169)  5.615 ms ec2-52-15-0-161.us-east-2.compute.amazonaws.com (52.15.0.161)  10.227 ms
 ...
32  <destination_ip>  24.706 ms  24.584 ms  24.698 ms
33  <destination_ip>  24.411 ms  24.426 ms  24.323 ms

第一个跃点是 docker，第二个是 AWS NAT 网关，然后蜿蜒穿过 AWS 网络，最终到达第 33 个跃点。

在运行docker 的 EC2 主机上curl <destination_address>捕获时运行时，我看到请求因 ttl 而失败：tcpdump -v host <destination_ip>

ip-10-133-218-86.us-east-2.compute.internal > <destination_ip>: ICMP time exceeded in-transit, length 52

然而，同样的检查tcpdump显示请求在通过主机时的 TTL 为 63，表明它正确使用了 ubuntu 系统默认值 64：

Time to live: 63

我的问题是：什么可能导致发送 TTL 为 64 的请求无法连接到 traceroute 显示的目标 IP 仅 33 远？

在这一点上，我们的选择似乎是（1）减少源和目标之间的跳数，或者（2）增加传出请求的 TTL。

为了尝试做（2），增加 TTL，我尝试将 sys 属性更新/proc/sys/net/ipv4/ip_default_ttl=64为/proc/sys/net/ipv4/ip_default_ttl=128. tcpdump 检查显示在传出请求中这得到了尊重，但是调用仍然失败并显示ICMP time exceeded in-transit.

编辑 1

tcpdump从主机上 添加 Wireshark 屏幕抓取。

编辑 2

添加另一个 tcpdump，在卷曲同一主机时捕获，但来自我的本地计算机。

正如答案所指出的，[SYN,ACK] 响应的 TTL 太低，无法返回到发起请求的机器。在我在本地访问同一台服务器的图像中，您可以看到它比该服务器的任何其他响应少了大约 200 跳。