什麼可能導致發送 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 $$response 的 TTL 太低，無法返回到發起請求的機器。在我在本地訪問同一台伺服器的圖像中，您可以看到它比該伺服器的任何其他響應少了大約 200 跳。
到達主機時，響應的 TTL 僅為 1，從而阻止它們被路由到容器。