Бывает неприятная ситуация: VPN успешно подключился, приложение показывает активный туннель, но интернет после этого работает лишь частично. Небольшой сайт открывается, а тяжёлая страница зависает. Текст загружается, изображения — нет. Файл начинает скачиваться и вскоре останавливается.
Подобное поведение иногда связано с MTU — ограничением на размер сетевого пакета. Это не самая частая причина проблем с VPN и точно не повод сразу открывать настройки и вводить найденное на форуме число. Но у неисправностей MTU есть характерная особенность: сам туннель может работать, а передача определённых пакетов — уже нет.
Разберём, откуда берётся этот эффект и когда MTU вообще имеет смысл подозревать.
MTU без сетевой теории
Аббревиатура MTU расшифровывается как Maximum Transmission Unit.
Если не углубляться в детали, это предел размера IP-пакета, который может пройти через конкретный сетевой интерфейс или участок сети без необходимости дополнительной обработки из-за его размера. Для Ethernet широко известно значение 1500 байт. Отсюда иногда возникает ошибочное представление, что MTU интернета всегда равен 1500.
Это не так.
Между компьютером и удалённым сервером может находиться множество сетей, каждая со своими ограничениями.
Представим маршрут:
ноутбук → роутер → сеть провайдера → транзитный оператор → сервер
Если большая часть пути пропускает пакеты до 1500 байт, но один участок — только 1492, ориентироваться придётся на более низкий предел. Здесь появляется понятие Path MTU.
Path MTU важнее локального значения
Path MTU, или PMTU, — максимально допустимый размер IP-пакета для всего конкретного маршрута. Его определяет самое узкое место на пути.
Это важно по двум причинам.
- Во-первых, MTU вашего Ethernet-адаптера ещё ничего не говорит о возможностях всего пути.
- Во-вторых, маршрут в интернете может меняться. Сегодня пакеты идут через одну сеть, завтра — через другую. Значит, может измениться и PMTU.
VPN добавляет сюда ещё один уровень сложности.
Почему включение VPN меняет размер пакета
VPN нужно каким-то образом доставить исходный трафик от устройства до VPN-сервера. Для этого пакет помещается внутрь другой сетевой конструкции — происходит инкапсуляция.
Условно без VPN:
IP-заголовок + данные
С VPN:
внешний IP-заголовок + транспортный заголовок + служебные данные VPN + исходный пакет
То есть первоначальный пакет получает дополнительную оболочку. Если исходный пакет уже был близок к предельному размеру маршрута, после инкапсуляции итоговый внешний пакет может этот предел превысить. Отсюда и возникают сложности.
Почему нельзя просто вычесть фиксированное число байт
Иногда встречаются таблицы примерно такого вида:
Ethernet 1500 → VPN MTU должен быть X.
Такие числа могут быть полезной отправной точкой для конкретной конфигурации, но универсальной формулы нет.
Overhead зависит от нескольких вещей:
- VPN-протокола;
- IPv4 или IPv6 снаружи туннеля;
- UDP или TCP;
- конкретных расширений и служебных полей;
- дополнительной инкапсуляции в сети;
- фактического PMTU до VPN-сервера.
Поэтому два пользователя одного VPN могут иметь разные оптимальные параметры. Даже у одного пользователя ситуация способна измениться после перехода с Wi-Fi на LTE.
Почему VPN подключается, хотя MTU неправильный
Именно это часто сбивает с толку. Если приложение показывает «Подключено», кажется логичным считать сетевую часть исправной. Однако установление туннеля и активная передача данных — разные этапы.
Служебные сообщения, необходимые для начала соединения, могут быть достаточно небольшими и успешно пройти по маршруту.
Получается примерно следующее:
- клиент связывается с сервером;
- проходит handshake;
- создаётся VPN-интерфейс;
- статус меняется на «Подключено»;
- пользователь начинает передавать более крупные объёмы данных;
- часть пакетов упирается в ограничение пути.
Поэтому типичная MTU-проблема может выглядеть как исправный VPN, который «ломается» только под нагрузкой.
Как это выглядит со стороны пользователя
У проблемы нет одного уникального симптома, но некоторые наблюдения особенно показательны.
Например:
- VPN подключается быстро;
- интернет без VPN работает нормально;
- короткие запросы проходят;
- тяжёлые страницы открываются не полностью;
- загрузка крупного файла внезапно останавливается;
- некоторые сайты работают, а другие почти нет;
- поведение меняется при переключении между Wi-Fi и мобильной сетью;
- другой VPN-протокол работает нормально.
Ещё один характерный сценарий — страница начинает загружаться очень быстро, а затем словно упирается в стену. Это уже больше похоже на проблему передачи пакетов, чем на обычный недостаток скорости.
Почему часть трафика проходит
Размер сетевых пакетов не всегда одинаков. Небольшой запрос помещается в доступный предел без труда. Например, клиенту нужно отправить совсем немного данных.
Пакет проходит. Далее начинается передача более крупного содержимого, сетевой стек формирует пакеты большего размера — и именно здесь проявляется ограничение.
Отсюда возникает визуально странный эффект:
соединение существует, сервер отвечает, но полноценный обмен данными не идёт.
Разве сеть сама не умеет решать такую проблему
В нормальной ситуации — умеет. Для этого существует Path MTU Discovery. Его задача — определить, пакеты какого размера способны пройти по текущему маршруту.
Если отправитель посылает слишком большой пакет, сетевой узел на проблемном участке должен сообщить об этом, после чего источник уменьшает размер следующих пакетов. Если всё работает правильно, пользователь о существовании PMTU вообще не узнаёт.
Проблемы начинаются тогда, когда обратное сообщение не доходит.
Как появляется PMTU black hole
Представим, что пакет слишком велик для одного из участков маршрута. Маршрутизатор его отбрасывает и формирует служебное сообщение для отправителя. Но где-то по дороге это сообщение блокируется firewall или фильтром.
Получается неприятная ситуация:
- большой пакет пропал;
- отправитель не знает, почему;
- корректное новое значение PMTU не получено;
- следующий пакет отправляется в тех же условиях.
Связь будто есть, но определённый трафик исчезает. Такое состояние называют PMTU black hole.
Причём здесь ICMP
ICMP часто ошибочно воспринимают исключительно как «протокол ping». На самом деле он выполняет гораздо больше служебных задач. В частности, с его помощью сеть сообщает об ошибках доставки и ограничениях размера пакета. Поэтому правило firewall вида:
«запретить вообще весь ICMP» может иметь побочные последствия.
Для IPv6 это особенно заметно, потому что PMTUD использует ICMPv6 Packet Too Big. Если такие сообщения блокировать без разбора, отправитель может не узнать, что ему следует уменьшить пакет.
IPv4 и IPv6 отличаются
В IPv4 исторически возможна фрагментация пакетов маршрутизаторами, если соответствующие условия это допускают. У IPv6 модель другая.
Промежуточные маршрутизаторы не должны фрагментировать пакет вместо отправителя. Если пакет нельзя передать дальше из-за MTU следующего участка, источник должен получить ICMPv6 Packet Too Big и адаптировать размер.
Поэтому корректная доставка ICMPv6 играет существенную роль в нормальной работе IPv6.
Откуда берутся зависания именно через мобильную сеть
Допустим, дома VPN работает идеально. Пользователь отключает Wi-Fi, смартфон переходит в 5G — и появляются зависания. Протокол и VPN-сервер остались теми же. Изменился маршрут.
Мобильная сеть может отличаться по:
- IPv4/IPv6;
- внутреннему туннелированию оператора;
- NAT;
- маршрутизации;
- промежуточным сетям;
- фактическому Path MTU.
Поэтому одна и та же конфигурация VPN способна вести себя по-разному через домашнего и мобильного провайдера. Но автоматически считать MTU виновником нельзя. Очень похожее поведение могут создавать DNS, потеря UDP-пакетов или особенности маршрутизации.
Почему смена VPN-сервера иногда решает проблему
Путь в интернет зависит от адреса назначения. Сервер во Франкфурте и сервер в Варшаве могут находиться в разных дата-центрах, автономных системах и транзитных сетях. Соответственно, меняется маршрут — а вместе с ним может поменяться и PMTU.
Поэтому проверка другого сервера полезна не только при перегрузке или высоком ping. Она помогает понять, зависит ли неисправность от конкретного сетевого пути. Если с одним сервером крупные передачи регулярно зависают, а с другим всё работает, это ценная информация для диагностики.
MTU не равно MSS
Ещё одна распространённая путаница связана с TCP MSS. MTU определяет размер пакета на IP-уровне.
MSS, или Maximum Segment Size, описывает максимальный объём TCP-данных внутри TCP-сегмента. В простом случае для IPv4 без дополнительных опций часто приводят пример:
MTU 1500 → TCP MSS 1460
Потому что часть пространства занимают заголовки IPv4 и TCP.
Но это лишь базовый пример. При VPN сверху добавляются дополнительные заголовки, поэтому расчёт реального допустимого размера становится сложнее.
Что такое MSS clamping
Для TCP существует удобный способ заранее удерживать сегменты в безопасных пределах — MSS clamping. Устройство изменяет объявляемое значение MSS так, чтобы TCP-стороны не пытались отправлять слишком крупные сегменты.
Смысл примерно такой:
не ждать, пока большой TCP-пакет создаст проблему, а сразу договориться использовать меньший размер.
В некоторых VPN-решениях это штатный инструмент. Например, OpenVPN использует параметр mssfix, который помогает уменьшать вероятность проблем с TCP-пакетами при некорректной работе Path MTU Discovery.
При этом конкретные параметры зависят от протокола. Копировать настройки OpenVPN в другую VPN-систему нельзя.
Почему фрагментация не является идеальным решением
Можно задать очевидный вопрос: если пакет большой, почему его просто не разбить на несколько частей? В некоторых сетевых ситуациях так и происходит. Но фрагментация имеет цену.
Она добавляет служебные расходы и усложняет обработку. Потеря одного фрагмента влияет на восстановление исходного пакета. Кроме того, фрагментированный трафик иногда хуже взаимодействует с NAT, firewall и другими промежуточными устройствами.
Поэтому более аккуратный подход — формировать пакеты подходящего размера заранее.
Почему уменьшение MTU часто «магически» помогает
Предположим, после инкапсуляции пакет периодически превышает предел маршрута. Если уменьшить MTU виртуального интерфейса, внутрь VPN начнут попадать более маленькие пакеты.
После добавления служебных заголовков итоговый пакет теперь помещается в PMTU. Зависания исчезают.
Именно поэтому в интернете так много советов: «поставьте MTU 1400» или «попробуйте 1300».
Проблема в том, что успешный результат ещё не означает, что выбранное значение оптимально. Он доказывает только одно: пакеты такого размера проходят.
Почему не существует «лучшего MTU для VPN»
Допустим, значение 1300 работает, но возможно, без проблем работали бы и 1350, и 1400, и 1420. Если установить MTU заметно ниже необходимого, соединение сохранит работоспособность, однако станет передавать больше пакетов для того же объёма полезных данных. А каждый пакет несёт собственные заголовки. Иными словами, уменьшать размер до бесконечности невыгодно.
Задача настройки — не получить минимально возможное значение, а найти достаточно большой размер, который стабильно проходит по конкретному маршруту.
А что насчёт 1280
Число 1280 часто всплывает в разговорах об IPv6, потому что это минимальный IPv6 link MTU, с которым связаны требования протокола.
Но из этого не следует, что 1280 — рекомендуемый MTU для любого VPN.
Установка такого значения может замаскировать проблему, поскольку пакеты становятся значительно меньше. Однако реальный маршрут зачастую допускает существенно больший размер. Поэтому использовать 1280 как универсальную настройку «на всякий случай» неправильно.
Может ли слишком маленький MTU замедлить VPN
Да. Например, для передачи условного мегабайта данных при более маленьких пакетах потребуется обработать больше отдельных пакетов. Каждый из них несёт:
- IP-заголовок;
- транспортный заголовок;
- VPN-overhead;
- другие служебные данные.
В результате возрастает доля неполезного трафика. Дополнительно растёт число операций, которые приходится выполнять сетевому стеку и VPN-клиенту. На современном устройстве небольшая разница может быть незаметной, но беспричинно уменьшать MTU всё равно не стоит.
Как отличить MTU от проблемы DNS
По пользовательским ощущениям сетевые неисправности часто похожи друг на друга. При DNS-сбое обычно возникает проблема раньше: устройство не может нормально преобразовать доменное имя в IP-адрес. При MTU-проблеме соединение с сервером уже может существовать.
Типичный сценарий:
- имя сайта разрешилось;
- соединение установлено;
- сервер начал отвечать;
- передача большого объёма данных остановилась.
Если сайт вообще не начинает открываться, это ещё не доказательство проблемы DNS. Но если первые данные приходят, а затем поток стабильно «замирает», гипотеза с MTU выглядит убедительнее.
А если просто медленно
Низкая скорость сама по себе — слабый аргумент в пользу MTU. Чаще причиной оказываются:
- перегруженный VPN-сервер;
- далёкая локация;
- высокий ping;
- плохой мобильный сигнал;
- неудачная маршрутизация;
- потеря пакетов.
MTU стоит подозревать сильнее, когда проблема неравномерная: небольшой обмен проходит, а крупный резко зависает или систематически обрывается.
Как диагностируют MTU специалисты
На настольных операционных системах можно исследовать предельный размер пакета диагностическими утилитами. Например, для IPv4 часто используют ping с заданным размером полезной нагрузки и запретом фрагментации. Размер постепенно изменяют и проверяют, какие пакеты проходят.
Существуют также трассировки, анализ ICMP, захват трафика и специализированные механизмы PMTU Discovery. Однако у простого ping-теста есть ограничения. Удалённый сервер может не отвечать на ICMP Echo вообще.
Кроме того, путь диагностического пакета не всегда полностью отражает поведение конкретного VPN-трафика. Поэтому найденное через ping число не следует автоматически копировать в настройки VPN.
Нужно ли пользователю самостоятельно вычислять MTU
Обычно нет. Хороший VPN-клиент должен выбирать разумные параметры самостоятельно. Если появились проблемы, последовательность проверки лучше начать не с MTU.
Сначала имеет смысл:
- подключиться к другому серверу;
- проверить другой поддерживаемый VPN-протокол;
- попробовать другую сеть;
- обновить приложение;
- временно исключить конфликт с другим VPN, firewall или сетевым фильтром.
Только если проблема остаётся и её характер похож именно на потерю крупных пакетов, стоит исследовать MTU глубже.
Когда ручное изменение оправдано
Ручная настройка имеет смысл, если есть несколько совпадающих признаков.
Например:
- VPN соединяется нормально;
- без VPN интернет полностью исправен;
- мелкие передачи работают;
- крупные систематически зависают;
- симптом воспроизводится;
- разработчик или поддержка допускает изменение MTU;
- уменьшение значения действительно устраняет неисправность.
В таком случае изменение параметра уже является осмысленной настройкой, а не случайным экспериментом.
Нужно ли менять MTU на домашнем роутере
Необязательно. WAN MTU роутера и MTU VPN-интерфейса — не одно и то же. Если VPN работает на ноутбуке, изменение WAN-параметра маршрутизатора затронет всю домашнюю сеть, хотя проблема может существовать исключительно внутри VPN-клиента.
Менять глобальный MTU на роутере имеет смысл, если есть подтверждённая причина на уровне самого подключения к провайдеру. Если же VPN запущен непосредственно на маршрутизаторе, тогда его виртуальный интерфейс действительно становится частью общей сетевой схемы.
VPN на роутере — отдельный случай
Когда VPN-туннель создаёт сам роутер, через него может идти трафик сразу множества устройств. Неверно подобранный размер пакетов тогда способен одновременно проявиться на:
- телефоне;
- ноутбуке;
- телевизоре;
- игровой консоли.
Это сильный диагностический признак. Если проблемы начались на всех устройствах сразу после включения VPN на маршрутизаторе, параметры самого туннеля становятся более вероятным источником сбоя.
Короткий алгоритм проверки
Если VPN подключён, но часть интернета зависает, практический порядок может быть таким.
- Сначала выключите VPN и убедитесь, что обычное соединение стабильно.
- Затем подключитесь к другому VPN-серверу.
- После этого сравните другой поддерживаемый протокол.
- Если возможно — смените сеть: Wi-Fi на мобильную или наоборот.
- Если характер сбоя сохраняется, обратите внимание, есть ли разница между короткими запросами и крупными загрузками.
- Только после этого стоит переходить к MTU, MSS и анализу ICMP.
Такой порядок полезен потому, что он отсеивает гораздо более распространённые причины до изменения низкоуровневых параметров.
Что написать в поддержку
Технической поддержке полезнее не предположение «у меня неправильный MTU», а факты.
Например:
VPN подключается без ошибок. Через домашний Wi-Fi сайты работают нормально. Через 5G короткие страницы открываются, но изображения и загрузка файлов регулярно зависают. Проверено на двух серверах. С другим VPN-протоколом проблема не проявляется.
Из такого описания уже видно:
- туннель создаётся;
- неисправность зависит от сети;
- сервер не единственная переменная;
- поведение зависит от протокола;
- проблема проявляется при более крупной передаче.
Это намного информативнее случайного MTU из настроек.
Частые вопросы
Что такое MTU простыми словами?
Это ограничение на размер сетевого пакета, который можно передать через определённый интерфейс или маршрут без превышения допустимого размера.
Что такое Path MTU?
Это максимально допустимый размер пакета для всего конкретного пути от отправителя до получателя. Его ограничивает участок маршрута с самым маленьким MTU.
Почему VPN влияет на MTU?
Потому что VPN инкапсулирует исходные данные и добавляет собственные заголовки. Внешний пакет становится больше исходного.
Почему VPN подключён, но сайты не грузятся?
Одна из возможных причин — слишком крупные пакеты, которые не проходят по маршруту после инкапсуляции. Однако такой же симптом могут давать DNS, маршрутизация и другие сетевые проблемы.
Какой MTU поставить для VPN?
Универсального значения нет. Оно зависит от протокола, IP-версии, транспорта и конкретного маршрута.
Значение 1500 всегда правильное?
Нет. 1500 часто встречается в Ethernet, но фактический PMTU маршрута может быть ниже, а VPN добавляет дополнительный overhead.
Почему уменьшение MTU иногда сразу помогает?
Потому что меньший внутренний пакет после VPN-инкапсуляции легче помещается в ограничение внешнего маршрута.
Чем MTU отличается от MSS?
MTU относится к IP-пакету, а MSS определяет максимальный объём TCP-данных в одном сегменте.
Что такое MSS clamping?
Это корректировка TCP MSS с целью заранее предотвратить формирование слишком крупных TCP-сегментов. Некоторые VPN используют этот механизм для обхода проблем PMTU.
Может ли блокировка ICMP привести к проблеме?
Да. В частности, IPv6 PMTUD зависит от ICMPv6 Packet Too Big. Если такие сообщения не доходят, соединение может успешно установиться и затем зависнуть при передаче более крупных данных.
Нужно ли менять MTU вручную?
Для большинства пользователей — нет. Сначала лучше проверить сервер, протокол, сеть и настройки приложения.
MTU редко заметен, пока сеть работает нормально. VPN делает этот параметр более чувствительным, потому что добавляет к исходному пакету собственную служебную оболочку. Пакет, который свободно проходил без туннеля, после инкапсуляции может оказаться слишком большим для одного из участков пути.
Обычно сетевой стек способен обнаружить такое ограничение и скорректировать размер автоматически. Но если Path MTU Discovery нарушен — например, необходимые служебные сообщения теряются или фильтруются — появляется характерная неисправность: соединение создаётся, небольшие пакеты проходят, а активная передача начинает зависать. При этом универсального «правильного MTU для VPN» нет.
Конкретное значение зависит от протокола и сетевого маршрута. Слишком большое способно привести к проблемам доставки, а чрезмерно маленькое — впустую увеличить число пакетов и служебный overhead.
Поэтому разумный подход состоит не в поиске магического числа, а в нормальной диагностике: сначала исключить сервер, сеть, протокол и DNS, а уже затем проверять MTU и MSS, если характер сбоя действительно на них указывает.