Иногда VPN подключается без ошибок, значок соединения активен, но интернет ведёт себя странно: одни сайты открываются, другие зависают, изображения грузятся частично, видеосервисы долго начинают воспроизведение, а большие загрузки обрываются.

Одна из возможных причин — неправильно подобранный MTU.

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

Разберёмся, что он означает, почему VPN уменьшает доступный размер пакета и как отличить проблему MTU от неисправности DNS, сервера или маршрутизации.

Что такое MTU простыми словами

MTU — Maximum Transmission Unit, максимальный размер блока данных, который сетевой интерфейс может передать одним IP-пакетом в заданных условиях.

Проще представить это как ограничение на размер коробки.

Если сеть позволяет передать коробку размером до 1500 единиц, пакет размером 1400 проходит без проблем. Пакет размером 1600 уже придётся обработать иначе: разделить, уменьшить или вообще отбросить — в зависимости от версии IP, настроек сети и конкретного маршрута.

В Ethernet-сетях часто встречается MTU 1500 байт, поэтому это число стало привычным в сетевых настройках.

Но 1500 не является универсальным значением для любого интернет-маршрута.

Пакет проходит не через один интерфейс, а через цепочку сетей. У каждой из них могут быть собственные ограничения.

Что такое Path MTU

Для реального соединения важнее не MTU одного устройства, а Path MTU, или PMTU.

Это максимальный размер IP-пакета, который может пройти по всему маршруту от отправителя до получателя без необходимости фрагментации на промежуточном участке. По определению IETF, Path MTU равен минимальному MTU среди звеньев конкретного пути.

Представим маршрут:

компьютер → роутер → провайдер → транзитная сеть → сервер

Допустим, разные участки поддерживают:

• 1500 байт;
• 1500 байт;
• 1492 байта;
• 1500 байт.

Для всего этого пути фактический PMTU будет не 1500, а 1492 байта. Именно самое узкое место определяет предельный размер пакета.

Почему VPN усложняет ситуацию

VPN не просто пересылает исходный IP-пакет. Перед отправкой через туннель к нему добавляется дополнительная служебная информация.

Упрощённо обычный пакет выглядит так:

IP-заголовок + данные

После помещения в VPN-туннель появляется дополнительная оболочка:

внешний IP-заголовок + транспорт + VPN-заголовки + исходный пакет

Это называется encapsulation — инкапсуляция.

Получается, что пакет, который нормально помещался в физическую сеть без VPN, после добавления VPN-заголовков становится больше.

Именно здесь возникает проблема.

Простой пример

Предположим, физический маршрут позволяет передавать пакет размером до 1500 байт.

Приложение формирует пакет, близкий к этому пределу. Без VPN он проходит нормально.

После включения VPN к нему добавляется служебный overhead туннеля.

Теперь внешний пакет может стать больше допустимого размера. Сети приходится каким-то образом решить эту ситуацию.

В зависимости от протокола и сетевой конфигурации пакет может:

• быть разбит на части;
• быть отправлен меньшего размера;
• вызвать процедуру определения PMTU;
• быть отброшен.

Последний случай и создаёт особенно неприятные симптомы.

Почему VPN при этом может показывать «Подключено»

Установка VPN-туннеля и передача больших объёмов данных — не одно и то же. Handshake обычно состоит из сравнительно небольших пакетов.

Они способны успешно пройти по маршруту даже при проблеме с MTU.

В результате:

1. клиент связывается с VPN-сервером;
2. аутентификация проходит;
3. туннель создаётся;
4. приложение показывает «Подключено»;
5. начинается реальная передача трафика;
6. крупные пакеты начинают теряться.

Поэтому проблема MTU нередко выглядит именно как:

VPN соединён, но интернет почти не работает.

OpenVPN прямо отмечает в документации, что проблемы MTU часто проявляются как зависание соединения в периоды активной передачи данных.

Какие симптомы могут указывать на MTU

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

Например:

• VPN успешно подключается;
• небольшие сайты иногда открываются;
• крупные страницы зависают;
• изображения не догружаются;
• загрузка файлов останавливается;
• отдельные приложения работают, другие нет;
• соединение без VPN полностью стабильно;
• проблема исчезает после перехода на другую сеть;
• изменение MTU в рекомендованном диапазоне устраняет сбой.

Особенно характерна ситуация, когда соединение начинает «замирать» именно после роста объёма передаваемых данных.

Почему маленькие запросы работают, а большие — нет

