Что такое MTU и почему некоторые сайты зависают через VPN

Что именно ограничивает MTU интерфейса?

Интерфейс соединяет устройство с конкретным сетевым звеном: это может быть Wi-Fi, мобильная сеть или виртуальный VPN-адаптер. Его MTU задаёт максимальный размер IP-пакета, который этот интерфейс должен передать одной сетевой единицей. Параметр относится к точке отправки, а не ко всему интернет-маршруту сразу.

MTU не является скоростью, лимитом тарифа или размером скачиваемого файла. Файл разбивается транспортным протоколом на множество пакетов, и ограничение применяется к каждому из них. Поэтому вывод «документ большой, значит виноват MTU» смешивает объём объекта с размером отдельного сетевого пакета.

Чем link MTU и Path MTU отличаются от MTU интерфейса?

Link MTU описывает максимальный пакет, который можно передать одним куском по отдельному звену. Путь до сайта состоит из нескольких таких звеньев.

Согласно определению Path MTU, или PMTU, его значение равно минимальному link MTU среди всех звеньев между источником и назначением.

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

Почему VPN добавляет ещё одно ограничение?

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

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

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

Как устройство узнаёт Path MTU?

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

В IPv6 узел на таком звене отбрасывает пакет и отправляет источнику сообщение Packet Too Big. Получив его, источник корректирует оценку PMTU для соответствующего назначения.

Если нужное служебное сообщение не достигает источника или не обрабатывается, соединение может попасть в состояние black hole: начальный обмен проходит, а последующая передача останавливается. Это свойство конкретного пути и направления. Свежий handshake VPN не исключает проблему после установления туннеля.

Чем фрагментация IPv4 отличается от IPv6?

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

В IPv4 фрагментация маршрутизатором возможна при определённых условиях, но рассчитывать на неё как на универсальное исправление нельзя: флаги пакета, фильтры и поведение пути различаются. Для пользовательской диагностики достаточно знать, что IPv4 и IPv6 обрабатывают этот случай не одинаково, а ручное число без контекста не переносится между ними.

Какие симптомы действительно поддерживают гипотезу PMTU?

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

Общий размер файла и время, которое он должен передаваться, не определяют PMTU напрямую: каждый пакет проверяется отдельно. Похожее зависание вызывают CDN, фильтр, сбой сайта и потери связи. Гипотеза становится содержательной только при повторяемой границе после установления соединения и различии между сетевыми путями.

Какие сравнения безопасны без изменения параметров?

Повторите один публичный запрос на том же устройстве и с тем же VPN-профилем в двух разрешённых сетях. Зафиксируйте время, домен, момент остановки, наличие свежего handshake и движение обоих счётчиков. Не меняйте одновременно браузер, DNS и VPN-приложение, иначе сравнение потеряет контрольное условие.

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

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

Когда остановить проверку и не подбирать числа?

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

Запишите это как гипотезу о пути, а не как готовый диагноз MTU. Дальнейший перебор способен изменить исходную картину и создать новые ошибки.

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