Знать про MTU важно не только сетевым инженерам, но и системным админам, DevOps инженерам, разработчикам. Почему? Ну хотя бы потому, что от MTU зависит эффективность работы любого приложения. Чтобы MTU не создал вам проблем нужно понимать какие его разновидности бывают и какие протоколы на него полагаютcя. Бонусом данной статьи станет знакомство с альтернативой ручному поиску Path MTU утилитой mtupath.
Все чаще мы в своей практике сталкивамся с проблемами, связанными с MTU. То разработчик отечественного ГОСТ VPN возьмет да решит, что MTU размером 65535 для TUN/TAP интерфейса это эффективно и оправданно. То безопасники возьмут да позакрывают ICMP на всех выходах и входах. То операторы возьмут да подрежут L3 MTU на ingress интерфейсов маршрутизаторов. Во всех этих случаях или их комбинациях порой очень сложно найти затык если не знать золотое правило траблшутинга таких проблем, их признаков и базовой теории обмена трафиком в рамках TCP/UDP. Обо всем этом и не только и пойдет речь ниже.
Различают два вида MTU: L2 MTU (Ethernet MTU), L3 MTU (IP MTU).
Есть еще и третий вид MTU, но в практике его встретить сложнее - Media MTU.
Media MTU - это Ethernet MTU + 4 байта (поле FCS, контрольная сумма L2 фрейма).
L2 MTU и его более полная версия Media MTU имеют значение в рамках сегментов сети из которых состоит общий канал (далее Path). Так же как и MAC адрес этот вид MTU имеет локальное значение.
А вот L3 MTU (IP MTU) имеет значение на всем Path (совокупности
сегментов). Так же как адреса назначения и источника пакета важны для
доставки пакета от точки А до точки B.
Канал = совокупность сегментов. Говоря об MTU канала мы подразумеваем минимальный MTU - Path MTU
Обычно, трафик изучают в Wireshark, можно сделатью отдельные столбцы с именами: L2 PDU, L3 PDU, L4 PDU. Поля в этих столбцах показывают размер (length) в байтах. Это удобно, чтобы не путаться, не заглядывать в заголовки и не высчитывать...
PDU (protocol data unit) - по сути единица протокольной сущности, со всеми служебными заголовками и полезной нагрузкой.
В некоторых случаях подвиды MTU это тоже самое, что PDU. К примеру Media MTU = MPDU (MAC Layer PDU). Идею вы поняли!
Стандартом де факто в сетях является Path MTU = 1500 байт. IETF разработал
стандарт RFC 1191, определяющий порядок работы алгоритма Path MTU Discovery (далее PMTUD). Алгоритм устанавливает следующие атрибуты:
- DF - don’t fragment bit. DF бит находится в L3 заголовке;
- ICMP Destination Unreachable, Fragmentation Needed.
Суть в том, что хост A в начале общения с хостом B отправляет
пакеты исходя из своих представлений о максимальном MTU. Чаще всего на
интерфейсе MTU 1500 байт. Вот их он и использует при формировании IP
пакета. Если в ОС реализован RFC 1191 и не отключен, то первый пакет
полетит с установленным в единицу DF битом.
Стандарт определяет, что на уровне сетевой подсистемы ядра TCP handshake должен начинаться с установленного в L3 заголовке DF бита
Если на пути следования пакета встретится устройство с MTU < 1500 байт и
при условии, что устройству в заданных рамках разрешено отвечать ICMP
ответами, то в ответ хосту А полетит ICMP сообщение ICMP Destination Unreachable, Fragmentation Needed. В теле сообщения будет указан MTU, который следует использовать для прохождения устройства, отправившего сообщение.
Заметили сколько "если" и "при условии" :) В жизни скорее всего так:
1. ICMP запрещены;
2. MTU физического интерфейса 1500 байт, а вот виртуального TUN/TAP или Loopback X > 1500 <= 65535.
65535
- максимальный MTU IPv4. L3 пакеты с таким MTU еще называют Jumbogram (гигантский пакет), по аналогии с Jumboframe (гигантский фрейм L2 PDU). Однако практическая польза от использования Jumbogram возможна в p2p соединениях, когда возможна реальная поддержка таких MTU на hop-by-hop основе. В остальных случаях Jumbogram бесполезна или даже вредна, так как высока вероятность, что это приведет к рассогласованию MSS и как итог к дропу пакетов и невозможности эффективного обмена трафиком между хостами.
Что же спасает ситуацию в большинстве случаев? Спросите вы. Все просто - в
большинстве случаев на всем пути 1500 байт MTU, а если на клиенте или
сервере меньше, то TCP постарается сгладить это недоразумение уменьшив
MSS.
Но что если TCP у нас ходит поверх UDP (т.е. используется UDP туннель) или
MTU зарезан где-то в сети провайдера без возможности изучить его
значения в рамках RFC 1191? Возможно мы хотим использовать чистый UDP
для голоса или видео?! А что если вендор посчитал, что установить
максимальный MTU IPv4 в 65535 на интерфейсе это хорошее решение и
повысит КПД VPN канала?
Вот в таких случаях и действует золотое правило о котором шла речь в заголовке! Запомните, если пинг до хоста назначения ходит, а приложение не работает, то ищите проблему сначала в MTU. В 99% случаев именно там затык. Особенно когда у всех работает, а вот есть кто-то один над кем как-будто пошутили)
О: Почему пинг работает не смотря на скрытую проблему с MTU?
В: Дело в том, что пинг по умолчанию несет в себе всего 32 байта полезной
нагрузки. Это минимальный размер payload для того чтобы ICMP request
(протокол #1) везде пролез. Задача обычного пинга проверить связность,
т.е. что маршрутизация работает и есть маршруты как туда, так и обратно. Поэтому если есть пинг это хорошо, но это не показатель, что все будет хорошо у приложения.
Итак ping ходит, а приложение (доступ к web странице) не работает.
Какие наши действия? Варианта действий два: в ручную найти минимальный
MTU (Path MTU), использовать утилиту автоматизированного поиска Path
MTU. Разберем оба варианта, так как минус второго - утилиты может не
оказаться под рукой. А плюс первого - универсальность (ping с заданным
размером пакета доступен в любой ОС).
1. Ручной поиск Path MTU:
Ручной поиск позволяет, последовательно подбирая размер пакета найти
максимальный размер пакета которой пролезет в канал. И с помощью не
ложной математики можно будет высчитать Path MTU:
1. Операционная система смотрит на MTU исходящего интерфейса и сообщает
пространству пользователя, что требуется фрагментация ибо не лезет такой
пакет. В Wireshark вы это не увидите. Ядро не передает ICMP пакет
дальше в сетевую подсистему хоста, а возвращает обратно приложению. В
нашем случае утилите пинг на стандартный поток ввода/вывода;
2. 1450 байт пролезло. Видно, передано =1, получено = 1, потеряно = 0. В Wireshark мы так же видим как запрос так и ответ:
3. 1470 байт пролезло.
Постепенно увеличиваем помня, что 1500 не пролезло, а 1470 проходит.
4. 1475 байт - не проходит;
5. 1472 байта - проходит. Видно, передано =1, получено = 1, потеряно = 0. В Wireshark мы так же видим как запрос так и ответ:
Взгляните внимательно на значение L2/L3 PDU. Ничего не напоминает?)
L3 PDU = 1500 байт - стандартный IP MTU
L2 PDU = IP MTU + L2 MTU = 1500 + 14 = 1514
На этом этапе уже можно остановиться помня о том, что L3 заголовок = 20
байт, а ICMP = 8 байт, всего 28 байт для заголовков. Т.е. Path MTU явно
1500 байт. Но предположим, что мы точно этого не помним и поэтому еще
один шаг;
6. 1473 байт не проходит и ставим точку.
2. Используем утилиту автоматизированного поиска Path MTU - mtupath.exe
https://www.iea-software.com/products/mtupath/
Тут все просто:
Программка делает за нас всю ручную работу. Помимо этого она дает
чуть больше чем нам нужно, она еще и MSS считает. Занизим на нашем
интерфейсе MTU:
Что происходит под капотом. Обратимся к Wireshark:
Так выглядит наличие возможной проблемы на канале:
Подведем итог
1. Всем IT спецам желательно представлять, что такое MTU, как от него считается MSS и какие возможны проблемы;
2. Необходимо помнить, что TCP использует RFC 1191 для поиска оптимального MTU. Если вы безопасник, то постарайтесь быть гибче и не портите жизнь людям. Лучше ломайте стереотипы и покажите что вы можете больше чем просто запретить :)
3. Если вы пытаетесь работать с безопасниками, то скиньте им эту статью.
ICMP гораздо гибче чем они думают, на МСЭ можно запретить часть
возможностей ICMP оставив при этом те возможности которые определены RFC и не мешают безопасной эксплуатации информационных систем;
4. Скачайте себе утилитку mtupath - не помешает в работе;
5. Добавьте эту статью себе в закладки, чтобы при необходимости освежить материал и применить в своей работе.