MTU для WireGuard: как настроить правильно

MAATRIX

Сайты грузятся через раз, SSH-сессия зависает на объёмном выводе, а ping внутри туннеля при этом летает — классическая картина неправильного MTU в WireGuard. Значение 1420 по умолчанию рассчитано на «чистый» Ethernet-канал и ломается, как только на пути появляется PPPoE или ещё один слой туннелирования. Разберёмся, откуда берётся это число, когда его надо снижать и как подобрать точное значение без гадания.

Откуда взялось значение 1420

Стандартный Ethernet-канал несёт кадры с полезной нагрузкой до 1500 байт — это MTU (Maximum Transmission Unit), максимальный размер IP-пакета, который проходит без фрагментации. WireGuard оборачивает каждый ваш пакет в собственный заголовок и шифрует его, поэтому «внутри» туннеля доступно меньше места, чем снаружи.

Overhead WireGuard складывается из:

• внешнего IP-заголовка — 20 байт для IPv4 или 40 байт для IPv6;
• UDP-заголовка — 8 байт;
• служебного заголовка самого WireGuard (тип пакета, счётчик, тег аутентификации Poly1305) — 32 байта.

Итого для IPv4-транспорта это 60 байт, для IPv6 — 80 байт. Если взять худший случай (IPv6-транспорт) и вычесть из 1500, получится ровно 1420 — это значение wg-quick и большинство клиентов подставляют по умолчанию, чтобы туннель работал одинаково независимо от того, IPv4 или IPv6 используется снаружи. Формально для чистого IPv4-транспорта можно было бы уместить 1440 байт, но 1420 — более безопасный запас, который на прямом Ethernet-канале почти всегда работает без проблем.

Проблема в том, что 1420 — это расчёт «от идеального канала». Как только на пути появляется дополнительная инкапсуляция — PPPoE, второй VPN, GRE-туннель между дата-центрами — свободного места оказывается меньше 1420 байт, и часть пакетов начинает либо фрагментироваться (с потерей производительности), либо биться в блэкхол, если фрагментация запрещена флагом DF.

Как выглядит проблема на практике

Неправильный MTU редко обрывает соединение полностью — он ломает выборочно, и это сбивает с толку при диагностике:

• ping внутри туннеля работает — ICMP-пакеты маленькие, они укладываются в любой MTU;
• SSH подключается, но зависает на ls -la большой директории, cat длинного файла или при выводе через less — как только сервер пытается отправить пакет крупнее реального MTU канала;
• HTTPS-сайты не открываются или открываются частично — TLS handshake (маленькие пакеты) проходит, но тело страницы (крупные пакеты) обрывается;
• VoIP и видеозвонки работают нестабильно — UDP-трафик с крупными пакетами теряется без ретрансмита;
• скачивание файлов медленно ползёт или замирает — TCP упирается в чёрную дыру PMTU (Path MTU Discovery Black Hole), когда роутер на пути должен ответить ICMP «Fragmentation Needed», но его блокирует фаервол.

Если видите именно такую комбинацию симптомов — сначала проверяйте MTU, а не переустанавливайте WireGuard заново. Разбор похожих симптомов без привязки к MTU есть в статье про WireGuard: нет интернета через VPN — причины и решение, а если рвётся сама сессия, а не отдельные пакеты — смотрите WireGuard обрывается соединение — причины и решение.

PPPoE: почему тут почти всегда нужно снижать MTU

PPPoE (PPP over Ethernet) — стандартная схема подключения у многих домашних и части офисных провайдеров, особенно там, где абонент авторизуется логином и паролем перед выходом в интернет. PPPoE добавляет собственный заголовок в 8 байт поверх Ethernet-кадра, из-за чего провайдерский MTU на таком канале обычно не 1500, а 1492 байта.

Если ваш роутер или сервер физически подключён через PPPoE, а WireGuard настроен с MTU 1420 (рассчитанным от 1500), туннель регулярно будет пытаться протолкнуть пакет крупнее реально доступного канала. Правильный расчёт для PPPoE-линии:

1492 (MTU канала PPPoE) − 80 (overhead WireGuard, IPv6-случай) = 1412

Если вы точно знаете, что транспорт всегда IPv4 (сервер и клиент оба ходят по IPv4-адресам), можно взять чуть больше — 1432, но 1412 безопаснее и почти не теряет в производительности на реальных нагрузках. На практике для PPPoE-подключений часто устанавливают ровно 1412 и не мучаются с более тонкой настройкой.

