Что может привести к сбою запроса, отправленного с TTL равным 64, при подключении к IP-адресу назначения, который, как показывает traceroute, находится на расстоянии 33 перехода?

Из контейнера докеров (под управлением ubuntu 18), работающего на AWS ECS, я пытаюсь установить соединение с внешним центром обработки данных. Мы устранили проблему там, где, по нашему мнению, причиной отказа является дополнительный переход, добавленный локальной сетью докеров. Это подтверждается тем фактом, что запрос curl на IP-адрес назначения успешно завершается из экземпляра EC2 узла докеров, а также из того же контейнера докеров при развертывании в подсети, которая находится на расстоянии менее 33 переходов от IP-адреса назначения.

При беге 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

Первый переход - это докер, второй - шлюз AWS NAT перед тем, как пробиться через сети AWS и, наконец, достичь точки 33.

При беге curl <destination_address> при захвате с tcpdump -v host <destination_ip> на хост-машине EC2, на которой запущен докер, я вижу, что запрос не выполняется из-за ttl:

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 при подключении к IP-адресу назначения, который, как показывает traceroute, находится всего в 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

Добавление снимка экрана Wireshark из tcpdump на хост-машине.

Редактировать 2

Добавление еще одного tcpdump, захваченного при скручивании того же хоста, но с моей локальной машины.

Как указано в ответе, ответ [SYN, ACK] имеет слишком низкий TTL, чтобы вернуться к машине, инициирующей запрос. На изображении, на котором я попадаю на тот же сервер локально, вы можете видеть, что это примерно на 200 переходов меньше, чем любой другой ответ этого сервера.