VPN martwy po uśpieniu: utracony tunel czy przestarzała aplikacja?

Pokrywa się otwiera, ikona sieci bezprzewodowej wraca, a VPN nadal wyświetla się jako połączony. Pierwsza strona wewnętrzna wisi wtedy do przekroczenia limitu czasu, a nowa karta robi to samo. Trzy różne rzeczy mogą wywołać ten obraz i wymagają trzech różnych napraw: tunelu, który nie przetrwał uśpienia, profilu, którego nikt nie poprosił o ponowną aktywację, albo aplikacji, która wciąż trzyma sesję zmarłą kilka godzin temu. Porównanie ich jest szybsze niż ponowna instalacja czegokolwiek.

Po wybudzeniu mogą zepsuć się trzy rzeczy

Pierwszym kandydatem jest sam tunel. Interfejs może nadal istnieć z adresem, podczas gdy powiązanie z peorem zniknęło, dlatego lampka wskaźnika nie jest dowodem działającej ścieżki. Starszy niż uśpienie uścisk dłoni jest wskazówką, a do jego zobaczenia wystarczy jedno polecenie.

Drugim jest aktywacja. Wiele klientów łączy się ponownie samo; niektóre nie, a profil, którego nikt nie prosi o powrót, siedzi tam i wygląda na skonfigurowany. Ta awaria jest cicha z założenia, bo nic nie zgłosiło błędu.

Trzecim jest aplikacja. Karta przeglądarki, sesja SSH lub połączenie z bazą danych mogą przetrwać zmianę sieci jako deskryptor pliku, podczas gdy transport pod nimi jest martwy. Wtedy nowa sesja działa bezbłędnie, co mówi ci, że tunel był w porządku przez cały czas.

Porównaj wszystkie trzy, zanim cokolwiek zmienisz, bo naprawy się nie pokrywają. Restart klienta, którego nigdy nie poproszono o ponowne uruchomienie, marnuje dowód, którego potrzebowałeś. Zapisz, do którego kandydata pasuje objaw, zanim dotkniesz konfiguracji. To jedno zdanie zwykle rozstrzyga resztę dochodzenia.

Po pierwsze: czy tunel wrócił?

Patrz na interfejs i stan peera, a nie na tekst statusu klienta. Interfejs z adresem i bez świeżego uścisku dłoni to tunel, który istnieje tylko z nazwy.

ip -brief addr show
wg show
ip route show table all | head -20

Jeśli interfejsu w ogóle nie ma, tunel nie przetrwał i pojawia się pytanie, kto miał go przywrócić. Jeśli jest, ale uścisk dłoni jest stary, powiązanie z peorem trzeba odtworzyć, a klient może czekać na ruch, który je wywoła.

Sprawdź także trasy i konfigurację DNS. Tunel może wrócić bez swoich tras, co daje mylący stan, w którym interfejs działa, a nazwy wewnętrzne nadal rozwiązuje zły serwer.

Po drugie: czy coś poprosiło go o powrót?

Tu porównanie się opłaca. NetworkManager traktuje inaczej profil wtyczki OpenVPN i natywne połączenie WireGuard, a odnośnik do ustawień połączenia wyraźnie mówi, że connection.autoconnect nie aktywuje profili VPN; mechanizmem podniesienia VPN wraz z połączeniem jest connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Jeśli ręczne ponowne połączenie naprawia problem za każdym razem, to sygnatura brakującej aktywacji, a nie zepsutego tunelu. Dziennik zwykle pokaże, jak interfejs spada i nic go nie przywraca.

Oprzyj się pokusie natychmiastowego dodania hooka uśpienia. Hook, który uruchamia się, zanim sieć się pozbiera, ściga się z tym samym procesem, któremu próbuje pomóc, i zamienia powtarzalny problem w okresowy.

Po trzecie: czy aplikacja trzyma stary stan?

Otwórz zupełnie nową sesję do tego samego celu, zanim dotkniesz VPN. Jeśli nowa sesja działa, a stara nie, tunel jest w porządku, a aplikacja trzyma martwe połączenie.

To najtańsza z trzech kontroli i najczęściej pomijana, bo okno, które zawodzi, jest tuż na ekranie. Zamknij je, otwórz ponownie i zanotuj, czy problem przetrwa. Jeśli nowa sesja działa, całkowicie przerwij dochodzenie dotyczące tunelu. Jeśli ona też zawodzi, aplikacja jest objawem, a nie przyczyną.

Niektóre aplikacje same się pozbierają po przekroczeniu limitu czasu, dlatego objaw może wyglądać, jakby sam się naprawił po kilku minutach. Takie zachowanie wskazuje na aplikację, a nie na tunel, i warto zapisać je osobno. Kolega, który mówi, że samo się naprawiło, opisuje ten wzorzec, a nie szczęście.

Uczyń porównanie powtarzalnym

Trzymaj zmienne małe: jedna sieć dostępowa, jeden czas uśpienia i to samo pierwsze żądanie za każdym razem. Potem zanotuj dwa wyniki: czy ręczne ponowne połączenie to naprawia i czy kolejne uśpienie przywraca awarię.

Właśnie ta ostatnia obserwacja najpewniej rozdziela trzech kandydatów. Działająca nowa sesja po nieudanej starej to nie problem tunelu i żadna reinstalacja klienta tego nie zmieni.

Stały keepalive WireGuarda należy do tego obrazu tylko jako keepalive mapowania NAT. Wysyła pakiety, aby utrzymać mapowanie otwarte; nie powstrzymuje maszyny przed uśpieniem i nie może dalej wysyłać, gdy proces jest wstrzymany.

Zapisz w zgłoszeniu, co znalazłeś: która z trzech rzeczy była zepsuta, co ją naprawiło i jak to odtworzyłeś. Następna osoba, która w poniedziałek otworzy pokrywę, podziękuje ci, a odpowiedzi nie trzeba będzie odkrywać od nowa.