Zawieszony VPN po restarcie routera: trzy rzeczy, które się zmieniły

Router kończy uruchamianie, laptop ponownie dołącza do tego samego SSID, a VPN stoi na połączono, podczas gdy nic się nie rusza. Zapisany profil jest nienaruszony. To, co wygasło pod nim, to ścieżka, a klient nadal trzyma stan, który zbudował dla starej.

Trzy warunki decydują o poprawce. Sprawdzaj je po kolei, bo późniejsze to zmarnowany wysiłek, jeśli pierwszy już wyjaśnia zatrzymanie.

Warunek pierwszy: adres lokalny się zmienił

Restart może nadać maszynie inny adres. Wtedy VPN skonfigurowany ze stałym lokalnym punktem końcowym dalej używa połączenia, którego już nie ma. To samo dotyczy klienta, który związał swój socket ze starym adresem. Interfejs tunelu może pozostać w górze, podczas gdy każdy generowany przez niego pakiet idzie donikąd.

Porównaj adres używany przez klienta z adresem, który interfejs ma teraz. Trasa domyślna wskazująca na bramę, która także się zmieniła, to ten sam rodzaj problemu pod inną nazwą.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Warunek drugi: przetłumaczone mapowanie zniknęło

Routery domowe tłumaczą strumienie wychodzące, a te mapowania żyją w pamięci. Restart usuwa każde z nich. To jest nieszkodliwe dla nowego połączenia i zgubne dla tunelu, który wierzy, że jego istniejący strumień jest nadal ważny. Wtedy druga strona nic nie widzi, więc klient nigdy nie dostaje błędu, na który mógłby zareagować.

Tu właśnie tunel bez keepalive zatrzymuje się cicho zamiast zawieść głośno. Udokumentowane ograniczenia WireGuard opisują ten sam kształt awarii. Błędny stan punktu końcowego daje odrzucone pakiety zamiast diagnozy.

Stały keepalive 25 sekund to zwykłe złagodzenie, bo odświeża mapowanie, zanim może upłynąć limit bezczynności. Nie naprawia mapowania, które już zniknęło. Połącz keepalive z logiką ponownego łączenia, zamiast traktować go jako poprawkę.

Warunek trzeci: adres publiczny się zmienił

Jeśli zmienił się własny adres zewnętrzny routera, wszystko po drugiej stronie filtrujące po adresie źródłowym widzi teraz innego partnera. Tunel może się podnieść, a serwer nadal może odrzucać ruch; wygląda to na zepsutego klienta, a w rzeczywistości jest polityką na drugim końcu.

Zapisz adres zewnętrzny przed restartem i po nim. Gdy oba się różnią, pytanie przechodzi od klienta do tego, kto utrzymuje listę dozwolonych, a reset danych logowania na laptopie nie może pomóc.

Odzyskuj w odpowiedniej kolejności

Najpierw dokończ wymagane logowanie w portalu przechwytującym, potem pozwól klientowi połączyć się ponownie jego obsługiwaną procedurą, zamiast zabijać proces. Obserwuj, czy wracają zarówno tożsamość, jak i ruch danych, bo to dwa różne etapy tego samego połączenia.

Strona z pamięci podręcznej niczego nie dowodzi, podobnie jak aplikacja czatu, która połączyła się sama. Przetestuj punkt końcowy, na którym naprawdę ci zależy, nowym żądaniem. Utrzymuj politykę ruchu bezpośredniego podczas przerwy, bo próba ponownego połączenia nie jest blokadą.

Gdy to powtarza się po każdym restarcie, zapis znaczy więcej niż ponowna próba. Zapisz adres lokalny, bramę, adres zewnętrzny i stan klienta przed i po, a potem porównaj obie kolumny. To zamienia mgliste zgłoszenie w błąd cyklu życia, który ktoś może naprawić, i zatrzymuje trzecią wymianę certyfikatów z powodu limitu czasu mapowania.