从在 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 跳。