VPN surnud pärast unerežiimi: kadunud tunnel või vananenud rakendus?

Kaas avaneb, traadita võrgu ikoon tuleb tagasi ja VPN näitab endiselt ühendatud olekut. Seejärel jääb esimene sisemine leht rippuma, kuni aegub, ja uus vahekaart teeb sama. Selle pildi võivad tekitada kolm erinevat asja ja need vajavad kolme erinevat parandust: tunnel, mis ei elanud unerežiimi üle, profiil, mida keegi ei palunud uuesti aktiveerida, või rakendus, mis hoiab veel sessiooni, mis suri tunde tagasi. Nende võrdlemine on kiirem kui millegi ümberpaigaldamine.

Pärast ärkamist võib katki olla kolm asja

Esimene kandidaat on tunnel ise. Liides võib veel aadressiga olemas olla, samal ajal kui side partneriga on kadunud, seepärast ei ole indikaatorituli tõestus toimivast teest. Unerežiimist vanem kätlemine on märk ja selle nägemiseks piisab ühest käsust.

Teine on aktiveerimine. Paljud kliendid ühendavad end ise uuesti; mõned mitte, ja profiil, mida keegi tagasi tulema ei kutsu, jääb lihtsalt seisma ja näeb seadistatud välja. See tõrge on disaini järgi vaikne, sest miski ei andnud viga.

Kolmas on rakendus. Brauseri vahekaart, SSH-sessioon või andmebaasiühendus võivad võrguvahetuse üle elada failideskriptorina, samal ajal kui transport nende all on surnud. Siis töötab uus sessioon laitmatult, mis ütleb teile, et tunnel oli kogu aeg korras.

Võrrelge kolme enne, kui midagi muudate, sest parandused ei kattu. Kliendi taaskäivitamine, mida ei palutud kunagi uuesti käivitada, raiskab tõendi, mida vajasite. Kirjutage üles, millisele kandidaadile sümptom sobib, enne kui seadistust puudutate. See üks lause otsustab tavaliselt ülejäänud uurimise.

Esiteks: kas tunnel tuli tagasi?

Vaadake liidest ja partneri olekut, mitte kliendi enda olekuteksti. Liides, millel on aadress ja millel pole värsket kätlemist, on tunnel, mis on ainult nime poolest üleval.

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

Kui liidest pole üldse, ei elanud tunnel üle ja küsimuseks saab, kes oleks pidanud selle tagasi tooma. Kui see on olemas, aga kätlemine on vana, tuleb side partneriga uuesti luua ja klient võib oodata liiklust, mis selle käivitab.

Kontrollige ka marsruute ja DNS-i seadistust. Tunnel võib naasta ilma oma marsruutideta, mis tekitab segadust tekitava oleku, kus liides on üleval ja sisemised nimed lahendatakse endiselt vale serveri kaudu.

Teiseks: kas keegi palus sellel tagasi tulla?

Siin võrdlus end ära tasub. OpenVPN pistikprogrammi profiili ja kohalikku WireGuard-ühendust käsitleb NetworkManager erinevalt ning ühenduse seadete viide ütleb selgelt, et connection.autoconnect ei aktiveeri VPN-profiile; mehhanism VPN-i ühendusega üles tõstmiseks on connection.secondaries.

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

Kui käsitsi uuesti ühendamine parandab probleemi iga kord, on see puuduva aktiveerimise, mitte katkise tunneli tunnus. Logi näitab tavaliselt, kuidas liides alla läheb ja miski ei too seda tagasi.

Vastustage kiusatusele lisada kohe unehook. Hook, mis käivitub enne, kui võrk on taastunud, võistleb sama protsessiga, mida ta aidata püüab, ja muudab korratava probleemi aeg-ajalt esinevaks.

Kolmandaks: kas rakendus hoiab vana olekut?

Avage täiesti uus sessioon samasse sihtkohta enne, kui VPN-i puudutate. Kui uus sessioon töötab ja vana mitte, on tunnel korras ja rakendus hoiab surnud ühendust.

See on kolmest kontrollist odavaim ja kõige sagedamini vahele jäetud, sest tõrkuv aken on otse ekraanil. Sulgege see, avage uuesti ja pange tähele, kas probleem jääb püsima. Kui uus sessioon töötab, lõpetage tunneli uurimine täielikult. Kui ka see ebaõnnestub, on rakendus sümptom, mitte põhjus.

Mõned rakendused taastuvad ise pärast aegumist, seepärast võib sümptom näida mõne minuti pärast ise paranevat. Selline käitumine osutab rakendusele, mitte tunnelile, ja seda tasub eraldi üles märkida. Kolleeg, kes ütleb, et see paranes lihtsalt ise, kirjeldab seda mustrit, mitte õnne.

Tehke võrdlus korratavaks

Hoidke muutujad väikesed: üks juurdepääsuvõrk, üks unerežiimi kestus ja iga kord sama esimene päring. Seejärel kirjutage üles kaks tulemust: kas käsitsi uuesti ühendamine parandab selle ja kas veel üks unerežiim toob tõrke tagasi.

Just viimane tähelepanek eristab kolme kandidaati kõige usaldusväärsemalt. Töötav uus sessioon pärast ebaõnnestunud vana ei ole tunneli probleem ja ükski kliendi ümberpaigaldus ei muuda seda.

WireGuardi püsiv keepalive kuulub siia pilti ainult NAT-i vastenduse keepalive-na. See saadab pakette, et hoida vastendust avatuna; see ei takista masinal uinumast ega saa jätkata saatmist, kui protsess on peatatud.

Kirjutage piletisse, mida leidsite: milline kolmest oli katki, mis selle parandas ja kuidas te seda korrate. Järgmine inimene, kes esmaspäeval kaane avab, tänab teid ja vastust ei pea nullist uuesti avastama.