Ручная настройка MTU по-прежнему нужна сегодня?

Симптом

  • ssh для удаленных хостов.
  • Простой вывод, например ls работает.
  • Но больше выходных данных, таких как find / не работает.

Решение

В нашем случае мы уменьшили MTU до 1200 на eth0 (IPv4), и симптомы исчезли.

Вопрос

AFAIK есть что-то, вызывающее Path MTU Discovery

Из Википедии:

  

Многие устройства безопасности сети блокируют все сообщения ICMP для воспринимаемой выгоды безопасности

Если это причина, как отладить это?

2 голоса | спросил guettli 24 MarpmThu, 24 Mar 2016 14:07:21 +03002016-03-24T14:07:21+03:0002 2016, 14:07:21

1 ответ


4

Путь MTU Discovery работает, отправив пакеты с различными размерами в цель с включенным битом DF (Do not Fragment). Если маршрутизатор на пути имеет меньший MTU, его поведение должно состоять в том, чтобы отправить сообщение ICMP в котором говорится, что пакет должен быть фрагментирован, но бит DF был установлен в 1. Часто этот пакет даже включает размер MTU ссылки, которая требует фрагментации.

Чтобы отладить это, вам просто нужно выполнить обнаружение Path MTU вручную.

Отправьте пинг на цель, в моем примере я буду использовать DNS-сервер Google (8.8.8.8). Установите бит DF в вашем пинге, чтобы предотвратить фрагментацию вашего пинга. Установите размер вашего пакета на некоторое большое число или стандартный MTU на 1500. Обратите внимание, что некоторые реализации ping задают размер только полезной нагрузки, что означает, что вам нужно учитывать 8-байтовый ICMP-заголовок и 20-байтовый IP-заголовок.

На ПК с Windows вот команда:

C:\Users\eddie>ping -f -l 1472 -i 1 8.8.8.8

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 10.200.192.1: TTL expired in transit.
Reply from 10.200.192.1: TTL expired in transit.
Reply from 10.200.192.1: TTL expired in transit.
Reply from 10.200.192.1: TTL expired in transit.

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Обратите внимание: я получил TTL, истекший с моего первого маршрутизатора. Это то, что я хочу видеть, это ничего мне не говорит о том, что путь между мной и моим первым роутером требует фрагментации.

Было бы так, если бы так:

C:\Users\eddie>ping -f -l 1473 -i 1 8.8.8.8

Pinging 8.8.8.8 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

В любом случае, делайте это постепенно, увеличивая TTL на 1 каждый раз. В какой-то момент пути вы столкнетесь с сообщением об ошибке выше (пакет должен быть фрагментирован набором DF). Когда это произойдет, вы точно узнаете, какой маршрутизатор между вами и объектом имел меньший размер ссылки.

Если это произошло, когда для TTL установлено значение 8, вы можете запустить трассировку для цели, а 8-й прыжок будет маршрутизатором, который не смог бы фрагментировать пакет.

Если в любой момент вместо Packet needs to be fragmented but DF set или TTL expired in transit, тогда вы также знаете, где в пути существует Брандмауэр и блокирует возвращенные ICMP-пакеты.

Изменить: добавление полезной информации из комментариев:

@YLearn добавляет:

  

помните, что обратные пакеты могут принимать другой маршрут назад и   может возникнуть проблема с обратным трактом, а не с брандмауэром /ACL   на исходящем пути

@ guettli (Оригинальный плакат) добавляет:

  

в linux эти параметры необходимы: ping -M do -s 1472 8.8.8.8 введите ссылку здесь

ответил Eddie 24 MarpmThu, 24 Mar 2016 16:11:56 +03002016-03-24T16:11:56+03:0004 2016, 16:11:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132