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 и пътя на данните, вместо да добавяте още периодичен трафик.

Пазете една промяна на тест и записвайте използваната продължителност на простой. Без това всяко следващо сравнение се разминава и никой не може да каже коя промяна е имала значение. Запишете четирите факта заедно: посока, продължителност, състояние на сън и поведение на приложението.