VPN dood ná slaap: tonnel verloor of verouderde app?

Die deksel gaan oop, die draadlose ikoon kom terug, en die VPN wys steeds as verbind. Die eerste interne bladsy hang dan tot dit tyd uit, en ’n nuwe oortjie doen dieselfde. Drie verskillende dinge kan daardie prentjie lewer, en hulle vra drie verskillende regstellings: ’n tonnel wat nie die slaap oorleef het nie, ’n profiel wat niks gevra het om te heractiveer nie, of ’n toepassing wat nog ’n sessie vashou wat ure gelede gesterf het. Om hulle te vergelyk is vinniger as om enigiets te herinstalleer.

Drie dinge kan ná ontwaking stukkend wees

Die eerste kandidaat is die tonnel self. Die koppelvlak kan nog met ’n adres bestaan terwyl die eweknie-assosiasie weg is, en daarom is ’n aandliggie nie bewys van ’n werkende pad nie. ’n Handdruk ouer as die slaap is die teken, en dit neem een opdrag om te sien.

Die tweede is aktivering. Baie kliënte koppel vanself weer; sommige nie, en ’n profiel wat nie gevra word om terug te kom nie, bly daar sit en lyk opgestel. Daardie faling is doelbewus stil, want niks het ’n fout gegee nie.

Die derde is die toepassing. ’n Blaaier-oortjie, ’n SSH-sessie of ’n databasisverbinding kan ’n netwerkverandering as ’n lêerbeskrywer oorleef terwyl die vervoer daaronder dood is. ’n Nuwe sessie werk dan perfek, wat jou wys die tonnel was die hele tyd reg.

Vergelyk die drie voordat jy enigiets verander, want die regstellings oorvleuel nie. Om ’n kliënt te herbegin wat nooit gevra is om weer te begin nie, mors die bewyse wat jy nodig gehad het. Skryf neer by watter kandidaat die simptoom pas voordat jy aan ’n konfigurasie raak. Daardie een sin besluit gewoonlik die res van die ondersoek.

Eerste: het die tonnel teruggekom?

Kyk na die koppelvlak en die ewekniestatus eerder as na die kliënt se eie statusteks. ’n Koppelvlak met ’n adres en geen onlangse handdruk is ’n tonnel wat net op papier bestaan.

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

As die koppelvlak heeltemal weg is, het die tonnel nie oorleef nie en word die vraag wie dit moes terugbring. As dit daar is maar die handdruk is oud, moet die eweknieverhouding herstel word en wag die kliënt dalk vir verkeer om dit te aktiveer.

Kyk ook na die roetes en die DNS-opstelling. ’n Tonnel kan sonder sy roetes terugkom, wat die verwarrende toestand gee waar die koppelvlak op is en interne name steeds deur die verkeerde bediener oplos.

Tweede: het iets gevra dat dit moet terugkom?

Dit is waar die vergelyking sy geld werd. ’n OpenVPN-inprop-profiel en ’n native WireGuard-verbinding word anders deur NetworkManager hanteer, en die verwysing vir verbindingsinstellings is duidelik dat connection.autoconnect nie VPN-profiele aktiveer nie; die meganisme om ’n VPN saam met ’n verbinding op te bring 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

As ’n handmatige herverbinding die probleem elke keer regstel, is dit die kenmerk van ’n ontbrekende aktivering eerder as ’n stukkende tonnel. Die logboek sal gewoonlik wys die koppelvlak gaan af en niks bring dit terug nie.

Weerstaan die drang om dadelik ’n slaaphook by te voeg. ’n Hook wat afvuur voordat die netwerk herstel het, jaag die proses wat hy probeer help, en dit maak ’n herhaalbare probleem ’n onreëlmatige een.

Derde: hou die toepassing ou toestand?

Maak ’n splinternuwe sessie na dieselfde bestemming oop voordat jy aan die VPN raak. As die nuwe sessie werk en die ou een nie, is die tonnel reg en hou die toepassing ’n dooie verbinding.

Dit is die goedkoopste van die drie kontroles en die een wat die meeste oorgeslaan word, want die foutvenster is reg voor jou op die skerm. Maak dit toe, maak dit weer oop, en let op of die probleem oorleef. As die nuwe sessie werk, stop die ondersoek na die tonnel heeltemal. As dit ook misluk, is die toepassing ’n simptoom eerder as ’n oorsaak.

Sommige toepassings herstel vanself ná ’n tyd uit, en daarom kan die simptoom lyk of dit ná ’n paar minute homself regmaak. Daardie gedrag wys na die toepassing eerder as na die tonnel, en dit is werd om apart te noteer. ’n Kollega wat sê dit het net homself reggemaak, beskryf hierdie patroon, nie ’n gelukkige breuk nie.

Maak die vergelyking herhaalbaar

Hou die veranderlikes klein: een toegangsnetwerk, een slaaptyd en elke keer dieselfde eerste versoek. Teken dan twee uitkomste aan: of handmatige herverbinding dit regstel, en of nog ’n slaap die faling terugbring.

Daardie laaste waarneming is die een wat die drie kandidate die betroubaarste skei. ’n Werkende nuwe sessie ná ’n mislukte ou een is nie ’n tonnelprobleem nie, en geen mate van herinstallasie van die kliënt sal dit verander nie.

WireGuard se aanhoudende keepalive hoort net as ’n NAT-kaartkeepalive in hierdie prentjie. Dit stuur pakkette om ’n kaart oop te hou; dit keer nie die masjien om te slaap nie en dit kan nie aanhou stuur terwyl die proses opgeskort is nie.

Teken in die kaartjie aan wat jy gevind het: watter van die drie stukkend was, wat dit reggestel het en hoe jy dit herhaal het. Die volgende persoon wat Maandag ’n deksel oopmaak, sal jou dank, en die antwoord hoef nie van nuuts af herontdek te word nie.