VPN dood na slaapstand: tunnel kwijt of verouderde app?

Het deksel gaat open, het wifisymbool komt terug en de VPN toont zich nog steeds verbonden. De eerste interne pagina blijft dan hangen tot de time-out, en een nieuw tabblad doet hetzelfde. Drie verschillende dingen kunnen dat beeld opleveren en ze vragen drie verschillende reparaties: een tunnel die de slaapstand niet overleefde, een profiel dat niemand vroeg opnieuw te activeren, of een toepassing die nog een sessie vasthoudt die uren geleden stierf. Ze vergelijken is sneller dan wat dan ook opnieuw installeren.

Drie dingen kunnen na het ontwaken kapot zijn

De eerste kandidaat is de tunnel zelf. De interface kan nog bestaan met een adres terwijl de koppeling met de peer weg is, daarom is een indicatielampje geen bewijs van een werkende route. Een handdruk ouder dan de slaapstand is het teken, en één opdracht volstaat om het te zien.

De tweede is activering. Veel clients verbinden zelf opnieuw; sommige niet, en een profiel dat niemand vraagt terug te komen blijft daar zitten en ziet er geconfigureerd uit. Die fout is stil van ontwerp, omdat niets een fout meldde.

De derde is de toepassing. Een browsertabblad, een SSH-sessie of een databaseverbinding kan een netwerkwijziging overleven als bestandsdescriptor terwijl het transport eronder dood is. Een nieuwe sessie werkt dan perfect, wat je vertelt dat de tunnel al die tijd in orde was.

Vergelijk de drie voordat je iets wijzigt, want de reparaties overlappen niet. Een client herstarten die nooit gevraagd is opnieuw te starten verspilt het bewijs dat je nodig had. Schrijf op welke kandidaat bij het symptoom past voordat je een configuratie aanraakt. Die ene zin bepaalt meestal de rest van het onderzoek.

Eerst: kwam de tunnel terug?

Kijk naar de interface en de peertoestand in plaats van de statustekst van de client. Een interface met een adres en zonder recente handdruk is een tunnel die enkel in naam bestaat.

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

Als de interface helemaal ontbreekt, overleefde de tunnel het niet en wordt de vraag wie hem terug had moeten brengen. Als hij er is maar de handdruk oud is, moet de koppeling met de peer opnieuw worden opgebouwd, en de client wacht misschien op verkeer dat hem activeert.

Controleer ook de routes en de DNS-configuratie. Een tunnel kan terugkomen zonder zijn routes, wat de verwarrende toestand geeft waarin de interface actief is en interne namen nog steeds via de verkeerde server worden opgelost.

Ten tweede: vroeg iets hem terug te komen?

Hier verdient de vergelijking zich terug. Een OpenVPN-pluginprofiel en een native WireGuard-verbinding worden anders behandeld door NetworkManager, en de referentie voor verbindingsinstellingen zegt duidelijk dat connection.autoconnect geen VPN-profielen activeert; het mechanisme om een VPN met een verbinding op te zetten is connection.secondaries.

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

Als handmatig opnieuw verbinden het probleem elke keer verhelpt, is dat de signatuur van een ontbrekende activering en niet van een kapotte tunnel. Het logboek toont meestal dat de interface naar beneden gaat en niets hem terugbrengt.

Weerst het verlangen om meteen een slaapstandhook toe te voegen. Een hook die afgaat voordat het netwerk is hersteld, racet met precies het proces dat hij probeert te helpen, en hij maakt van een reproduceerbaar probleem een periodiek probleem.

Ten derde: houdt de toepassing oude toestand vast?

Open een volledig nieuwe sessie naar dezelfde bestemming voordat je de VPN aanraakt. Als de nieuwe sessie werkt en de oude niet, is de tunnel in orde en houdt de toepassing een dode verbinding vast.

Dit is de goedkoopste van de drie controles en degene die het vaakst wordt overgeslagen, omdat het venster dat faalt precies op het scherm staat. Sluit het, open het opnieuw en noteer of het probleem overleeft. Als de nieuwe sessie werkt, stop het onderzoek naar de tunnel volledig. Als die ook faalt, is de toepassing een symptoom en geen oorzaak.

Sommige toepassingen herstellen zichzelf na een time-out, daarom kan het lijken of het symptoom na een paar minuten zichzelf oplost. Dat gedrag wijst op de toepassing en niet op de tunnel, en het is de moeite waard apart te noteren. Een collega die zegt dat het zich gewoon zelf oploste, beschrijft dit patroon en geen geluk.

Maak de vergelijking reproduceerbaar

Houd de variabelen klein: één toegangsnetwerk, één slaapduur en elke keer hetzelfde eerste verzoek. Noteer dan twee resultaten: of handmatig opnieuw verbinden het verhelpt, en of nog een slaapstand de fout terugbrengt.

Die laatste observatie is degene die de drie kandidaten het betrouwbaarst scheidt. Een werkende nieuwe sessie na een mislukte oude is geen tunnelprobleem, en geen herinstallatie van de client zal dat veranderen.

De blijvende keepalive van WireGuard hoort hier alleen thuis als keepalive voor NAT-mapping. Hij stuurt pakketten om een mapping open te houden; hij verhindert niet dat de machine in slaap valt en kan niet blijven sturen terwijl het proces is opgeschort.

Noteer in het ticket wat je vond: welk van de drie kapot was, wat het repareerde en hoe je het reproduceerde. De volgende persoon die op maandag een deksel opent, zal je dankbaar zijn, en het antwoord hoeft niet vanaf nul opnieuw te worden ontdekt.