При некорректном MTU туннель WireGuard может оставаться активным, ICMP и SSH работают, но HTTPS-запросы зависают, а передача больших файлов прерывается. Одна из возможных причин — нарушение Path MTU Discovery (PMTUD), препятствующее определению допустимого размера пакетов на маршруте.
WireGuard инкапсулирует IP-пакеты в UDP. Накладные расходы составляют 60 байт поверх IPv4 и 80 байт поверх IPv6 без дополнительной инкапсуляции. При внешнем Path MTU 1500 максимальный MTU туннеля без фрагментации составляет соответственно 1440 и 1420 байт.
Проверим текущий MTU интерфейса WireGuard.
ip link show dev wg0
В типичной конфигурации
wg-quick можно увидеть MTU 1420, однако фактическое значение зависит от маршрутизации и настроек интерфейса.wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420
Проверим прохождение внутренних IPv4-пакетов с установленным флагом DF. Размер ICMP-данных 1392 байта вместе с IPv4- и ICMP-заголовками формирует пакет размером 1420 байт.
ping -4 -M do -s 1392 -c 4 10.20.0.1
Здесь
10.20.0.1 — пример адреса удалённого WireGuard-пира. Успешный ping до него не гарантирует отсутствие ограничений MTU на дальнейшем маршруте.Если пакеты не проходят, повторим проверку с размером 1340 байт. Ошибка
message too long указывает на превышение MTU, известного локальному сетевому стеку, а отсутствие ответа может быть связано с фильтрацией ICMP:ping -4 -M do -s 1312 -c 4 10.20.0.1
Если HTTPS-сервис находится за удалённым пиром, дополнительно проверим маршрут до его IPv4-адреса и прохождение пакетов, если сервис отвечает на ICMP.
ip -4 route get 10.20.0.10
ping -4 -M do -s 1392 -c 4 10.20.0.10
Здесь
10.20.0.10 — пример адреса целевого сервиса. Маршрут должен проходить через wg0.Если диагностика указывает на ограничение MTU, временно установим 1380 байт. Это тестовое значение, которое может потребовать дополнительного уменьшения при PPPoE или вложенных туннелях.
sudo ip link set dev wg0 mtu 1380
Повторим проверку с ICMP-данными размером 1352 байта, что соответствует внутреннему IPv4-пакету размером 1380 байт.
ping -4 -M do -s 1352 -c 4 10.20.0.1
При необходимости проверим конечный адрес сервиса. Изменение MTU только на одной стороне туннеля не гарантирует устранения проблем в обратном направлении.
После изменения MTU проверим прикладной трафик через VPN. Используем доступный через туннель HTTPS-сервис.
curl -4 -v --connect-timeout 5 --max-time 30 https://INTERNAL_HOST/
Заменим
INTERNAL_HOST на реальное имя сервиса и убедимся, что его IPv4-адрес маршрутизируется через VPN.Если изменение устранило проблему, закрепим значение в существующей конфигурации
/etc/wireguard/wg0.conf. Параметр MTU обрабатывается утилитой wg-quick, а не протоколом WireGuard.[Interface]
Address = 10.20.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
MTU = 1380
Это пример секции
[Interface]. Сохраним существующие ключи, адреса и остальные параметры конфигурации.Значение MTU уже применено командой
ip link set, поэтому перезапуск сейчас не требуется. Для проверки сохранённой конфигурации после повторного поднятия интерфейса можно выполнить:sudo wg-quick down wg0 && sudo wg-quick up wg0
При удалённом подключении через туннель команда может привести к потере доступа. Успешный ICMP-тест не гарантирует корректную работу TCP. При сохранении проблемы проверьте MTU на обеих сторонах туннеля, PMTUD и маршрутизацию.
🔥 Активный WireGuard-туннель не гарантирует передачу крупных пакетов. Проверка DF-пакетов и снижение MTU помогают выявить проблему.
🚪 Linux Ready | #практика