VPN mrtev po mirovanju: izgubljen tunel ali zastarela aplikacija?

Pokrov se odpre, ikona brezžičnega omrežja se vrne in VPN je še vedno prikazan kot povezan. Prva notranja stran se nato obesi, dokler ne poteče čas, in nov zavihek naredi enako. Tri različne stvari lahko ustvarijo to sliko in potrebujejo tri različne popravke: tunel, ki ni preživel mirovanja, profil, ki ga nihče ni prosil za ponovno aktivacijo, ali aplikacija, ki še vedno drži sejo, ki je umrla pred urami. Primerjava je hitrejša od ponovne namestitve česarkoli.

Po prebujenju se lahko pokvarijo tri stvari

Prvi kandidat je tunel sam. Vmesnik lahko še obstaja z naslovom, medtem ko je povezava z vrstnikom izginila, zato indikatorska lučka ni dokaz delujoče poti. Rokovanje, starejše od mirovanja, je znak, in za ogled zadostuje en ukaz.

Drugi je aktivacija. Mnogi odjemalci se ponovno povežejo sami; nekateri ne, in profil, ki ga nihče ne prosi za vrnitev, tam samo sedi in je videti konfiguriran. Ta odpoved je tiho po zasnovi, ker nič ni sporočilo napake.

Tretja je aplikacija. Zavihek brskalnika, seja SSH ali povezava z bazo lahko preživijo spremembo omrežja kot deskriptor datoteke, medtem ko je promet pod njimi mrtev. Nova seja nato deluje brezhibno, kar vam pove, da je bil tunel ves čas v redu.

Primerjajte vse tri, preden karkoli spremenite, ker se popravki ne prekrivajo. Ponovni zagon odjemalca, ki ni bil nikoli pozvan k ponovnemu zagonu, zapravi dokaz, ki ste ga potrebovali. Preden se dotaknete konfiguracije, zapišite, kateremu kandidatu ustreza simptom. Ta en stavek običajno odloči preostanek preiskave.

Najprej: se je tunel vrnil?

Opazujte vmesnik in stanje vrstnika, ne besedila stanja odjemalca. Vmesnik z naslovom in brez nedavnega rokovanja je tunel, ki obstaja samo po imenu.

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

Če vmesnika sploh ni, tunel ni preživel in vprašanje postane, kdo bi ga moral vrniti. Če obstaja, a je rokovanje staro, je treba povezavo z vrstnikom ponovno vzpostaviti, odjemalec pa morda čaka na promet, ki jo bo sprožil.

Preverite tudi poti in konfiguracijo DNS. Tunel se lahko vrne brez svojih poti, kar ustvari zmedeno stanje, ko vmesnik deluje, notranja imena pa se še vedno razrešujejo prek napačnega strežnika.

Drugič: je kaj zahtevalo njegovo vrnitev?

Tu se primerjava obrestuje. NetworkManager obravnava profil vtičnika OpenVPN in izvorno povezavo WireGuard različno, referenca za nastavitve povezave pa jasno navaja, da connection.autoconnect ne aktivira profilov VPN; mehanizem za dvig VPN skupaj s povezavo je connection.secondaries.

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

Če ročna ponovna povezava težavo vsakič odpravi, je to podpis manjkajoče aktivacije in ne pokvarjenega tunela. Dnevnik običajno pokaže, kako vmesnik pade in nič ga ne vrne.

Uprite se želji, da bi takoj dodali kavelj za mirovanje. Kavelj, ki se sproži, preden si omrežje opomore, tekmuje s prav tistim procesom, ki mu želi pomagati, in iz ponovljive težave naredi občasno.

Tretjič: ali aplikacija drži staro stanje?

Preden se dotaknete VPN, odprite povsem novo sejo na isti cilj. Če nova seja deluje in stara ne, je tunel v redu, aplikacija pa drži mrtvo povezavo.

To je najcenejša od treh preverjanj in tista, ki se najpogosteje preskoči, ker je okno, ki odpove, prav na zaslonu. Zaprite ga, odprite znova in zabeležite, ali težava ostane. Če nova seja deluje, preiskavo tunela povsem ustavite. Če tudi ta odpove, je aplikacija simptom in ne vzrok.

Nekatere aplikacije se po poteku časa same poberejo, zato je lahko videti, kot da se simptom po nekaj minutah sam popravi. Takšno vedenje kaže na aplikacijo in ne na tunel, in vredno ga je zabeležiti ločeno. Kolega, ki pravi, da se je samo popravilo, opisuje ta vzorec in ne sreče.

Naredite primerjavo ponovljivo

Spremenljivke naj bodo majhne: eno dostopno omrežje, eno trajanje mirovanja in vsakič ista prva zahteva. Nato zabeležite dva izida: ali ročna ponovna povezava to popravi in ali nadaljnje mirovanje prinese odpoved nazaj.

Prav zadnje opažanje najbolj zanesljivo loči tri kandidate. Delujoča nova seja po neuspešni stari ni težava tunela in nobena ponovna namestitev odjemalca tega ne bo spremenila.

Trajni keepalive WireGuarda sodi v to sliko samo kot keepalive preslikave NAT. Pošilja pakete, da ohrani preslikavo odprto; ne prepreči stroju, da zaspi, in ne more nadaljevati s pošiljanjem, dokler je proces ustavljen.

V zahtevku zapišite, kaj ste našli: katera od treh stvari je bila pokvarjena, kaj jo je popravilo in kako ste to ponovili. Naslednja oseba, ki bo v ponedeljek odprla pokrov, se vam bo zahvalila, odgovora pa ne bo treba znova odkrivati od začetka.