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

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

При запуске traceroute из контейнера я вижу 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 при захвате с помощью tcpdump -v host на хост-машине 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

My вопрос: что может вызвать отправку запроса w с 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 при передаче .

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

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

Правка 2

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

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