Проблемы MTU в WireGuard вероятны, когда есть актуальное рукопожатие и небольшие обмены работают, но крупные передачи зависают, одно направление отказывает либо симптом проявляется только в IPv4 или IPv6. До изменения MTU докажите повторяемую зависимость от размера. Затем временно уменьшайте MTU туннеля контролируемыми шагами, повторяя тот же поток, и восстановите исходное значение, если граница отказа не сдвинулась.

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

Ключевые выводы

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

Перед каждым экспериментом записывайте исходные MTU интерфейсов и действующие маршруты.

Проверяйте IPv4 и IPv6 независимо: механизмы PMTU и минимальные требования различаются.［2］［3］

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

Не отключайте ICMP и не назначайте одно «магическое» MTU любому пути.

Что MTU меняет на пути WireGuard?

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

wg-quick умеет вычислять MTU интерфейса по маршруту к конечной точке (Endpoint) или системному значению и позволяет задать MTU явно.［1］ Но этот механизм не знает всех последующих звеньев. Другой туннель, мобильный оператор, виртуальная сеть, PPP, облачная оверлейная сеть или неожиданно маленький промежуточный канал способны снизить Path MTU.

IPv4 Path MTU Discovery полагается на сообщение маршрутизатора о том, что неподлежащее фрагментации сообщение слишком велико. RFC 1191 описывает ICMP-ответ и адаптацию отправителя.［2］ Маршрутизаторы IPv6 не фрагментируют пакеты в пути; RFC 8201 определяет Packet Too Big и минимальный MTU канала IPv6 в 1280 октетов с правилами для меньшего пути.［3］ Потеря или фильтрация этой обратной связи создаёт «чёрную дыру» (black hole): маленькие пакеты проходят, крупные повторно исчезают.

Какие симптомы указывают на проблемы MTU в WireGuard?

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

Симптом	Сила сигнала MTU	Что ещё исключить
Малый запрос и ответ работают, большой ответ стабильно зависает	Высокая	Ограничение сервиса, обработка запросов диапазонов, перегрузка
Один размер работает, немного больший повторно теряется	Высокая	Ограничение скорости, порог межсетевого экрана с отслеживанием состояния
IPv4 работает, крупный IPv6-трафик нет	Средняя или высокая	Маршрут IPv6, DNS, межсетевой экран для IPv6
Крупные данные не идут в одном направлении	Средняя или высокая	Асимметрия маршрута, правила получателя
Не работает даже маленькая проба по IP	Низкая	Маршрут, пир, ключ, адрес сервера (Endpoint), пересылка
Пропускная способность просто ниже ожидаемой	Низкая	Перегрузка, процессор, радиоканал, ограничение полосы, сервер
Не открывается один сайт, но контролируемая передача того же размера работает	Низкая	TLS, HTTP, CDN, политика приложения

Если маленькая проба не меняет TX и RX WireGuard, вернитесь к матрице счётчиков после рукопожатия. MTU не исправит поток, который не выбрал пир.

Семь безопасных проверок MTU

Шаг 1. Зафиксируйте исходное состояние

Запишите MTU интерфейса WireGuard, физического или внешнего интерфейса, маршрут к конечной точке пира, семейства адресов и наличие другого туннеля. Подтвердите актуальное рукопожатие и свежие TX/RX для маленькой двусторонней пробы. Затем опишите направление неудачной операции, примерный размер полезной нагрузки, поведение тайм-аута и время.

Используйте контролируемый адрес, где вы вправе менять размер запроса или ответа. Обычная веб-страница — слабый ориентир: контент, CDN, записи TLS, сжатие и кэш могут измениться. Лучше разрешённая тестовая служба или системный инструмент, ясно сообщающий результат.

Запишите точное действие для восстановления MTU. Управляемый клиент может пересоздать интерфейс; заранее выясните, переживёт ли временная настройка повторное подключение.

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

Шаг 2. Постройте лестницу размеров

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

Размер полезной нагрузки в инструменте может не равняться размеру внутреннего IP-пакета, а тот отличается от внешнего шифрованного пакета. Заголовки IPv4 и IPv6 имеют разную длину, возможны дополнительные заголовки, а параметры утилит измеряют разные величины. Записывайте инструмент и единицы и не называйте размер полезной нагрузки универсальным MTU WireGuard.

При проверке через ping используйте документированный параметр платформы, если нужно запретить фрагментацию IPv4 или запросить аналогичное поведение PMTU. Отсутствие echo-ответа не является самостоятельным доказательством, поэтому подтвердите результат контролируемым TCP- или UDP-потоком. Не создавайте поток запросов (flood) и не тестируйте чужую систему без разрешения.

Шаг 3. Временно уменьшите MTU только туннеля

Выберите консервативный шаг ниже записанного MTU и примените его только к интерфейсу WireGuard поддерживаемым временным способом. Повторите ту же лестницу и действие приложения. Не изменяйте одновременно DNS, маршрут, межсетевой экран и MTU.

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

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

Шаг 4. Сравните IPv4 и IPv6 отдельно