Это один из главных признаков. Небольшой запрос легко помещается в допустимый размер пакета.

Например, клиент отправляет короткий DNS-запрос или небольшое HTTP-сообщение.

Оно проходит.

Затем сервер начинает передавать страницу, изображение или другой крупный объект. Сетевой стек формирует более крупные пакеты.

Если их размер после VPN-инкапсуляции превышает PMTU, появляются проблемы.

Пользователь в итоге получает странный эффект:

• соединение вроде есть;
• первые килобайты приходят;
• затем всё зависает.

А разве сеть не должна сама определить подходящий размер

Должна. Для этого существует Path MTU Discovery — PMTUD. Механизм позволяет отправителю определить максимальный размер пакетов, которые способен пропустить текущий маршрут.

Для IPv4 классический механизм описан в RFC 1191. Для IPv6 актуальный стандарт PMTUD описан в RFC 8201.

В нормальной ситуации всё происходит автоматически, и пользователь вообще не задумывается о MTU.

Проблемы возникают, когда информация о слишком большом пакете не возвращается отправителю корректно.

Как работает PMTUD

Упрощённая логика выглядит так.

Устройство отправляет пакет. На каком-то участке маршрута выясняется, что он слишком велик.

Сетевая система сообщает отправителю:

«Такой размер здесь не проходит. Используй пакет меньше».

Отправитель корректирует размер и продолжает передачу. Пользователь этого не замечает.

Но для работы механизма соответствующие служебные ICMP-сообщения должны доходить до отправителя.

Если они фильтруются или теряются, возникает так называемый PMTU black hole.

Что такое MTU black hole

Это ситуация, когда слишком большие пакеты исчезают, а отправитель не получает нормальной информации о причине. Маленькие пакеты продолжают работать. Большие — пропадают.

Соединение при этом может не разрываться полностью. Отсюда и характерные «зависания».

В IPv6 промежуточные маршрутизаторы вообще не выполняют обычную фрагментацию пакетов вместо отправителя: корректная работа с Path MTU особенно важна. RFC 8201 отдельно описывает использование сообщений Packet Too Big для определения PMTU.

Почему ICMP нельзя бездумно блокировать

У ICMP в интернете плохая репутация из-за старого совета «закройте ping для безопасности».

На практике ICMP используется не только для ping.

Он передаёт важную диагностическую информацию, в том числе необходимую для корректного определения Path MTU.

Если firewall блокирует все ICMP-сообщения без разбора, часть сетевых механизмов может перестать работать корректно.

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

IPv4 и IPv6 ведут себя по-разному

В IPv4 возможна фрагментация IP-пакетов, хотя современная сеть старается её избегать.

В IPv6 маршрутизаторы по пути не фрагментируют пакеты за отправителя.

Если пакет слишком велик для следующего участка, маршрутизатор должен отправить источнику ICMPv6 Packet Too Big. После этого отправитель уменьшает размер.

Такой подход делает корректную работу PMTUD особенно значимой в IPv6-соединениях.

Именно поэтому проблемы с фильтрацией ICMPv6 способны давать очень странное сетевое поведение.

Почему MTU VPN зависит от протокола

Разные VPN-протоколы добавляют разное количество служебных данных.

На итоговый overhead влияют:

• IPv4 или IPv6;
• UDP или TCP;
• сам VPN-протокол;
• алгоритмы аутентификации;
• дополнительные уровни туннелирования.

Поэтому нельзя сказать:

«Правильный MTU для VPN всегда равен X».

Такого универсального числа не существует.

Значение зависит от конкретного протокола и реального сетевого пути.

Почему советы «поставьте MTU 1400» иногда помогают

В интернете часто можно встретить рекомендации установить: 1400 или 1280 или другое конкретное значение.

Иногда это действительно устраняет проблему.

Причина проста: уменьшив внутренний пакет с запасом, пользователь делает так, чтобы после добавления VPN-заголовков внешний пакет всё равно помещался в Path MTU. Но это не означает, что выбранное число оптимально.

Можно решить проблему слишком грубо.

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

Соединение заработает, но его эффективность может снизиться.

Почему слишком маленький MTU тоже нежелателен

Чем меньше пакет, тем больше пакетов потребуется передать для того же объёма данных. Каждый из них имеет заголовки.

Поэтому чрезмерное уменьшение MTU увеличивает долю служебного overhead. Условно говоря, выгоднее перевезти груз в десяти нормальных коробках, чем в пятидесяти маленьких.

