WireGuard сбоит после простоя: сначала проверьте направление

Любому изменению настроек предшествуют четыре вопроса: работает ли тот же ресурс, пока клиент активен, сколько длился период простоя, спало ли устройство или сменило сеть, и появляется ли сбой только в трафике, который начинает противоположная сторона. Ответы отделяют истёкшее сопоставление NAT от спящего радио и от устаревшего приложения. Они также говорят, уместен ли keepalive вообще. Начните с направления: оно стоит одной команды и исключает половину возможных причин.

Какое направление сбоит?

Новый исходящий запрос клиента и трафик, приходящий к нему после тихого периода, по-разному нагружают оборудование с состоянием. Исходящие пакеты перестраивают сопоставление при выходе, а входящим пакетам нужно, чтобы старое сопоставление выжило. Эта асимметрия и есть весь тест. Если клиент может выйти, но внутрь ничего не приходит, сопоставление, вероятно, истекло, а если не работает ни то ни другое, туннель или сетевой доступ клиента пропал.

Отметьте, сколько длился тихий период и спало ли устройство или перешло за это время в другую сеть. Эти два факта меняют диагноз раньше любой настройки.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Выполните эти три команды до и после тихого периода, потому что каждая отвечает на свою часть вопроса. Не сдвинувшаяся метка времени handshake говорит, что стороны перестали разговаривать, а изменившийся конечный узел говорит, что сопоставление сместилось, а не умерло. Счётчики передачи показывают, пришло ли хоть что-нибудь, и в этом разница между устаревшим сопоставлением и молчащим приложением. Запишите числа в обеих точках, потому что сравнение и есть доказательство.

Сон, радио и состояние приложения

На телефоне или ноутбуке спящее устройство могло полностью потерять сетевой доступ, а keepalive не может восстановить выключенное радио или завершить неудовлетворённый captive portal. Мобильные платформы приостанавливают фоновую работу по политике, поэтому продолжится ли периодический трафик, зависит от платформы и от того, о чём приложение с ней договорилось. Кэшированное соединение — третий случай и самый обманчивый, потому что возвращение туннеля не то же самое, что повторное подключение приложения к нему.

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

Что на самом деле делает keepalive

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

Большинство периодов простоя — не сбои. Туннель, который переподключается после пяти минут тишины, ведёт себя правильно, и проблема только в случае, когда что-то должно было прийти с противоположной стороны.

Выждите интервал, который раньше сбоил

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

Держите одно изменение на тест и записывайте использованную длительность простоя. Без этого каждое последующее сравнение уплывает, и никто не может сказать, какое изменение имело значение. Запишите четыре факта вместе: направление, длительность, состояние сна и поведение приложения.