VPN død etter dvale: tapt tunnel eller utdatert app?

Loket blir opna, det trådlause ikonet kjem tilbake, og VPN blir framleis visa som tilkopla. Den første interne sida heng deretter til ho timar ut, og ei ny fane gjer det same. Tre ulike ting kan lage det bildet, og dei treng tre ulike reparasjonar: ein tunnel som ikkje overlevde dvalen, ein profil som ingen bad om å gjenaktivere, eller ein app som framleis held på ei økt som døydde for timar sidan. Å samanlikne dei er raskare enn å installere noko på nytt.

Tre ting kan vere øydelagde etter oppvakning

Den første kandidaten er sjølve tunnelen. Grensesnittet kan framleis finnast med ei adresse medan peer-sambandet er borte, difor er ei indikatorlampe ikkje prov på ein fungerande veg. Eit handtrykk eldre enn dvalen er teiknet, og det tek éin kommando å sjå det.

Den andre er aktiveringa. Mange klientar koplar seg til att sjølve; nokre gjer det ikkje, og ein profil som ingen ber om å kome tilbake blir sitjande og ser konfigurert ut. Den feilen er stille av design, fordi ingenting rapporterte ein feil.

Den tredje er appen. Ei nettlesarfane, ei SSH-økt eller ei databasekopling kan overleve eit nettverksbyte som ein fildeskriptor medan transporten under er død. Då fungerer ei ny økt perfekt, noko som fortel deg at tunnelen var i orden heile tida.

Samanlikn dei tre før du endrar noko, fordi reparasjonane overlappar ikkje. Å starte på nytt ein klient som aldri vart beden om å starte att, sløser bort provet du trong. Skriv ned kva kandidat symptomet passar til før du rører ein konfigurasjon. Den eine setninga avgjer vanlegvis resten av undersøkinga.

Først: kom tunnelen tilbake?

Sjå på grensesnittet og peer-tilstanden i staden for statusteksten til klienten. Eit grensesnitt med ei adresse og utan ferskt handtrykk er ein tunnel som berre er oppe av namn.

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

Viss grensesnittet manglar heilt, overlevde ikkje tunnelen, og spørsmålet blir kven som skulle ha henta han tilbake. Viss det er der, men handtrykket er gamalt, må peer-sambandet gjenopprettast, og klienten ventar kanskje på trafikk som kan utløyse det.

Kontroller òg rutene og DNS-konfigurasjonen. Ein tunnel kan kome tilbake utan rutene sine, noko som gir den forvirrande tilstanden der grensesnittet er oppe og interne namn framleis blir løyste gjennom feil tenar.

Andre: bad noko han om å kome tilbake?

Det er her samanlikninga svarar seg. Ein OpenVPN-programtilleggsprofil og ei innebygd WireGuard-kopling blir handsama ulikt av NetworkManager, og referansen for koplinginnstillingar seier tydeleg at connection.autoconnect ikkje aktiverer VPN-profilar; mekanismen for å reise ein VPN saman med ei kopling er connection.secondaries.

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

Viss manuell attkopling reparerer problemet kvar gong, er det signaturen på ei manglande aktivering og ikkje på ein øydelagd tunnel. Loggen vil vanlegvis vise at grensesnittet går ned og at ingenting hentar det tilbake.

Motstå freistinga å leggje til ein dvalekrok med ein gong. Ein krok som blir utløyst før nettverket har kome seg, kappast med den same prosessen han prøver å hjelpe, og han gjer eit reproduserbart problem til eit periodisk.

Tredje: held appen på gamal tilstand?

Opne ei heilt ny økt til same mål før du rører VPN. Viss den nye økta verkar og den gamle ikkje, er tunnelen i orden og appen held på ei død kopling.

Dette er den billegaste av dei tre kontrollane og den som oftast blir hoppa over, fordi vindauget som feilar er rett på skjermen. Lat det att, opne det på nytt, og noter om problemet overlever. Viss den nye økta verkar, stopp undersøkinga av tunnelen heilt. Viss ho òg feilar, er appen eit symptom og ikkje ei årsak.

Nokre appar kjem seg sjølve etter ein tidsavbrot, difor kan symptomet sjå ut som det reparerer seg sjølv etter nokre minutt. Den åtferda peikar på appen og ikkje på tunnelen, og det er verdt å notere separat. Ein kollega som seier at det berre reparerte seg sjølv, skildrar dette mønsteret, ikkje flaks.

Gjer samanlikninga reproduserbar

Hald variablane små: eitt tilgangsnett, éin dvaletid og den same første førespurnaden kvar gong. Logg deretter to resultat: om manuell attkopling reparerer det, og om endå ein dvale bringar feilen tilbake.

Den siste observasjonen er den som skil dei tre kandidatane mest påliteleg. Ei fungerande ny økt etter ei mislukka gamal er ikkje eit tunnelproblem, og inga reinstallasjon av klienten vil endre det.

Den vedvarande keepalive-en til WireGuard høyrer berre heime i dette bildet som ein keepalive for NAT-mapping. Han sender pakkar for å halde ei mapping open; han hindrar ikkje maskinen i å gå i dvale og kan ikkje halde fram med å sende medan prosessen er suspendert.

Skriv i saka kva du fann: kva av dei tre som var øydelagd, kva som reparerte han og korleis du reproduserte det. Den neste som opnar eit lok på ein måndag, vil takke deg, og svaret treng ikkje bli oppdaga på nytt frå botnen.