VPN död efter viloläge: förlorad tunnel eller föråldrad app?

Locket öppnas, den trådlösa ikonen kommer tillbaka och VPN visas fortfarande som anslutet. Den första interna sidan hänger sedan tills den timear ut, och en ny flik gör samma sak. Tre olika saker kan skapa den bilden och de behöver tre olika åtgärder: en tunnel som inte överlevde viloläget, en profil som ingen bad att återaktivera, eller en app som fortfarande håller en session som dog för timmar sedan. Att jämföra dem går snabbare än att installera om något.

Tre saker kan gå sönder efter uppvaknandet

Den första kandidaten är själva tunneln. Gränssnittet kan fortfarande finnas med en adress medan peer-kopplingen är borta, därför är en indikatorlampa inte bevis på en fungerande väg. En handskakning äldre än viloläget är tecknet, och det räcker med ett kommando för att se det.

Den andra är aktiveringen. Många klienter återansluter själva; vissa gör det inte, och en profil som ingen ber att komma tillbaka sitter kvar och ser konfigurerad ut. Det felet är tyst av design, eftersom ingenting rapporterade ett fel.

Den tredje är appen. En webbläsarflik, en SSH-session eller en databasanslutning kan överleva ett nätverksbyte som en fildeskriptor medan transporten under är död. Då fungerar en ny session perfekt, vilket säger dig att tunneln var i ordning hela tiden.

Jämför de tre innan du ändrar något, eftersom åtgärderna inte överlappar. Att starta om en klient som aldrig bads starta igen slösar bort beviset du behövde. Skriv ned vilken kandidat symptomet passar innan du rör en konfiguration. Den enda meningen avgör oftast resten av undersökningen.

Först: kom tunneln tillbaka?

Titta på gränssnittet och peer-tillståndet i stället för klientens egen statustext. Ett gränssnitt med en adress och utan färsk handskakning är en tunnel som bara är uppe till namnet.

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

Om gränssnittet saknas helt överlevde inte tunneln, och frågan blir vem som skulle ha hämtat tillbaka den. Om det finns men handskakningen är gammal måste peer-kopplingen återupprättas, och klienten väntar kanske på trafik som kan utlösa den.

Kontrollera också rutterna och DNS-konfigurationen. En tunnel kan komma tillbaka utan sina rutter, vilket ger det förvirrande tillståndet där gränssnittet är uppe och interna namn fortfarande löses via fel server.

Andra: bad något den att komma tillbaka?

Det är här jämförelsen lönar sig. En OpenVPN-pluginprofil och en inbyggd WireGuard-anslutning hanteras olika av NetworkManager, och referensen för anslutningsinställningar säger uttryckligen att connection.autoconnect inte aktiverar VPN-profiler; mekanismen för att resa en VPN med en anslutning är connection.secondaries.

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

Om manuell återanslutning reparerar problemet varje gång är det signaturen för en saknad aktivering och inte för en trasig tunnel. Loggen visar oftast att gränssnittet går ned och att ingenting hämtar tillbaka det.

Motstå frestelsen att lägga till en vilolägskrok direkt. En krok som utlöses innan nätverket har återhämtat sig kappas med samma process som den försöker hjälpa, och den gör ett reproducerbart problem till ett periodiskt.

Tredje: håller appen kvar gammalt tillstånd?

Öppna en helt ny session till samma mål innan du rör VPN. Om den nya sessionen fungerar och den gamla inte, är tunneln i ordning och appen håller en död anslutning.

Detta är den billigaste av de tre kontrollerna och den som oftast hoppas över, eftersom fönstret som misslyckas ligger rakt på skärmen. Stäng det, öppna det igen och notera om problemet överlever. Om den nya sessionen fungerar, avbryt undersökningen av tunneln helt. Om den också misslyckas är appen ett symptom och inte en orsak.

Vissa appar återhämtar sig själva efter en tidsgräns, därför kan symptomet se ut att reparera sig självt efter några minuter. Det beteendet pekar på appen och inte på tunneln, och det är värt att notera separat. En kollega som säger att det bara reparerade sig självt beskriver det här mönstret, inte tur.

Gör jämförelsen reproducerbar

Håll variablerna små: ett åtkomstnät, en vilolägstid och samma första förfrågan varje gång. Logga sedan två resultat: om manuell återanslutning reparerar det, och om ännu ett viloläge för tillbaka felet.

Den sista observationen är den som skiljer de tre kandidaterna mest tillförlitligt. En fungerande ny session efter en misslyckad gammal är inte ett tunnelproblem, och ingen ominstallation av klienten ändrar det.

WireGuards ständiga keepalive hör bara hemma i den här bilden som en keepalive för NAT-mappning. Den skickar paket för att hålla en mappning öppen; den hindrar inte maskinen från att gå i viloläge och kan inte fortsätta skicka medan processen är avstängd.

Skriv i ärendet vad du hittade: vilken av de tre som var trasig, vad som reparerade den och hur du reproducerade det. Nästa person som öppnar ett lock på en måndag kommer att tacka dig, och svaret behöver inte upptäckas på nytt från början.