WireGuard zawodzi po bezczynności: najpierw sprawdź kierunek

Przed każdą zmianą ustawienia stoją cztery pytania: czy ten sam zasób działa, gdy klient jest aktywny, jak długo trwał okres bezczynności, czy urządzenie spało lub zmieniło sieć, i czy błąd pojawia się tylko w ruchu inicjowanym przez drugą stronę. Odpowiedzi oddzielają wygasłe mapowanie NAT od uśpionego radia i od nieaktualnej aplikacji. Mówią też, czy keepalive ma w ogóle znaczenie. Zacznij od kierunku, bo kosztuje jedną komendę i eliminuje połowę możliwych przyczyn.

Który kierunek zawodzi?

Nowe żądanie wychodzące klienta i ruch, który po cichym okresie przychodzi w jego stronę, obciążają urządzenia stanowe inaczej. Pakiety wychodzące odbudowują mapowanie przy wyjściu, a pakiety przychodzące potrzebują, aby stare mapowanie przetrwało. Ta asymetria to cały test. Jeśli klient może wyjść, ale nic nie wchodzi, mapowanie prawdopodobnie wygasło, a jeśli żadne nie działa, tunel lub dostęp sieciowy klienta zniknął.

Zanotuj, jak długo trwał cichy okres i czy urządzenie spało lub przeszło w międzyczasie do innej sieci. Te dwa fakty zmieniają diagnozę zanim zrobi to jakiekolwiek ustawienie.

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

Uruchom te trzy przed cichym okresem i po nim, bo każda odpowiada na inną część pytania. Nieprzesunięty znacznik czasu handshake mówi, że strony przestały rozmawiać, a zmieniony punkt końcowy mówi, że mapowanie przesunęło się, a nie zginęło. Liczniki transmisji pokazują, czy w ogóle coś dotarło, i to jest różnica między wygasłym mapowaniem a cichą aplikacją. Zapisz liczby w obu punktach, bo porównanie jest dowodem.

Sen, radio i stan aplikacji

W telefonie lub laptopie uśpione urządzenie mogło całkowicie utracić dostęp do sieci, a keepalive nie przywróci wyłączonego radia ani nie ukończy niezaspokojonego captive portalu. Platformy mobilne zawieszają pracę w tle zgodnie z polityką, więc to, czy ruch okresowy trwa, zależy od platformy i od tego, co aplikacja z nią uzgodniła. Połączenie w pamięci podręcznej to trzeci przypadek i najbardziej mylący, bo powrót tunelu to nie to samo co ponowne połączenie aplikacji z nim.

Po okresie bezczynności otwórz aplikację ponownie, zamiast ufać karcie, która pozostała otwarta. Jeśli nowe żądanie powiedzie się tam, gdzie stara sesja zawiodła, tunel nigdy nie był problemem.

Co keepalive rzeczywiście robi

PersistentKeepalive okresowo wysyła uwierzytelniony pusty pakiet do peera, co wystarcza, by utrzymać mapowanie NAT między peerami i aktualny punkt końcowy drugiej strony, jak opisuje szybki start WireGuard. Nie naprawia uśpionego radia, utraconej trasy ani aplikacji, która nigdy nie ponawia próby. Wybierz interwał w obsługiwanych ustawieniach klienta i nie włączaj agresywnej wartości wszędzie tylko dlatego, że wyświetlacz stanu milknie.

Większość okresów bezczynności nie jest awariami. Tunel, który po pięciu minutach ciszy łączy się ponownie, zachowuje się poprawnie, a problemem jest tylko przypadek, w którym coś miało dotrzeć z drugiej strony.

Odczekaj interwał, który wcześniej zawodził

Wprowadź jedną obsługiwaną zmianę, a potem pozwól upłynąć temu samemu okresowi bezczynności, zanim ponownie przetestujesz ten zasób. Czekanie jest częścią testu, a nie formalnością. Natychmiastowy sukces po ponownym połączeniu nic nie mówi o objawie długiej bezczynności, bo ponowne połączenie jest właśnie zdarzeniem, które resetuje stan. Jeśli problem pojawia się także podczas aktywnego użytkowania, wróć do kontroli handshake i ścieżki danych, zamiast dodawać więcej ruchu okresowego.

Trzymaj jedną zmianę na test i zapisz użyty czas bezczynności. Bez tego każde późniejsze porównanie dryfuje i nikt nie powie, która zmiana miała znaczenie. Zapisz cztery fakty razem: kierunek, czas, stan snu i zachowanie aplikacji.