VPN miręs po miego: prarastas tunelis ar pasenusi programa?

Dangtis atsidaro, belaidžio ryšio piktograma grįžta, o VPN vis dar rodoma kaip prisijungusi. Tada pirmasis vidinis puslapis stringa, kol baigiasi laikas, ir nauja kortelė elgiasi taip pat. Šį vaizdą gali sukurti trys skirtingi dalykai, ir jiems reikia trijų skirtingų taisymų: tunelio, kuris neišgyveno miego, profilio, kurio niekas neprašė vėl aktyvuoti, arba programos, kuri vis dar laiko sesiją, mirusią prieš kelias valandas. Juos palyginti greičiau nei ką nors perinstaliuoti.

Po pabudimo gali sugesti trys dalykai

Pirmasis kandidatas yra pats tunelis. Sąsaja gali dar egzistuoti su adresu, nors ryšys su partneriu dingo, todėl indikatoriaus lemputė nėra veikiančio kelio įrodymas. Senesnis už miegą rankos paspaudimas yra ženklas, ir jam pamatyti pakanka vienos komandos.

Antrasis yra aktyvavimas. Daugelis klientų prisijungia iš naujo patys; kai kurie ne, o profilis, kurio niekas neprašo grįžti, tiesiog stovi ir atrodo sukonfigūruotas. Ta nesėkmė tyli iš prigimties, nes niekas negrąžino klaidos.

Trečiasis yra programa. Naršyklės kortelė, SSH sesija ar duomenų bazės ryšys gali išgyventi tinklo pokytį kaip failo deskriptorius, nors transportas po jais yra miręs. Tada nauja sesija veikia nepriekaištingai, o tai sako, kad tunelis visą laiką buvo tvarkingas.

Palyginkite tris prieš ką nors keisdami, nes taisymai nesutampa. Kliento, kurio niekas niekada neprašė paleisti iš naujo, perkrovimas iššvaisto jums reikalingus įrodymus. Užsirašykite, kurį kandidatą atitinka simptomas, prieš liesdami konfigūraciją. Tas vienas sakinys dažniausiai nulemia likusį tyrimą.

Pirma: ar tunelis grįžo?

Žiūrėkite į sąsają ir partnerio būseną, o ne į kliento statuso tekstą. Sąsaja su adresu ir be naujo rankos paspaudimo yra tunelis, kuris egzistuoja tik pavadinimu.

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

Jei sąsajos visai nėra, tunelis neišgyveno ir kyla klausimas, kas turėjo jį sugrąžinti. Jei ji yra, bet rankos paspaudimas senas, ryšį su partneriu reikia atkurti, o klientas galbūt laukia srauto, kuris jį suaktyvins.

Patikrinkite ir maršrutus bei DNS konfigūraciją. Tunelis gali grįžti be savo maršrutų, o tai sukuria painią būseną, kai sąsaja veikia, o vidiniai vardai vis dar sprendžiami per netinkamą serverį.

Antra: ar kas nors paprašė jo grįžti?

Štai čia palyginimas atsiperka. NetworkManager skirtingai tvarko OpenVPN įskiepio profilį ir vietinį WireGuard ryšį, o ryšio nustatymų nuoroda aiškiai nurodo, kad connection.autoconnect neaktyvuoja VPN profilių; VPN iškėlimo kartu su ryšiu mechanizmas yra connection.secondaries.

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

Jei rankinis prisijungimas iš naujo problemą sutvarko kiekvieną kartą, tai yra trūkstamo aktyvavimo, o ne sugedusio tunelio požymis. Žurnalas paprastai parodys, kaip sąsaja krenta ir niekas jos negrąžina.

Atsispirkite impulsui iš karto pridėti miego kabliuką. Kabliukas, suveikiantis prieš tinklui atsigaunant, lenktyniauja su tuo pačiu procesu, kuriam bando padėti, ir paverčia atkuriamą problemą pasitaikančia.

Trečia: ar programa laiko seną būseną?

Prieš liesdami VPN atidarykite visiškai naują sesiją tam pačiam tikslui. Jei nauja sesija veikia, o senoji ne, tunelis tvarkingas, o programa laiko negyvą ryšį.

Tai pigiausias iš trijų patikrinimų ir dažniausiai praleidžiamas, nes nepavykstantis langas yra tiesiai ekrane. Uždarykite jį, atidarykite iš naujo ir pažymėkite, ar problema išlieka. Jei nauja sesija veikia, visiškai sustabdykite tunelio tyrimą. Jei ji irgi nepavyksta, programa yra simptomas, o ne priežastis.

Kai kurios programos po laiko limito atsigauna pačios, todėl simptomas gali atrodyti pasitaisęs po kelių minučių. Toks elgesys rodo į programą, o ne į tunelį, ir verta tai užrašyti atskirai. Kolega, kuris sako, kad tai tiesiog pati pasitaisė, aprašo šį modelį, o ne sėkmę.

Padarykite palyginimą atkuriamą

Laikykite kintamuosius mažus: vienas prieigos tinklas, viena miego trukmė ir ta pati pirmoji užklausa kiekvieną kartą. Tada užregistruokite du rezultatus: ar rankinis prisijungimas iš naujo tai sutvarko, ir ar dar vienas miegas sugrąžina gedimą.

Būtent paskutinis stebėjimas patikimiausiai atskiria tris kandidatus. Veikianti nauja sesija po nepavykusios senos nėra tunelio problema, ir joks kliento perinstaliavimas to nepakeis.

WireGuard nuolatinis keepalive šiame paveiksle tinka tik kaip NAT susiejimo keepalive. Jis siunčia paketus, kad susiejimas liktų atviras; jis netrukdo mašinai užmigti ir negali toliau siųsti, kol procesas sustabdytas.

Įrašykite į bilietą, ką radote: kuris iš trijų buvo sugedęs, kas jį sutvarkė ir kaip atkūrėte. Kitas žmogus, pirmadienį atidarysiantis dangtį, jums padėkos, ir atsakymo nereikės atrasti iš naujo.