Path mtu discovery linux

15.6. Решение проблемы с Path MTU Discovery путем настройки MTU.

Общеизвестно, что скорость передачи данных возрастает с увеличением размера пакета. Это вполне естесственно, ведь для каждого пакета в потоке принимается решение о выборе маршрута. К примеру, файл, размером в 1 мегабайт, будет передан быстрее, если он будет разбит на 700 пакетов (при максимальном размере пакета), а не на 4000.

Однако, не все сегменты Интернет могут передавать пакеты, с максимальной полезной нагрузкой в 1460 байт. Поэтому необходимо найти такой размер, который будет максимально возможным для заданного маршрута.

Процесс поиска такого размера называется ‘Path MTU Discovery’ (Поиск Максимального Размера Пакета для выбранного Пути), где MTU означает ‘Maximum Transfer Unit’ (Максимальный Размер Блока передачи данных).

Когда на маршрутизатор поступает пакет, который не может быть передан по выбранному маршруту целиком (без фрагментации) И у него установлен флаг «Don’t Fragment» (Не фрагментировать), то в ответ отправляется ICMP-сообщение о том, что пакет был сброшен из-за невозможности «протолкнуть» его по выбранному маршруту. Компьютер, выполнивший посылку, начинает последовательно уменьшать размер пакетов до тех пор, пока они не смогут быть переданы по выбранному маршруту.

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

В результате таких действий процесс поиска оптимального размера пакета работает все хуже и хуже, а на некоторых маршрутизаторах вообще не работает, что в свою очередь порождает сеансы TCP/IP с весьма странным поведением, которые «умирают» спустя некоторое время.

Хотя у меня нет никаких доказательств, но я знаю по крайней мере два сайта, с которыми наблюдается подобная проблема и перед обоими стоит Alteon Acedirectors — возможно кто-то имеет более богатый опыт и сможет подсказать как и почему это происходит.

15.6.1. Решение

Если вы столкнетесь с подобной проблемой, то можно посоветовать отключить ‘Path MTU Discovery’ и установить MTU вручную. Koos van den Hout пишет:

У меня возникла следующая проблема: для арендованного мною канала, работающего через ppp, на скорости 33.6К, я установил величину MTU/MRU, равную 296. Это дает мне достаточно приемлемое время отклика.

Со моей стороны установлен роутер (с маскарадингом), работающий под управлением Linux.

Недавно я вынес маршрутизатор на отдельный компьютер, так что теперь большая часть приложений выполняется на отдельной машине.

После этого возникла масса проблем с авторизацией в irc. В процессе длительных поисков я установил, что само соединение проходит и даже показывается системой как ‘connected’, но я не получал motd от irc (motd — от англ. Message of The Day, которое демонстрируется после успешной авторизации, прим. перев. ). Кроме того, помятуя о проблеме, связанной с MTU, я определил, что проблема исчезала только в том случае, когда MTU устанавливался равным 296. А так как серверы irc блокируют весь трафик, который напрямую не связан с их работой, то в числе блокируемых оказался и ICMP.

Мне удалось убедить администратора WEB-сервера в истинных причинах возникновения проблем, но администратор IRC-сервера отказался устранять их.

Таким образом, передо мной встала необходимость уменьшить MTU для внешнего трафика и оставить нормальное значение для локального.

ip route add default via 10.0.0.1 mtu 296

(10.0.0.1 — шлюз по-умолчанию, внутренний адрес маршрутизатора с маскарадингом)

Вообще, можно запретить ‘PMTU Discovery’ путем настройки специфических маршрутов. Например, если проблемы наблюдаются только с определенной подсетью, то это должно помочь:

ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000

Назад	В начало документа	Вперед
Прозрачное проксирование с помощью netfilter, iproute2, ipchains и squid.	К началу раздела	Решение проблемы с Path MTU Discovery путем настройки MSS.

Источник

Path MTU Discovery и прочее связанное с этим

MTU — эта аббревиатура составлена из слов Maximum Transmission Unit, что можно перевести как Максимальный Передающийся Блок. Блок состоит из заголовка и полезной нагрузки. Под MTU понимается максимально возможный размер передаваемой полезной нагрузки.

