VPN po uspání mrtvá: ztracený tunel, nebo zastaralá aplikace?

Víko se otevře, ikona bezdrátové sítě se vrátí a VPN se stále hlásí jako připojená. První interní stránka pak visí, dokud nevyprší časový limit, a nová karta dělá totéž. Takový obraz mohou vytvořit tři různé věci a potřebují tři různé opravy: tunel, který uspání nepřežil, profil, který nikdo nepožádal o opětovnou aktivaci, nebo aplikace, která stále drží relaci, jež zemřela před hodinami. Porovnat je je rychlejší než cokoli přeinstalovávat.

Po probuzení se mohou pokazit tři věci

Prvním kandidátem je samotný tunel. Rozhraní může dál existovat s adresou, zatímco přidružení k protějšku zmizelo, a proto kontrolka není důkazem funkční cesty. Handshake starší než uspání je tou stopou a stačí jeden příkaz, abyste ho viděli.

Druhou je aktivace. Mnoho klientů se připojí znovu samo; některé ne, a profil, který nikdo nevyzve k návratu, tam jen zůstane a vypadá nastavený. Toto selhání je záměrně tiché, protože nic neohlásilo chybu.

Třetí je aplikace. Karta prohlížeče, relace SSH nebo připojení k databázi mohou přežít změnu sítě jako deskriptor souboru, zatímco přenos pod nimi je mrtvý. Nová relace pak funguje bezvadně, což vám říká, že tunel byl celou dobu v pořádku.

Porovnejte všechny tři dřív, než něco změníte, protože opravy se nepřekrývají. Restart klienta, který nebyl nikdy vyzván ke spuštění, plýtvá důkazem, který jste potřebovali. Než se dotknete konfigurace, zapište, ke kterému kandidátu symptom patří. Ta jediná věta obvykle rozhodne o zbytku vyšetřování.

Za prvé: vrátil se tunel?

Sledujte rozhraní a stav protějšku, ne vlastní stavový text klienta. Rozhraní s adresou a bez nedávného handshake je tunel, který existuje jen na papíře.

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

Pokud rozhraní úplně chybí, tunel nepřežil a otázkou se stává, kdo ho měl vrátit. Pokud existuje, ale handshake je starý, je třeba obnovit vztah s protějškem a klient může čekat na provoz, který ho spustí.

Zkontrolujte také trasy a nastavení DNS. Tunel se může vrátit bez svých tras, což vytváří matoucí stav, kdy rozhraní funguje a interní jména se stále překládají přes špatný server.

Za druhé: požádal ho někdo o návrat?

Tady se porovnání vyplatí. Profil zásuvného modulu OpenVPN a nativní připojení WireGuard zpracovává NetworkManager různě a reference nastavení připojení jasně uvádí, že connection.autoconnect profily VPN neaktivuje; mechanismem pro zvednutí VPN spolu s připojení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

Pokud ruční opětovné připojení problém pokaždé opraví, je to podpis chybějící aktivace, ne rozbitého tunelu. Protokol obvykle ukáže, jak rozhraní padá a nic ho nevrací.

Odolejte nutkání hned přidat hook pro uspání. Hook, který se spustí dřív, než se síť vzpamatuje, závodí s procesem, kterému se snaží pomoci, a převádí reprodukovatelný problém na občasný.

Za třetí: drží aplikace starý stav?

Než se dotknete VPN, otevřete úplně novou relaci ke stejnému cíli. Pokud nová relace funguje a stará ne, tunel je v pořádku a aplikace drží mrtvé připojení.

Toto je nejlevnější ze tří kontrol a ta nejčastěji vynechávaná, protože okno se selháním je přímo na obrazovce. Zavřete ho, otevřete znovu a poznamenejte, zda problém přežívá. Pokud nová relace funguje, vyšetřování tunelu úplně ukončete. Pokud selže i ona, aplikace je symptom, ne příčina.

Některé aplikace se po vypršení limitu zotaví samy, a proto se může zdát, že se symptom po pár minutách sám opraví. Takové chování ukazuje na aplikaci, ne na tunel, a stojí za samostatné zaznamenání. Kolega, který hlásí, že se to prostě samo opravilo, popisuje tento vzorec, ne šťastnou náhodu.

Udělejte porovnání reprodukovatelné

Držte proměnné malé: jedna přístupová síť, jedna doba uspání a stejný první požadavek pokaždé. Pak zaznamenejte dva výsledky: zda to ruční připojení opraví a zda další uspání selhání vrátí.

Právě poslední pozorování odděluje tři kandidáty nejspolehlivěji. Funkční nová relace po selhané staré není problém tunelu a žádná reinstalace klienta to nezmění.

Trvalý keepalive WireGuardu patří do tohoto obrazu jen jako keepalive pro mapování NAT. Posílá pakety, aby udržel mapování otevřené; nebrání stroji usnout a nemůže pokračovat v odesílání, dokud je proces pozastaven.

Zapište do tiketu, co jste zjistili: která ze tří věcí byla rozbitá, co ji opravilo a jak jste to zopakovali. Příští člověk, který v pondělí otevře víko, vám poděkuje a odpověď nebude muset být znovu objevována od nuly.