Слишком маленький MTU может привести к:

• большему количеству пакетов;
• дополнительной нагрузке на CPU;
• росту относительного overhead;
• снижению эффективной пропускной способности.

RFC 8201 также отмечает, что использование пакетов существенно меньше доступного Path MTU приводит к неоптимальному расходованию сетевых ресурсов и снижению эффективности.

Поэтому цель — не найти самый маленький MTU, а подобрать достаточно большой размер, который стабильно проходит по маршруту.

MTU и MSS — в чём разница

Эти два понятия часто путают.

MTU относится к размеру IP-пакета на сетевом уровне.

MSS — Maximum Segment Size — к максимальному количеству TCP-данных внутри одного TCP-сегмента.

MSS меньше MTU, потому что часть пространства занимают IP- и TCP-заголовки.

Упрощённо для классического IPv4 без дополнительных опций:

MSS ≈ MTU − IP header − TCP header

Например, при MTU 1500 часто получается MSS 1460.

Но VPN добавляет дополнительную инкапсуляцию, поэтому ситуация снова становится сложнее.

Зачем VPN использует MSS clamping

Для TCP-трафика проблему можно частично решать не только изменением MTU самого туннеля, но и ограничением объявляемого MSS.

Этот механизм часто называют MSS clamping.

Он сообщает TCP-сторонам:

«Не создавайте сегменты больше определённого размера».

Это позволяет заранее уменьшить TCP-пакеты так, чтобы они после VPN-инкапсуляции помещались в допустимый MTU.

OpenVPN, например, имеет параметр mssfix, предназначенный именно для ограничения TCP-размера с учётом туннелирования. Его документация рекомендует не менять MTU без необходимости и отдельно описывает mssfix как средство борьбы с проблемами размеров пакетов.

Фрагментация — не всегда хорошее решение

Самый очевидный вариант — просто разбить большой пакет на несколько фрагментов. Но фрагментация имеет недостатки.

Она:

• создаёт дополнительный overhead;
• усложняет обработку;
• увеличивает последствия потери одного фрагмента;
• может взаимодействовать с firewall и NAT;
• иногда ухудшает производительность.

Поэтому современные VPN стараются подобрать размер пакетов так, чтобы избегать IP-фрагментации там, где это возможно.

OpenVPN прямо указывает, что внутренняя функция fragment — скорее крайний вариант при сломанном Path MTU Discovery, а не стандартная замена корректной работе сети.

Может ли MTU отличаться по Wi-Fi и мобильной сети

Да. И это одна из причин, почему VPN иногда отлично работает дома, но нестабилен через LTE или 5G. При смене Wi-Fi на мобильные данные меняется весь путь до VPN-сервера.

Может измениться:

• IP-версия;
• оператор;
• NAT;
• количество промежуточных сетей;
• туннелирование внутри операторской инфраструктуры;
• фактический Path MTU.

В итоге VPN с одним и тем же собственным MTU на одной сети работает, а на другой сталкивается с ограничением по размеру пакета.

Это особенно полезная гипотеза, если симптом выглядит так:

Wi-Fi + VPN → стабильно

мобильная сеть + VPN → соединение есть, страницы зависают

Но MTU — только одна из возможных причин такого поведения. Похожие симптомы способны создавать DNS и маршрутизация.

Может ли MTU зависеть от VPN-сервера

Да. При смене VPN-сервера меняется сетевой маршрут.

Например:

пользователь → сервер в Германии

и:

пользователь → сервер в Нидерландах

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

Поэтому иногда один VPN-сервер работает нормально, а соединение с другим проявляет характерные проблемы с крупными пакетами. Смена сервера в таком случае становится полезным диагностическим тестом.

Как отличить проблему MTU от DNS

DNS-проблема чаще проявляется так:

• сайт по доменному имени не открывается;
• разрешение имени занимает много времени;
• после получения IP соединение работает нормально.

Проблема MTU выглядит иначе:

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

Конечно, пользователь не всегда может определить это визуально. Но если сайт начинает загружаться и останавливается на середине, MTU становится более вероятной гипотезой, чем простой DNS-сбой.

MTU или плохой VPN-сервер

Перегруженный сервер чаще вызывает:

• низкую скорость в целом;
• высокий ping;
• нестабильную задержку;
• равномерно медленную загрузку.

При MTU-проблеме поведение нередко более «ломаное»:

• маленькие передачи проходят быстро;
• крупные зависают полностью;
• отдельные сайты работают идеально;
• другие практически невозможно открыть.

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

