В основе сетевого взаимодействия лежит простая идея: разбить большие объёмы данных на такие фрагменты, которые способны пройти по каналу связи. Это и есть функция MTU — Maximum Transmission Unit, максимального размера кадра, который можно передать без необходимости делить его на части. Казалось бы, просто: есть стандарт Ethernet — 1500 байт, есть PPPoE — 1492 байта, а значит, нужно просто учесть эти числа и жить спокойно. Но как только в маршруте пакета появляется туннель, VPN, нестандартный канал или ошибка на одном из интерфейсов — вся система начинает рушиться. Потому что даже одного лишнего байта достаточно, чтобы началась фрагментация, а с ней — задержки, потери, проблемы с шифрованием, падения производительности и даже полные обрывы соединений.

MTU — это немая переменная в сетевой архитектуре, которая редко на слуху, но влияет буквально на всё. Слишком часто её не трогают вовсе, оставляя «по умолчанию». Или трогают один раз — при настройке туннеля, VPN или новой линейки маршрутизаторов — и забывают. Но именно в этой «забытости» и кроется главная уязвимость. Потому что сетевой трафик не проходит по одному каналу, он путешествует по множеству интерфейсов, с разными характеристиками, через туннели GRE, IPsec, OpenVPN, через VLAN, PPPoE, NAT и маршрутизаторы, у каждого из которых могут быть свои ограничения по MTU. И если на стыке этих сред не учтён MTU, начинается фрагментация — процесс, при котором один исходный пакет IP разбивается на два или более пакетов, чтобы пройти по следующему звену.

Что такое фрагментация и почему это плохо

Фрагментация — это не просто увеличение числа пакетов. Это перерасход ресурсов на каждом уровне. Когда IP-пакет фрагментируется, он разбивается на части, каждая из которых должна быть отдельно завернута, промаркирована, передана и собрана. Это происходит на маршрутизаторах, шлюзах и на самом конечном узле. Если хотя бы один фрагмент теряется — теряется весь пакет. Более того, каждый фрагмент требует отдельной обработки в CPU, нарушая кэширование, увеличивая нагрузку на процессор, снижая Throughput, увеличивая Latency.

Но ещё опаснее то, что некоторые протоколы вообще не работают с фрагментацией. Например, IPsec в режиме ESP (Encapsulating Security Payload) не способен корректно шифровать фрагментированные пакеты, если фрагментация происходит до шифрования. Если исходный IP-пакет уже разбит, а затем завернут в ESP — нарушается целостность. В лучшем случае пакет будет отброшен, в худшем — VPN-сессия будет разрываться произвольно. Проблема осложняется тем, что разные реализации IPsec по-разному обрабатывают фрагменты, и не всегда предсказуемо.

Другой пример — VoIP и видеотрафик. В этих протоколах критична не только доставка, но и время доставки. Когда каждый аудиофрагмент приходит на 30-50 мс позже, пользователь это слышит. А если фрагменты приходят в разной последовательности или с потерями — начинается «механический» голос, артефакты, эхо, или сброс вызова. Даже HTTPS, казалось бы — «устойчивый» протокол, при большом объёме данных может испытывать проблемы, если MTU не согласован и TLS-пакеты не вмещаются в кадр.

VPN и MTU: конфликт по умолчанию

Особенно критично MTU влияет на производительность при работе через VPN. Возьмём, к примеру, OpenVPN в режиме TAP или IPsec в режиме туннелирования. Каждый туннель добавляет свои заголовки: от 20 до 60 байт. Если основной интерфейс рассчитан на 1500 байт, а туннель добавляет сверху ещё 60, то итоговая полезная нагрузка должна быть не более 1440 байт. Если этого не учесть, все пакеты будут фрагментироваться до отправки в туннель. В случае UDP-туннеля — фрагментированные UDP-пакеты передаются в любом случае. Но если используется TCP over TCP — начинается эффект «туннельной деградации»: дублирование окон, залипание ACK, перегрузки. Именно поэтому MTU в туннельных интерфейсах нужно снижать вручную, чтобы учитывать оверхед.

