MTU и MSS в WireGuard: почему ping работает, а файлы зависают
Проверяем размер пакета по пути и ограничиваем MSS-правила нужным VPN-трафиком. Без универсального MTU и изменений всей сети наугад.
- Размер по путиПроверяем DF и учитываем заголовки
- Область MSS-правилаТолько нужный TCP-трафик через VPN
- Новая сессияПовторяем передачу и проверяем остальную сеть
Небольшой ping проходит, страница начинает открываться, а копирование файла останавливается. Такой набор симптомов даёт повод проверить размер пакетов, но ещё не доказывает проблему MTU. Сначала исключите потерю связи, неверный маршрут и ограничение скорости. Счётчик RX errors сам по себе тоже не объясняет причину: важны его прирост и воспроизводимая проверка.
Размер интерфейса и размер по пути
MTU задаёт предел IP-пакета на интерфейсе. Внешний канал должен вместить ещё и оболочку VPN; дополнительная инкапсуляция на маршруте уменьшает доступный запас. Поэтому одинаковое значение на двух WireGuard-интерфейсах полезно для понятной конфигурации, но не гарантирует прохождение пакета через весь путь.
Проверяйте адрес в удалённой LAN и повторяйте тест в обратную сторону. В RouterOS параметр size включает IP-заголовок. В обычном IPv4 ping Linux параметр -s задаёт только данные ICMP: для сопоставления к нему прибавляют 28 байт. Это различие легко превращает сравнение двух команд в ложный вывод.
# Учебный адрес, не адрес рабочего сервера
# RouterOS: полный IPv4-пакет размером 1400 байт
/ping 10.60.20.50 size=1400 do-not-fragment count=5
# Linux: 1372 байта данных + 28 байт заголовков
ping -M do -s 1372 -c 5 10.60.20.50Подбирайте размер несколькими измерениями, а не одним пакетом. Тайм-аут неоднозначен: узел может запрещать ICMP, а сеть — терять пакеты и по другой причине. Сопоставьте обычный ping, тест с DF и сообщения о невозможности фрагментации. Разрешённая доставка необходимых ICMP-ошибок помогает механизму определения MTU работать правильно.
MSS относится к TCP, а не ко всему VPN
MSS ограничивает объём данных TCP-сегмента и согласуется при установлении соединения. Правило change-mss действует на подходящие TCP SYN-пакеты; оно не чинит UDP и не превращает плохой маршрут в хороший. Clamp-to-pmtu опирается на представление маршрутизатора о допустимом размере, поэтому при сломанном обнаружении MTU одного этого режима может оказаться недостаточно.
Сначала опишите область действия: входящий или исходящий WireGuard-интерфейс, сети офисов и TCP. Правило только с chain=forward и tcp-flags=syn затронет также обычный транзит LAN–WAN. Изменения для обратного направления проверяют отдельно. Ниже — пример фильтров для просмотра существующих правил, без их автоматического добавления:
/ip/firewall/mangle/print detail where action=change-mss
/ip/firewall/mangle/print stats where action=change-mssПодтверждаем эффект на новой сессии
После согласованной правки установите новое TCP-соединение и повторите ту же передачу. Уже открытая сессия не согласует MSS заново. Затем проверьте обычный интернет и другой офисный трафик: исправление должно помогать выбранному пути, а не менять поведение всей сети. Сохраните измеренный предел и условия теста — они полезнее универсального совета «поставьте 1380».