Назад | Перейти на главную страницу

Максимальная задержка ICMP между запросом эха и ответом, полученным маршрутизатором NAT

Я пытался замедлить работу сети на моем сервере (arch linux vm) с помощью netem

sudo tc qdisc add dev eth0 root netem delay 1600ms

С задержкой 1600 мс клиент не получает эхо-ответный пакет, хотя пакет генерируется на стороне сервера. Однако он может выдержать до 1500ms задержка. Если задержка меньше указанной, на стороне клиента принимается эхо-ответ.

Но в RFC указывается ли фиксированная максимальная задержка между эхо-запросом и эхо-ответом?

я использовал ping так же как scapy генерировать ICMP пакеты эхо-запросов и tcpdump для проверки входящих пакетов эхо-ответа. Так что проблема не в ping программа.

Поэтому я думаю, что где-то в промежуточном маршрутизаторе ECHO reply пакеты отбрасываются из-за задержки. Итак, какова максимальная задержка между запросом эха и ответом, которую выдерживают обычные маршрутизаторы?

Контекст: ICMP не является протоколом с отслеживанием состояния.

В сценарии, когда вы сидите за маршрутизатором, который преобразует ваш трафик через NAT, и вы отправляете эхо-запрос на устройство на другой стороне маршрутизатора, маршрутизатору необходимо отслеживать ваши Эхо-запросы ICMP чтобы соответствующие Эхо-ответы ICMP in. Как это сделать, если ICMP не отслеживает состояние? Просто напишите запись в таблице NAT и оставьте ее на некоторое время.

Производитель вашего маршрутизатора решил, что 1500 мс - это хороший компромисс между функциональностью (ICMP работает) и безопасностью:

1) Маршрутизатор может быстро освободить память вместо того, чтобы хранить потенциально миллионы записей для односторонних ICMP.
2) Маршрутизатор блокирует нежелательные эхо-ответы ICMP, потенциально используемые для зондирования, снятия отпечатков пальцев и т. Д.

Как примечания, тайм-аут проверки связи по умолчанию для Windows составляет 4 секунды, а для многих дистрибутивов Linux - 10 секунд (со ссылкой на инструменты «ping» по умолчанию в обеих ОС).

Есть рекомендации в RFC 5508 «Требования к поведению NAT для ICMP», относительно того, как долго маршрутизатор должен сохранять состояние для пакетов ICMP, но нет никакой гарантии, что кто-нибудь последует за ними.