WireGuard зависает: предел MTU или отсутствующее правило пересылки?
Всё за сервером — это проблема пересылки или обратного маршрута. Малые запросы проходят, а большие зависают — это признак размера пакета.
Привычка снижать MTU, как только WireGuard начинает вести себя неправильно, скрывает другую неисправность. Шлюз, который не пересылает, и путь, который не несёт большие пакеты, дают различимые картины: один отказывает в обе стороны и при любом размере, другой переживает малые запросы и умирает на больших. Определите, какая форма у вас, прежде чем менять любое число. Тест дешёвый, и он убирает половину возможных причин.
Две неисправности, две разные формы
Проблема пересылки проявляется сразу за сервером. Рукопожатие проходит, адрес туннеля отвечает, и ничего за шлюзом недоступно даже малым запросом. Пакет дошёл до сервера и не был передан, или у ответа не было обратного маршрута.
Проблема размера проявляется только выше порога. DNS, рукопожатие TCP и небольшой вызов API работают, а загрузка файла или большой ответ зависают. Пакеты, которые помещались, прошли от края до края, а те, что не помещались, были отброшены где-то без полезного отчёта.
Эти описания указывают на разных людей и разные файлы конфигурации, поэтому измерение формы ценнее догадки. Один ping до шлюза не может их разделить.
Исключите пересылку, прежде чем что-то уменьшать
Проверяйте назначение за шлюзом, а не сам шлюз. Ping до адреса туннеля сервера доказывает только то, что интерфейс поднят и вы достигаете машины, завершающей туннель. Трафик для более широкой сети зависит от включённой пересылки IP на этой машине и от брандмауэра, разрешающего пересылаемый поток. Истинно должно быть и то и другое, и если одно неверно, получается та же тишина.
Обратная маршрутизация не менее важна. Если сеть назначения не знает, как достичь адреса туннеля клиента, запрос приходит, а ответ исчезает, и клиент сообщает о тайм-ауте, который выглядит так же, как отброшенная пересылка.
Там, где проект использует трансляцию адресов, правило трансляции является частью этого обратного пути. Удаление его во время поиска проблемы с MTU превращает работающий проект в сломанный, поэтому прочитайте существующие правила, прежде чем их править.
Измерьте, где начинается разрыв
Сначала прочитайте состояние пересылки и правила фильтрации. Это проверки только для чтения, и они отвечают на дешёвый вопрос:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Затем проверьте размеры с битом «не фрагментировать», от клиента, в сторону узла за шлюзом:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Если первая проверка проходит, а вторая завершается ошибкой фрагментации, путь сообщает вам свой пригодный размер. Если не проходит ни одна, вы смотрите на пересылку или маршрутизацию, и MTU не является переменной, которую нужно менять.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
Исправьте тот уровень, который вы доказали
Когда виновата пересылка, исправление — это правило пересылки или маршрут, выраженные как можно уже, насколько позволяет проект. Когда виноват размер, исправление — это MTU, учитывающий инкапсуляцию именно на этом пути, применённый к интерфейсу, которому он нужен, а не к каждому адаптеру в парке.
Так или иначе, после этого повторите ту же задачу к тому же назначению. Если исходная большая передача теперь завершается, изменение затронуло тот уровень, который отказывал. Если улучшилась только малая проверка, вы лечили симптом, и реальный предел всё ещё на месте.
Запишите, какую форму вы наблюдали до изменения. Эта одна строка, записанная рядом с исправлением, — то, что не даёт следующему человеку снизить MTU, который никогда не был проблемой.