Как проверить гипотезу с MTU

Правильный способ зависит от операционной системы, VPN-протокола и доступных инструментов.

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

Но у такого теста есть ограничения.

Некоторые узлы:

• не отвечают на ping;
• фильтруют ICMP Echo;
• используют асимметричную маршрутизацию;
• имеют другой маршрут для диагностического трафика.

Поэтому один результат ping нельзя автоматически считать точным MTU всего VPN-соединения.

Нужно ли обычному пользователю рассчитывать MTU вручную

В большинстве случаев — нет. Современный VPN-клиент должен сам задавать разумные параметры туннеля.

Сначала лучше проверить более простые вещи:

1. другой VPN-сервер;
2. другой поддерживаемый протокол;
3. другую сеть;
4. обновление приложения;
5. отсутствие конфликтующих сетевых программ.

Если проблема повторяется именно при передаче крупных данных и техподдержка подтверждает подозрение на MTU, тогда ручная настройка становится оправданной.

Почему не стоит сразу ставить случайное значение

Представим, пользователь находит инструкцию:

«Если VPN тормозит, установите MTU 1280».

Он меняет параметр, и проблема действительно исчезает. Можно сделать вывод, что значение правильное.

Но технически тест доказал лишь одно:

пакеты такого размера помещаются в текущий маршрут.

Он не доказал, что 1280 — максимальный или оптимальный размер.

Возможно, без проблем работали бы:

• 1300;
• 1360;
• 1400;
• 1420;
• другое значение.

Чем ближе корректно работающий MTU к реальному пределу маршрута, тем эффективнее используется сеть.

Почему нельзя рекомендовать одно MTU для WireGuard, OpenVPN и других протоколов

У каждого протокола своя структура пакета. Также различается внешний транспорт.

Например, на overhead влияет, проходит ли туннель:

• поверх IPv4;
• поверх IPv6;
• через UDP;
• через дополнительную обёртку.

Поэтому значение, которое подходит одному VPN-подключению, необязательно будет оптимально для другого.

Кроме того, меняется не только протокол, но и путь до сервера. Именно поэтому универсальные таблицы «лучший MTU для VPN» следует воспринимать как отправную точку диагностики, а не как стандарт.

Нужно ли менять MTU на роутере

Обычно не первым делом. Изменение WAN MTU роутера затрагивает весь домашний трафик, а проблема может касаться только виртуального VPN-интерфейса.

Если VPN-клиент установлен непосредственно на компьютере или смартфоне, правильнее сначала работать с настройками самого VPN.

MTU WAN-интерфейса роутера имеет смысл менять только при подтверждённой проблеме на уровне подключения провайдера — например, если это предусмотрено его конфигурацией.

А если VPN работает на самом роутере

Тогда ситуация меняется.

VPN-интерфейс создаётся непосредственно на маршрутизаторе, и именно он выполняет инкапсуляцию трафика устройств домашней сети.

В таком случае неправильный MTU VPN-интерфейса может влиять сразу на:

• компьютеры;
• смартфоны;
• телевизоры;
• игровые устройства.

Характерный признак: после включения VPN на роутере одинаковые странности появляются сразу на нескольких устройствах.

Может ли неправильный MTU снизить скорость без полного зависания

Да. Проблема не всегда выглядит как полный black hole.

Неоптимальная обработка пакетов способна вызывать:

• дополнительную фрагментацию;
• повторную передачу TCP;
• рост нагрузки;
• уменьшение полезной пропускной способности.

В таком случае VPN продолжает работать, но результаты теста скорости хуже ожидаемых.

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

Когда MTU действительно стоит подозревать

Вот более показательный набор условий:

• без VPN соединение работает нормально;
• VPN устанавливается без ошибки;
• проблема появляется сразу после включения туннеля;
• небольшие передачи проходят;
• крупные соединения зависают или обрываются;
• смена сети влияет на проблему;
• смена протокола влияет на проблему;
• уменьшение MTU по рекомендации разработчика устраняет сбой.

Чем больше совпадений, тем логичнее исследовать MTU.

Когда проблема, скорее всего, не в MTU

MTU менее вероятен, если:

• VPN вообще не способен установить соединение;
• приложение сообщает об ошибке авторизации;
• не работает только DNS;
• VPN-сервер полностью недоступен;
• интернет без VPN тоже нестабилен;
• соединение разрывается вместе с потерей мобильного сигнала.

В таких случаях сначала нужно искать другую причину.

