VPN død efter dvale: tabt tunnel eller forældet app?

Låget åbnes, det trådløse ikon kommer tilbage, og VPN vises stadig som forbundet. Den første interne side hænger derefter, indtil den timer ud, og en ny fane gør det samme. Tre forskellige ting kan frembringe det billede, og de kræver tre forskellige rettelser: en tunnel, der ikke overlevede dvalen, en profil, som ingen bad om at genaktivere, eller et program, der stadig holder en session, som døde for timer siden. At sammenligne dem er hurtigere end at geninstallere noget.

Tre ting kan være i stykker efter opvågning

Den første kandidat er selve tunnelen. Interfacet kan stadig findes med en adresse, mens peer-forbindelsen er væk, og derfor er en indikatorlampe ikke bevis på en fungerende vej. Et håndtryk ældre end dvalen er tegnet, og der skal én kommando til at se det.

Den anden er aktivering. Mange klienter genopretter forbindelsen selv; nogle gør ikke, og en profil, som ingen beder om at vende tilbage, bliver siddende og ser konfigureret ud. Den fejl er tavs af design, fordi intet gav en fejl.

Den tredje er programmet. En browserfane, en SSH-session eller en databaseforbindelse kan overleve et netværksskift som en fildeskriptor, mens transporten under den er død. En ny session virker derefter perfekt, hvilket fortæller dig, at tunnelen var fin hele tiden.

Sammenlign de tre, før du ændrer noget, fordi rettelserne ikke overlapper. At genstarte en klient, som aldrig blev bedt om at starte igen, spilder det bevis, du havde brug for. Skriv ned, hvilken kandidat symptomet passer på, før du rører en konfiguration. Den ene sætning afgør som regel resten af undersøgelsen.

Først: kom tunnelen tilbage?

Se på interfacet og peer-tilstanden i stedet for klientens egen statustekst. Et interface med en adresse og uden et nyt håndtryk er en tunnel, der kun er oppe af navn.

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

Hvis interfacet mangler helt, overlevede tunnelen ikke, og spørgsmålet bliver, hvem der skulle bringe den tilbage. Hvis det er der, men håndtrykket er gammelt, skal peer-forbindelsen genoprettes, og klienten venter måske på trafik, der kan udløse den.

Kontroller også ruterne og DNS-konfigurationen. En tunnel kan komme tilbage uden sine ruter, hvilket giver den forvirrende tilstand, hvor interfacet er oppe, og interne navne stadig slås op via den forkerte server.

Andet: bad noget den om at komme tilbage?

Det er her, sammenligningen betaler sig. En OpenVPN-pluginprofil og en indbygget WireGuard-forbindelse håndteres forskelligt af NetworkManager, og referencen til forbindelsesindstillinger siger udtrykkeligt, at connection.autoconnect ikke aktiverer VPN-profiler; mekanismen til at rejse en VPN sammen med en forbindelse 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 en manuel genopkobling reparerer problemet hver gang, er det signaturen på en manglende aktivering og ikke på en ødelagt tunnel. Loggen vil normalt vise, at interfacet går ned, og at intet bringer det tilbage.

Modstå trangen til straks at tilføje et dvalekrog. Et hook, der udløses, før netværket er kommet sig, kappes med den proces, det prøver at hjælpe, og det gør et reproducerbart problem til et periodisk.

Tredje: holder programmet gammel tilstand?

Åbn en helt ny session til samme destination, før du rører VPN. Hvis den nye session virker, og den gamle ikke gør, er tunnelen fin, og programmet holder en død forbindelse.

Dette er den billigste af de tre kontroller og den, der oftest springes over, fordi det svigtende vindue er lige på skærmen. Luk det, åbn det igen, og noter, om problemet overlever. Hvis den nye session virker, stop undersøgelsen af tunnelen helt. Hvis den også fejler, er programmet et symptom og ikke en årsag.

Nogle programmer kommer sig selv efter en timeout, og derfor kan symptomet se ud, som om det retter sig selv efter få minutter. Den adfærd peger på programmet og ikke på tunnelen, og det er værd at notere separat. En kollega, der siger, at det bare rettede sig selv, beskriver dette mønster og ikke et held.

Gør sammenligningen reproducerbar

Hold variablene små: ét adgangsnetværk, én dvaletid og den samme første anmodning hver gang. Log derefter to resultater: om manuel genopkobling reparerer det, og om endnu en dvale bringer fejlen tilbage.

Den sidste observation er den, der skiller de tre kandidater mest pålideligt. En fungerende ny session efter en mislykket gammel er ikke et tunnelproblem, og ingen geninstallation af klienten ændrer det.

WireGuards vedvarende keepalive hører kun hjemme i dette billede som en keepalive for NAT-mapping. Den sender pakker for at holde en mapping åben; den forhindrer ikke maskinen i at gå i dvale og kan ikke fortsætte med at sende, mens processen er suspenderet.

Skriv i billetten, hvad du fandt: hvilken af de tre der var i stykker, hvad der reparerede den, og hvordan du reproducerede det. Den næste, der åbner et låg en mandag, vil takke dig, og svaret skal ikke genopdages fra bunden.