Повторите малые и крупные тесты для явных адресов IPv4 и IPv6. Запишите маршрут, исходный адрес, MTU интерфейса, приращения счётчиков и результат. Не позволяйте имени незаметно переключить семейство между попытками.

Для IPv4 исследуйте, получает ли отправитель требуемое сообщение ICMP «fragmentation needed» и не изменяет ли устройство пакет. RFC 1191 предупреждает о проблемах старого и неверного поведения.［2］ Для IPv6 проверяйте Packet Too Big и не опускайте дизайн ниже архитектурных требований без понимания фрагментации источником.［3］

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

Шаг 5. Проверьте оба направления и потерю обратной связи

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

Если вы администрируете путь, используйте узкие счётчики интерфейсов и межсетевого экрана: генерируются ли сообщения Packet Too Big или fragmentation needed и пропускаются ли они. Разрешайте нужные служебные сообщения по документированной политике, а не отключайте защиту. ICMP переносит необходимую сетевую обратную связь; глобальная блокировка не является надёжным усилением безопасности.

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

Шаг 6. Решите, оправдана ли постоянная настройка

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

Когда сеть ваша, предпочтительнее исправить потерю обратной связи PMTU или неверный внешний линк. Уменьшение MTU иногда остаётся практичной клиентской мерой, но его следует документировать с затронутыми путями и пересматривать после изменения топологии. Возможность явно переопределить MTU в wg-quick не превращает догадку в доказательство.［1］

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

Шаг 7. Выполните откат и сохраните краткий протокол

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

Сохраните только исходное и тестовое MTU, внешний путь, семейство адресов, смысл payload в инструменте, порог успеха и отказа, направление, новые TX/RX и наличие ICMP feedback. Не храните захват постороннего трафика, сведения учётной записи и историю адресов.

Передайте проблему выше, если управляемый клиент перезаписывает значение, обратную связь может починить только оператор или поддерживаемого элемента управления нет. Такая таблица полезнее совета «попробуйте 1280» без контекста.

Как повторить тест размера через управляемое VPN-приложение?

Тест «малая передача против большой» можно повторить через управляемый туннель в качестве контрольного. Подключите AethoVPN на том же устройстве и в той же сети, откройте небольшую страницу, затем начните крупное скачивание или загрузку и отметьте, не зависает ли она. Если обе передачи там завершаются, а ваш собственный пир WireGuard зависает только на крупных, путь доступа способен переносить туннелированный трафик полного размера, и главным подозреваемым становится MTU вашего интерфейса. Приложение не документирует ручное поле MTU, поэтому любые изменения MTU остаются на вашем самостоятельно управляемом пире, а в поддержку следует передавать только очищенные симптомы. Начните 3-дневный бесплатный пробный период для контрольного теста.

Итоги

Требуйте устойчивого различия малых и крупных передач до диагноза MTU.
Фиксируйте исходное состояние и меняйте только один адрес, направление и семейство за раз.
Уменьшайте только MTU туннеля и временно; сдвиг границы — доказательство, не универсальный ответ.
Сохраняйте обратную связь ICMP и ищите первую точку исчезновения крупного пакета или ошибки.
Проверяйте оба направления и все поддерживаемые семейства до постоянной правки.
Отменяйте неэффективные эксперименты и храните краткую очищенную запись.

Часто задаваемые вопросы (FAQ)

Какое MTU следует использовать для WireGuard?

Универсального значения нет. Внутренний размер зависит от семейства внешнего адреса, пути и дополнительной инкапсуляции. Измеряйте свой путь и используйте поддерживаемые средства.

Почему рукопожатие работает, а загрузка зависает?

Сообщения рукопожатия невелики. Они могут пересечь путь, который теряет крупные транспортные пакеты или нужную отправителю обратную связь ICMP.

Всегда ли 1280 — лучший MTU WireGuard?

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

Нужно ли блокировать ICMP ради безопасности?

Не блокируйте его полностью. IPv4 и IPv6 используют ICMP для важных ошибок и PMTU. Применяйте узкую документированную политику межсетевого экрана.

Может ли MTU влиять только на отдачу или только на загрузку?

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

Указывает ли успешное снижение MTU на неисправный маршрутизатор?

Нет. Оно поддерживает проблему размера где-то на пути. Для локализации звена требуются наблюдения по пути или помощь оператора.

Требуется ли перезапуск WireGuard после изменения MTU?

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

Отказ от ответственности: это руководство содержит общую техническую информацию. Меняйте только разрешённые системы, сохраняйте необходимый ICMP и отменяйте временные настройки после теста.

Источники:

WireGuard Tools, "wg-quick(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg-quick.8
IETF, "RFC 1191: Path MTU Discovery": https://www.rfc-editor.org/info/rfc1191/
IETF, "RFC 8201: Path MTU Discovery for IP version 6": https://www.rfc-editor.org/info/rfc8201/

Sources checked 12 сентября 2026 г.

Рекомендуемые статьи:

Проблемы MTU в WireGuard: признаки и безопасные тесты