Содержимое сетевого пакета

Ethernet-кадр (Ethernet frame)

Размер ethernet-кадра в ethernet-сети варьируется в пределах 1514-1538? байт, что слагается из:

• заголовок (header) кадра, размером 14–38 байт, содержащий, из важного для наблюдателя, следующие поля:
  • MAC-адрес получателя в актуальном физическом сегменте сети
  • MAC-адрес отправителя в этом же сегменте сети
  • поле EtherType (IPv4: 0x0800, или ARP: 0x0806, или …)

  Так как MTU размером всего 1500 байт на сегодняшний день является атавизмом, то уже разработан и внедряется … джамбо-пакеты размером до ~9000 байт … бла-бла-бла.

  Запоминаем, что размер Ethernet MTU может достигать 1500 байт, причём длина заголовка ethernet-кадра, в отличии от инкапсулированных в него пакетов, не имеет значения, так как ethernet-кадр существует только в пределах текущего сегмента сети, границы которого не пересекает.

  Заголовок ethernet-кадра обрабатывается на втором, канальном уровне, OSI, Ethernet payload на этом уровне, естественно, остаётся без изменений.

  Вернее будет сказать, что при необходимости прохождения очередного сегмента сети, сетевая карта загружает полезный груз в только что подготовленный ethernet frame и отправляет его до шлюза-маршрутизатора в следующий сегмент сети, где payload перегружается в новый ethernet-кадр, который, в свою очередь, довезёт груз до следующего роутера, и т.д.

  Впрочем, некоторая информация, присутствующая в заголовке предыдущего ethernet фрейма, например VLAN или QoS, может копироваться в соответствующие поля заголовка следующего фрейма и, таким образом, путешествовать вместе с грузом через все или несколько сетевых сегментов до пункта назначения.

  IP-датаграмма (IP datagram)

  Итак, в поле payload ethernet-кадра мы можем наблюдать IP-датаграмму, состоящую из:

  • заголовок (header) датаграммы, длиной 20–60? байт, где, в числе прочего, видим:
    • длина заголовка (например, 20 байт)
    • общая длина датаграммы, header + payload (например 1500 байт)
    • идентификация — уникальное случайное число, используемое, вместе с полями “протокол”, “ip-адрес отправителя” “ip-адрес получателя”, для идентификации конкретной датаграммы
    • поле для флагов (установлен флаг DF)
    • протокол
    • ip-адрес отправителя
    • ip-адрес получателя

    Из вышенаписанного выясняется, что IP datagram MTU может достигать 1480 байт.

    Заголовок IP-датаграммы обрабатывается на третьем сетевом уровне модели OSI и данные в нём могут измениться, например, при трансляции IP-адреса в случае пересечения шлюза NAT. Полезная нагрузка IP-датаграммы, что естественно, на сетевом уровне изменениям не подвергается.

    TCP-сегмент (TCP segment)

    бла-бла-бла Подвести к TCP MSS

    UDP-сегмент (UDP segment)

    бла-бла-бла Затронуть OpenVPN

    Способ определения MTU (Path MTU Discovery)

    В RFC1191 (November 1990) предложен способ обнаружения MTU.

    На сегодняшний день алгоритм, если я всё правильно понимаю, выглядит так:

    1. Хост-источник подготавливает ip-датаграмму с некоторым содержимым.
    2. В заголовке отправляемой ip-датаграммы устанавливаем флаг “не фрагментировать”.
    3. Датаграмма начинает движение к требуемому ip-адресу, пересекая ряд роутеров.
    4. В случае, если очередной роутер не может отправить датаграмму в следующий сетевой сегмент без фрагментации, то этот роутер:
       • отправляет обратную ip-датаграмму с icmp-информацией о необходимости уменьшить MTU для этого маршрута до определённого значения
       • уничтожает исходную датаграмму
    5. Хост-источник, после получения icmp-сообщения, повторяет отправку данных, но перепакованную в пакеты меньшего размера.
    6. Если на маршруте попадётся ещё один роутер с меньшим значением MTU, то алгоритм повторится с учётом нового меньшего значения MTU.

    Содержимое обратной ip-датаграммы информативно:

    • заголовок стандартный:
      • …
      • протокол ICMP
      • ip-адрес отправителя [роутер]
      • ip-адрес получателя [хост-источник]
      • Type [3]
      • Code [4]
      • MTU для следующего скачка: [значение до которого надо уменьшить MTU]
      • и копия первых ~500? байт исходной датаграммы, где наблюдаются важные поля: идентификация, протокол, ip-адрес отправителя, ip-адрес получателя

      Path MTU Discovery Black Hole

      Пресловутая чёрная дыра возникает в том случае, если на каком-то из роутеров, находящихся на обратном маршруте [роутер –> хост-источник], прохождение icmp-пакетов запрещено. Нельзя забывать и о самих отправителе и получателе icmp-пакета.

      Причина возникновения “Чёрной дыры”

      Разберём обычную схему с “зависшим сайтом”:

      1. Домашний пользователь, с помощью браузера, отправляет web-серверу запрос на показ страницы. Обычно такая датаграмма имеет небольшой размер и гарантированно доберётся до web-сервера.
      2. После преодоления цепочки роутеров, на web-сервер приходит ip-датаграмма с запросом показа страницы.
      3. Так как запрашиваемая страница довольно тяжёлая, а сетевой интерфейс web-сервера имеет значение MTU равным 1500 байт, то web-сервер делит содержимое страницы на несколько частей так, чтобы размер первого куска страницы, вместе с заголовками ip-датаграммы и tcp-сегмента, не превышал 1500 байт.
      4. Тяжёлая ip-датаграмма начинает путешествие к пользователю.
      5. На одном из роутеров возникает проблема. Сетевой интерфейс, через который датаграмма должна была продолжить путь к пользователю, имеет MTU 1492. Роутер отправляет icmp 3/4 обратно web-серверу, а датаграмму уничтожает. Пользователь продолжает наблюдать в браузере песочные часы на белом фоне пустой страницы.
      6. Датаграмма с указанием “MTU уменьшить до 1492 при отправке пакетов через такой-то роутер” может быть уничтожена:
         • на роутере-отправителе;
         • на одном из роутеров между роутером-отправителем и web-сервером;
         • на сетевом интерфейсе web-сервера; что маловероятно, потому что одно из первых правил в файрволе web-сервера:
           • iptables -A INPUT -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT ,
           • то есть icmp-пакет, после разбора своего содержимого, где будут найдены изначальные идентификация, протокол, ip-адрес отправителя, ip-адрес получателя, попадёт под определение RELATED .
      7. В случае не прохождения обратного icmp-пакета произойдёт следующее:
         • web-сервер не получит icmp-пакет и продолжит ждать tcp-пакет с подтверждением получения первого куска страницы;
         • через некоторое время web-сервер повторит безнадёжную отправку первого куска запрошенной html-страницы;
         • пользователь продолжает наблюдать в браузере песочные часы на белом фоне пустой страницы.

      Определение MTU с помощью ping

      Работает в случае разрешённых icmp echo/request .

      Уменьшаем размер пакета пинга до устойчивых обратных понгов.

      $ ping -M do 1.1.1.1 -s 1465 PING 1.1.1.1 (1.1.1.1) 1465(1493) bytes of data. From 192.168.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1484) ping: local error: message too long, mtu=1484 $ ping -M do 1.1.1.1 -s 1456 PING 1.1.1.1 (1.1.1.1) 1456(1484) bytes of data. 1464 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=4.67 ms 1464 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=6.86 ms 1464 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=4.84 ms 

      Способы решения проблемы с “Чёрной дырой”

      1. Очевидное и самое правильное решение — обеспечить прохождение icmp 3/4 на всём маршруте. К счастью
      2. Искуственно уменьшить MTU внешнего интерфейса на своём хосте, либо на одном из-под контрольных роутеров. Минус этого решения в деградации производительности сети из-за уменьшения размера payload.
      3. Задействовать TCP MSS. Будет работать только с TCP. С UDP- протоколом, например OpenVPN, проблемы останутся.

      Разобрать: TCP MSS tcp сквозь openvpn over udp Параграф: Определение MTU с помощью ping

      Дописать при желании: Может быть разжевать по какой причине фрагментирование нежелательно.

      Источник