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

Lokket åpnes, det trådløse ikonet kommer tilbake, og VPN vises fortsatt som tilkoblet. Den første interne siden henger deretter til den timer ut, og en ny fane gjør det samme. Tre ulike ting kan lage det bildet, og de trenger tre ulike reparasjoner: en tunnel som ikke overlevde dvalen, en profil som ingen ba om å gjenaktivere, eller en app som fortsatt holder en økt som døde for timer siden. Å sammenligne dem er raskere enn å installere noe på nytt.

Tre ting kan være ødelagt etter oppvåkning

Den første kandidaten er selve tunnelen. Grensesnittet kan fortsatt finnes med en adresse mens peer-forbindelsen er borte, derfor er en indikatorlampe ikke bevis på en fungerende vei. Et håndtrykk eldre enn dvalen er tegnet, og det tar én kommando å se det.

Den andre er aktivering. Mange klienter kobler seg til igjen selv; noen gjør det ikke, og en profil som ingen ber om å komme tilbake blir sittende og ser konfigurert ut. Den feilen er stille av design, fordi ingenting rapporterte en feil.

Den tredje er appen. En nettleserfane, en SSH-økt eller en databaseforbindelse kan overleve et nettverksbytte som en fildeskriptor mens transporten under er død. Da fungerer en ny økt perfekt, noe som forteller deg at tunnelen var i orden hele tiden.

Sammenlign de tre før du endrer noe, fordi reparasjonene ikke overlapper. Å starte på nytt en klient som aldri ble bedt om å starte igjen, sløser bort beviset du trengte. Skriv ned hvilken kandidat symptomet passer til før du rører en konfigurasjon. Den ene setningen avgjør vanligvis resten av undersøkelsen.

Først: kom tunnelen tilbake?

Se på grensesnittet og peer-tilstanden i stedet for klientens egen statustekst. Et grensesnitt med en adresse og uten ferskt håndtrykk er en tunnel som bare er oppe av navn.

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

Hvis grensesnittet mangler helt, overlevde ikke tunnelen, og spørsmålet blir hvem som skulle ha hentet den tilbake. Hvis det er der, men håndtrykket er gammelt, må peer-forbindelsen gjenopprettes, og klienten venter kanskje på trafikk som kan utløse den.

Kontroller også rutene og DNS-konfigurasjonen. En tunnel kan komme tilbake uten rutene sine, noe som gir den forvirrende tilstanden der grensesnittet er oppe og interne navn fortsatt løses gjennom feil server.

Andre: ba noe den om å komme tilbake?

Det er her sammenligningen betaler seg. En OpenVPN-pluginprofil og en innebygd WireGuard-tilkobling håndteres ulikt av NetworkManager, og referansen for tilkoblingsinnstillinger sier tydelig at connection.autoconnect ikke aktiverer VPN-profiler; mekanismen for å reise en VPN sammen med en tilkobling 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

Hvis manuell gjenoppkobling reparerer problemet hver gang, er det signaturen på en manglende aktivering og ikke på en ødelagt tunnel. Loggen vil vanligvis vise at grensesnittet går ned og at ingenting henter det tilbake.

Motstå fristelsen til å legge til en dvalekrok med en gang. En krok som utløses før nettverket har kommet seg, kappes med den samme prosessen den prøver å hjelpe, og den gjør et reproduserbart problem til et periodisk.

Tredje: holder appen på gammel tilstand?

Åpne en helt ny økt til samme mål før du rører VPN. Hvis den nye økten virker og den gamle ikke, er tunnelen i orden og appen holder på en død forbindelse.

Dette er den billigste av de tre kontrollene og den som oftest hoppes over, fordi vinduet som feiler er rett på skjermen. Lukk det, åpne det igjen, og noter om problemet overlever. Hvis den nye økten virker, stopp undersøkelsen av tunnelen helt. Hvis den også feiler, er appen et symptom og ikke en årsak.

Noen apper kommer seg selv etter en tidsavbrudd, derfor kan symptomet se ut som det reparerer seg selv etter noen minutter. Den oppførselen peker på appen og ikke på tunnelen, og det er verdt å notere separat. En kollega som sier at det bare reparerte seg selv, beskriver dette mønsteret, ikke flaks.

Gjør sammenligningen reproduserbar

Hold variablene små: ett tilgangsnett, én dvaletid og den samme første forespørselen hver gang. Logg deretter to resultater: om manuell gjenoppkobling reparerer det, og om enda en dvale bringer feilen tilbake.

Den siste observasjonen er den som skiller de tre kandidatene mest pålitelig. En fungerende ny økt etter en mislykket gammel er ikke et tunnelproblem, og ingen reinstallering av klienten vil endre det.

WireGuards vedvarende keepalive hører bare hjemme i dette bildet som en keepalive for NAT-mapping. Den sender pakker for å holde en mapping åpen; den hindrer ikke maskinen i å gå i dvale og kan ikke fortsette å sende mens prosessen er suspendert.

Skriv i saken hva du fant: hvilken av de tre som var ødelagt, hva som reparerte den og hvordan du reproduserte det. Den neste som åpner et lokk en mandag, vil takke deg, og svaret trenger ikke oppdages på nytt fra bunnen.