VPN mŕtva po uspaní: stratený tunel alebo zastaraná aplikácia?

Veko sa otvorí, ikona bezdrôtovej siete sa vráti a VPN sa stále hlási ako pripojená. Prvá interná stránka potom visí, kým nevyprší časový limit, a nová karta robí to isté. Taký obraz môžu vytvoriť tri rôzne veci a potrebujú tri rôzne opravy: tunel, ktorý neprežil uspanie, profil, ktorý nikto nepožiadal o opätovnú aktiváciu, alebo aplikácia, ktorá stále drží reláciu, ktorá zomrela pred hodinami. Porovnať ich je rýchlejšie než čokoľvek preinštalovať.

Po prebudení sa môžu pokaziť tri veci

Prvým kandidátom je samotný tunel. Rozhranie môže ďalej existovať s adresou, kým pridruženie k partnerovi zmizlo, preto kontrolka nie je dôkazom funkčnej cesty. Handshake starší ako uspanie je tou stopou a stačí jeden príkaz, aby ste ho videli.

Druhou je aktivácia. Mnohí klienti sa pripoja znova sami; niektorí nie, a profil, ktorý nikto nevyzve na návrat, tam len zostane a vyzerá nastavený. Toto zlyhanie je zámerne tiché, pretože nič neohlásilo chybu.

Treťou je aplikácia. Karta prehliadača, relácia SSH alebo pripojenie k databáze môžu prežiť zmenu siete ako deskriptor súboru, kým prenos pod nimi je mŕtvy. Nová relácia potom funguje bezchybne, čo vám hovorí, že tunel bol celý čas v poriadku.

Porovnajte všetky tri, skôr než niečo zmeníte, pretože opravy sa neprekrývajú. Reštart klienta, ktorý nikdy nebol vyzvaný na opätovné spustenie, plytvá dôkazom, ktorý ste potrebovali. Skôr než sa dotknete konfigurácie, zapíšte, ktorému kandidátovi symptom zodpovedá. Tá jediná veta zvyčajne rozhodne o zvyšku vyšetrovania.

Za prvé: vrátil sa tunel?

Sledujte rozhranie a stav partnera, nie stavový text klienta. Rozhranie s adresou a bez nedávneho handshake je tunel, ktorý existuje len podľa mena.

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

Ak rozhranie úplne chýba, tunel neprežil a otázkou sa stáva, kto ho mal vrátiť. Ak existuje, ale handshake je starý, vzťah s partnerom treba obnoviť a klient možno čaká na prevádzku, ktorá ho spustí.

Skontrolujte aj trasy a nastavenie DNS. Tunel sa môže vrátiť bez svojich trás, čo vytvára mätúci stav, keď rozhranie funguje a interné názvy sa stále prekladajú cez nesprávny server.

Za druhé: požiadal ho niekto o návrat?

Tu sa porovnanie vyplatí. Profil zásuvného modulu OpenVPN a natívne pripojenie WireGuard spracúva NetworkManager odlišne a referencia nastavení pripojenia jasne uvádza, že connection.autoconnect profily VPN neaktivuje; mechanizmom na zdvihnutie VPN spolu s pripojením je connection.secondaries.

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

Ak ručné opätovné pripojenie problém zakaždým opraví, je to podpis chýbajúcej aktivácie, nie rozbitého tunela. Záznam zvyčajne ukáže, ako rozhranie padá a nič ho nevracia.

Odolajte nutkaniu hneď pridať hook na uspanie. Hook, ktorý sa spustí skôr, než sa sieť vzpamätá, preteká sa s tým istým procesom, ktorému sa snaží pomôcť, a mení reprodukovateľný problém na občasný.

Za tretie: drží aplikácia starý stav?

Skôr než sa dotknete VPN, otvorte úplne novú reláciu k rovnakému cieľu. Ak nová relácia funguje a stará nie, tunel je v poriadku a aplikácia drží mŕtve pripojenie.

Toto je najlacnejšia z troch kontrol a tá najčastejšie vynechávaná, pretože okno, ktoré zlyháva, je priamo na obrazovke. Zatvorte ho, otvorte znova a poznamenajte, či problém pretrváva. Ak nová relácia funguje, vyšetrovanie tunela úplne ukončite. Ak zlyhá aj ona, aplikácia je symptom, nie príčina.

Niektoré aplikácie sa po vypršaní limitu zotavia samy, preto sa môže zdať, že sa symptom po pár minútach sám opraví. Také správanie ukazuje na aplikáciu, nie na tunel, a stojí za samostatné zaznamenanie. Kolega, ktorý hovorí, že sa to jednoducho samo opravilo, opisuje tento vzor, nie šťastie.

Urobte porovnanie reprodukovateľným

Držte premenné malé: jedna prístupová sieť, jedno trvanie uspania a rovnaká prvá požiadavka zakaždým. Potom zaznamenajte dva výsledky: či to ručné pripojenie opraví a či ďalšie uspanie vráti zlyhanie.

Práve posledné pozorovanie oddeľuje troch kandidátov najspoľahlivejšie. Funkčná nová relácia po zlyhanej starej nie je problém tunela a žiadna preinštalácia klienta to nezmení.

Trvalý keepalive WireGuardu patrí do tohto obrazu iba ako keepalive mapovania NAT. Posiela pakety, aby udržal mapovanie otvorené; nebráni stroju zaspať a nemôže pokračovať v odosielaní, kým je proces pozastavený.

Zapíšte do tiketu, čo ste zistili: ktorá z troch vecí bola rozbitá, čo ju opravilo a ako ste to zopakovali. Ďalší človek, ktorý v pondelok otvorí veko, vám poďakuje a odpoveď nebude musieť byť znovu objavená od nuly.