Безопасный порядок диагностики

Если VPN подключается, но работает нестабильно, двигайтесь от простого к сложному. Сначала проверьте интернет без VPN.

Затем смените VPN-сервер.

Если приложение поддерживает несколько протоколов, сравните их.

Проверьте ту же конфигурацию через другую сеть: например, Wi-Fi и мобильный интернет.

Отключите сторонний DNS, firewall или другое VPN-приложение, если они используются одновременно.

И только после этого переходите к ручной диагностике MTU.

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

Что сообщить технической поддержке

Вместо сообщения:

«VPN плохо работает»

лучше передать конкретные наблюдения.

Например:

VPN подключается через Wi-Fi и LTE. Через Wi-Fi всё работает нормально. Через LTE небольшие сайты открываются, но загрузка изображений и крупных файлов зависает. Проблема воспроизводится на двух серверах. При другом протоколе её нет.

Такой отчёт уже позволяет инженеру подозревать конкретный сетевой уровень.

Полезно также указать:

• операционную систему;
• версию VPN-клиента;
• протокол;
• сервер;
• тип сети;
• модель роутера или оператора;
• точный характер зависания.

Если приложение умеет создавать диагностический лог, отправляйте его только через официальный канал поддержки и предварительно убедитесь, что в нём нет секретных ключей или данных доступа.

Частые вопросы

Что такое MTU в VPN?

Это ограничение на размер IP-пакета, который может передаваться через сетевой интерфейс или маршрут. В VPN доступный размер особенно важен, потому что туннель добавляет к исходному пакету дополнительные заголовки.

Какой MTU считается правильным для VPN?

Универсального значения нет. Он зависит от протокола, IPv4/IPv6, внешнего транспорта и фактического Path MTU до конкретного VPN-сервера.

Почему часто встречается число 1500?

MTU 1500 широко используется в Ethernet-сетях. Но VPN-туннель добавляет overhead, а отдельные участки интернет-маршрута могут иметь меньший MTU.

Поэтому 1500 не является автоматическим правильным значением для VPN-интерфейса.

Почему уменьшение MTU исправляет VPN?

Более маленький исходный пакет оставляет дополнительное место для заголовков VPN. После инкапсуляции итоговый пакет с большей вероятностью помещается в допустимый Path MTU и не требует проблемной фрагментации.

Чем меньше MTU, тем лучше?

Нет. Слишком маленький MTU увеличивает количество пакетов и долю служебных данных, что может снижать эффективность соединения.

Что такое PMTU?

Path MTU — максимальный размер IP-пакета, который может пройти через весь текущий маршрут без превышения MTU какого-либо участка. Он определяется самым маленьким MTU на пути.

Что такое PMTUD?

Path MTU Discovery — механизм, с помощью которого узел определяет допустимый размер пакетов для конкретного маршрута.

Почему блокировка ICMP может мешать VPN?

Некоторые ICMP-сообщения сообщают отправителю, что пакет слишком велик для текущего маршрута. Если такая информация блокируется, устройство может продолжать отправлять пакеты неподходящего размера, создавая эффект black hole.

MTU и MSS — это одно и то же?

Нет. MTU относится к IP-пакету целиком, а MSS определяет объём полезных TCP-данных внутри сегмента.

Нужно ли менять MTU вручную?

Обычно нет. OpenVPN, например, прямо рекомендует в большинстве случаев оставлять tun-mtu по умолчанию и прибегать к низкоуровневой настройке только при реальной необходимости.

 

MTU — незаметный параметр, который становится важным в тот момент, когда к обычному сетевому пакету добавляется VPN-инкапсуляция.

Без VPN пакет может идеально помещаться в возможности маршрута. После добавления внешнего IP-заголовка, UDP или TCP и данных самого туннеля его размер увеличивается. Если получившийся пакет превышает Path MTU и сеть не может корректно сообщить об этом отправителю, часть трафика начинает исчезать.

Из-за этого возникает особенно неприятный тип неисправности: VPN показывает активное соединение, небольшие запросы проходят, но страницы, файлы и другие крупные передачи зависают.

При этом MTU не следует делать первым подозреваемым при любой проблеме с VPN.

Сначала стоит исключить сервер, протокол, DNS, сеть и системные ограничения. И только если симптомы действительно похожи на проблему размера пакетов, имеет смысл переходить к диагностике PMTU, MSS и параметров туннеля.

Главное правило — не искать магическое число MTU из случайной инструкции.

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