Именно из-за таких несогласований во многих организациях возникают необъяснимые падения скорости: всё вроде подключается, но работает медленно. Или «интернет есть, но сайт не открывается». Особенно часто такое поведение возникает при работе с облачными приложениями, при которых TLS-фреймы превышают 1500 байт. Сервер отправляет пакет, он фрагментируется, но один из фрагментов теряется — в итоге клиент не может установить соединение. А администратор начинает копать в сторону DNS, NAT, провайдера — забывая, что причина может быть одна цифра в MTU.

Path MTU Discovery — спасение или иллюзия?

Формально в IPv4 и IPv6 существует механизм PMTUD — Path MTU Discovery. Он должен автоматически определять максимальный размер пакета по маршруту. Работает это так: отправляется пакет с флагом DF (Don't Fragment). Если на пути есть устройство, которое не может его пропустить без фрагментации, оно должно отправить ICMP сообщение типа 3/4 (Fragmentation Needed). Получатель уменьшает размер и повторяет. Всё кажется логичным.

Но в реальной сети ICMP часто блокируется на firewall'ах. Или теряется на промежуточных маршрутизаторах. Или модифицируется NAT-устройствами. В результате PMTUD не работает. Пакеты отправляются, но ничего не приходит обратно. И пока не истечёт timeout или TCP не отдаст сессию, пользователь ждёт. Особенно тяжело это проявляется на HTTPS-соединениях, где передача первых байтов важна для установления ключей. Если Handshake не проходит — сайт «не открывается», хотя технически трафик разрешён.

Смешанные среды: Ethernet, PPPoE и VLAN

Ещё одна типичная проблема — несовместимость сред с разными MTU по умолчанию. Ethernet традиционно использует 1500 байт, но PPPoE ограничен 1492. Если по ошибке в PPPoE-интерфейсе MTU остаётся 1500 — провайдер просто отбросит пакеты. А если включён MSS Clamping — TCP MSS будет насильственно урезан, что может вызвать ошибки в приложениях, особенно VoIP и терминальных сессиях.

То же самое — при наличии VLAN. Тег VLAN добавляет 4 байта, и если это не учтено, кадр выходит за пределы 1500 и либо фрагментируется, либо отбрасывается. На уровне L2 это может вызывать ошибку «giant frame» или «baby giant», которая не всегда видна в логах. Особенно тяжело это проходит на старом оборудовании, которое не поддерживает Jumbo Frames или не умеет автоматическую настройку MTU.

Настройка MTU — это не одна цифра

Правильная настройка MTU требует понимания всей цепочки передачи данных. Нужно учитывать, какие протоколы используются (TCP, UDP, GRE, IPsec), какие туннели проходят (VPN, L2TP, PPPoE), какие дополнительные заголовки добавляются (VLAN, MPLS), какие устройства на пути (NAT, firewall, IDS). Нельзя просто поставить 1500 и надеяться на лучшее. Нельзя использовать Jumbo Frames, если инфраструктура к ним не готова. И нельзя оставлять MTU на «авто», если Вы внедряете туннелирование или многопротокольную маршрутизацию.

Один из эффективных подходов — вводить политику тестового снижения MTU на этапе проектирования. Лучше заранее ограничить MTU до безопасного уровня (например, 1400 байт), чем потом разбираться с фрагментацией. Особенно это актуально для туннелей, где фрагментация нарушает инкапсуляцию. На оборудовании D-Link это можно задать вручную на WAN-интерфейсах и в VPN-профилях. Кроме того, современные модели позволяют автоматически применять MSS Clamping, что особенно важно при использовании TCP-сессий поверх туннелей.

Как это изучается на практике

На курсе «Технологии TCP/IP» в ВиАкадемии мы уделяем параметрам MTU и фрагментации отдельное внимание. Слушатели настраивают маршруты, вводят туннели, моделируют сбои, анализируют TTL и DF-флаги, проверяют реакцию на PMTUD. Мы проверяем трассировки с фрагментацией, анализируем ICMP-ответы, исследуем поведение приложений при потерях фрагментов. Мы разбираем проблемы IPsec, GRE и HTTPS при несогласованном MTU, настраиваем MSS Clamping и реализуем fallback-сценарии. И главное — учим видеть проблему не в «скорости интернета», а в глубине сетевого стека.

Настроить MTU — значит знать, сколько байт выдержит Ваша сеть

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

Скорость сети — это не мегабиты, а предсказуемость маршрута.
Настройте MTU — и сеть задышит без обрывов.