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

Почти всегда это MTU.

Что такое MTU и почему он ломается именно в туннеле

MTU — максимальный размер пакета, который сеть согласна передать целиком. В обычном Ethernet это 1500 байт.

Туннель добавляет к каждому пакету собственные заголовки. У WireGuard поверх IPv4 накладные расходы составляют 60 байт: 20 на внешний IP-заголовок, 8 на UDP и 32 на служебные данные самого протокола. Значит, полезной нагрузки внутри туннеля остаётся 1440 байт, и обычно ставят 1420 — с небольшим запасом.

Если внутри туннеля оставить 1500, каждый крупный пакет после упаковки превысит предел канала. Дальше возможны два исхода, и оба плохие.

Почему это «чёрная дыра», а не ошибка

В теории существует механизм обнаружения MTU по пути: узел, которому пакет великоват, отправляет отправителю служебное сообщение ICMP «нужна фрагментация», и тот уменьшает размер.

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

Получается характерная картина:

  • короткие запросы проходят — они помещаются в лимит;
  • рукопожатие TLS проходит — оно тоже небольшое;
  • а первый крупный ответ исчезает, и соединение висит до тайм-аута.

Отсюда и ощущение, что «интернет работает, но сайт не открывается».

Как подобрать значение за пять минут

Способ первый, точный. Отправляем пакеты фиксированного размера с запретом фрагментации и ищем предел:

# Linux и macOS
ping -M do -s 1372 -c 3 1.1.1.1

# Windows
ping -f -l 1372 1.1.1.1

Размер в команде указывается без 28 байт заголовков, поэтому к найденному значению их нужно прибавить: прошло -s 1372 — значит, путь держит 1400. Уменьшайте число, пока ответы не пойдут, и прибавьте 28.

Способ второй, быстрый. Поставить 1280 и не искать. Это минимальный MTU, обязательный для IPv6, и его пропускает любой маршрут в интернете. Потеря пропускной способности от такого запаса — несколько процентов, зато зависших запросов не остаётся.

Куда вписывать

В WireGuard — в секцию интерфейса:

[Interface]
PrivateKey = ...
Address = 10.0.0.2/32
MTU = 1280

В OpenVPN размер задаётся директивой tun-mtu, а при работе поверх UDP помогает ещё и mssfix, который подрезает размер сегментов TCP на входе в туннель. Это лечит основную часть симптомов даже там, где MTU подобран неидеально.

Когда запас нужен больше обычного

PPPoE у провайдера. Такое подключение само по себе съедает 8 байт, и канал начинается не с 1500, а с 1492. Все расчёты сдвигаются вниз.

IPv6 снаружи. Внешний заголовок IPv6 занимает 40 байт против 20 у IPv4 — накладные расходы туннеля вырастают на те же 20.

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

Двойной туннель. Если трафик идёт через два туннеля подряд, заголовки складываются.

Как отличить MTU от других причин

Признак MTU Другое
Мелкие запросы проходят, крупные виснут да нет
Рукопожатие есть, счётчики растут да при обрыве — нет
Проблема на конкретных сайтах, не на всех да при проблемах с DNS — на всех
Помогает уменьшение MTU да —

Если же не работает вообще ничего, дело не в размере пакета — смотрите маршрутизацию и DNS. Если ответ обрывается на середине после долгой паузы — это скорее тайм-аут NAT в длинном соединении.

Чем платим за низкий MTU

Меньше полезных данных в пакете — больше пакетов на тот же объём, а значит, чуть выше накладные расходы и нагрузка на процессор. Разница между 1420 и 1280 в реальных измерениях — единицы процентов пропускной способности, и на скорость она влияет куда слабее, чем расстояние до сервера.

Поэтому выбор простой: гоняться за последними процентами имеет смысл на стабильном канале, а если что-то не открывается — ставьте 1280 и возвращайтесь к тонкой настройке позже.

Коротко

MTU ломается тихо: ошибок нет, скорость нормальная, а часть запросов пропадает. Причина в том, что туннель добавляет заголовки, а служебные ICMP-сообщения о превышении размера по дороге теряются. Лечится одной строкой в конфигурации. Значение 1280 работает всегда, 1420 — оптимально для большинства каналов, а точное подбирается командой ping за пять минут.