Отдельная ловушка: если PPPoE-сессию поднимает не сам сервер, а домашний роутер (Keenetic, MikroTik, OpenWrt), а WireGuard-клиент работает на устройстве за роутером, MTU нужно снижать именно на устройстве с WireGuard-клиентом или сервером — снижение MTU только на WAN-интерфейсе роутера туннель не спасёт, потому что WireGuard инкапсулирует пакеты уже после того, как они покинули приложение.

Двойное туннелирование: считаем overhead дважды

Если WireGuard идёт не напрямую в интернет, а через ещё один слой инкапсуляции — это уже двойное туннелирование, и overhead складывается. Типичные сценарии:

• WireGuard поверх WireGuard — например, сначала поднимается межсерверный туннель между двумя дата-центрами, а внутри него уже работает клиентский WireGuard;
• AmneziaWG или другой обфусцированный WireGuard поверх обычного канала — обфускация добавляет собственные байты сверх стандартного заголовка WireGuard, подробнее о разнице — в статье про AmneziaWG: обфусцированный WireGuard — установка;
• сайт-ту-сайт туннель между узлами провайдера (например, GRE или WireGuard-мост между локациями), внутри которого клиенты поднимают собственные VPN-сессии;
• WireGuard через корпоративный VPN или прокси, который сам по себе уже инкапсулирует трафик.

Расчёт всегда один и тот же принцип — от MTU внешнего, самого узкого канала последовательно вычитаете overhead каждого слоя инкапсуляции:

1500 (Ethernet)
 − 80  (внешний WireGuard-туннель между узлами)
 = 1420
 − 80  (внутренний WireGuard-туннель до клиента)
 = 1340

Если внешний туннель ещё и идёт поверх PPPoE, вычитаем и эти 8 байт — получится около 1332. Ориентировочные значения для типовых цепочек:

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

Как найти точный MTU практическим тестом

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

На Linux/macOS (тестируем внутри туннеля, пингуя IP peer'а из подсети WireGuard, например 10.0.0.1):

ping -M do -s 1400 10.0.0.1

Флаг -M do запрещает фрагментацию (аналог DF-бита), -s задаёт размер полезной нагрузки ICMP без учёта заголовков. Если пакет проходит — увеличивайте размер, если приходит Frag needed and DF set или пакет теряется — уменьшайте. Реальный MTU туннеля считается так:

MTU = успешный размер -s + 28 (20 байт IP-заголовок + 8 байт ICMP)

Для IPv6 добавляется 48 байт вместо 28. Двигайтесь бинарным поиском: пробуйте 1400, если проходит — 1450, если нет — 1375, и так далее, пока не найдёте точную границу.

На Windows аналогичный тест:

ping -f -l 1400 10.0.0.1

-f — запрет фрагментации, -l — размер данных. Сообщение «Требуется фрагментация пакета, но установлен запрещающий бит DF» означает, что размер надо уменьшить.

Если результат теста стабильно даёт число меньше расчётного (например, вы ожидали 1420, а реально проходит только 1370), значит на пути есть скрытая инкапсуляция или урезанный MTU у провайдера, о которой вы не знали — стоит уточнить у оператора канала или у хостера сервера.

Как задать MTU в конфигурации

Проще всего прописать MTU прямо в конфиге WireGuard — тогда значение подхватится при каждом поднятии интерфейса.

В файле wg0.conf для wg-quick:

[Interface]
PrivateKey = <ключ>
Address = 10.0.0.2/24
MTU = 1412
DNS = 1.1.1.1

[Peer]
PublicKey = <ключ_сервера>
Endpoint = 203.0.113.10:51820
AllowedIPs = 0.0.0.0/0

После изменения конфига перезапустите интерфейс:

wg-quick down wg0 && wg-quick up wg0

Если интерфейс поднят руками через ip, а не через wg-quick, MTU меняется отдельной командой:

sudo ip link set mtu 1412 dev wg0

На роутерах и NAS значение обычно выставляется в веб-интерфейсе:

• MikroTik — в свойствах WireGuard-интерфейса, поле MTU;
• Keenetic — в настройках WireGuard-подключения, «Дополнительные параметры»;
• pfSense / OPNsense — вкладка Interfaces у WireGuard-интерфейса, поле MTU;
• официальные клиенты WireGuard (Windows, macOS, iOS, Android) — добавьте строку MTU = ... прямо в конфиг перед импортом, отдельного поля в интерфейсе приложения обычно нет.

Дополнительно к снижению MTU для TCP-трафика полезно включить clamp MSS на сервере — это заставляет TCP-соединения заранее договариваться о меньшем размере сегмента, не дожидаясь чёрной дыры PMTU:

iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

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

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