Kodėl jūsų OpenVPN klientas lieka išjungtas po vieno laiko limito

Pirmadienio rytas: penktadienį pakilęs tunelis dingo, sąsaja vis dar sąraše, o žurnale nieko nerašoma, kad kas nors tai pastebėjo. Priegloba prisijungusi, skydelis žalias, o viskas, ką ji išsiuntė per savaitgalį, išėjo per fizinę sąsają. Čia trūksta dviejų nepriklausomų sprendimų: vieno apie tai, ar kliento procesas išgyvena laikiną gedimą, ir kito apie tai, ar kažkas virš jo vėl paleidžia procesą po jo pasitraukimo. Pataisius tik vieną, kita spraga lieka atvira.

Pradėkite nuo to, ką įrenginys iš tikrųjų padarė, o ne nuo to, ką teigia stebėjimas. systemctl status openvpn-client@office ir journalctl -u openvpn-client@office -n 50 rodo pasitraukimo priežastį ir paskutinę eilutę, kurią klientas įrašė prieš išeidamas.

Procesas pasitraukė anksčiau, nei kas nors pastebėjo

Klientas, kuris dingsta be klaidos, paprastai pasitraukė tyčia. Šį elgesį lemia profilis, o ne paslaugų tvarkyklė: ping-exit baigia procesą vos tik kita pusė nustoja atsakinėti, o ping-restart palieka procesą ir iš naujo prisijungia jo viduje. Sesijos limitai ir neveiklumo laikmačiai iš išorės sukuria tą patį vaizdą: be tunelio ir be aliarmo.

Dvi ping direktyvos negali būti kartu viename profilyje, todėl pasirinkite vieną ir užrašykite pasirinkimą. Pažiūrėkite ir į serverį, nes jo paties ping-exit uždaro sesiją nepriklausomai nuo to, ko paprašė klientas, ir tik serverio žurnalas užrašo, kas priėmė tą sprendimą.

Pasirinkimas tarp ping-exit ir ping-restart

Pasirinkite ping-restart nešiojamajam kompiuteriui ar atokiai vietai, kuri turi pati pasveikti, o ping-exit palikite atvejams, kai negyvas tunelis turi sustabdyti procesą, kad kažkas kitas galėtų į jį reaguoti. Skaičiai mažiau svarbūs nei ryšys: ping 10 su ping-restart 60 reiškia dešimt sekundžių tylos prieš patikrinimą ir šešiasdešimt prieš paleidimą iš naujo, o tai agresyvu nuostolingame mobiliajame ryšyje ir pagrįsta laidiniame. Užrašykite priežastį prie eilutės, nes kitaip kitas skaitytojas manys, kad numatytosios reikšmės buvo sąmoningos.

Tada patvirtinkite, kad pasitraukė būtent procesas. Įrenginys, kuris praneša apie aktyvumą, kai tunelis negyvas, yra kitas gedimas, nagrinėjamas toliau.

Priežiūra, kuri iš tiesų paleidžia įrenginį iš naujo

systemd priegloboje mažiausias ilgalaikis pakeitimas yra vienas drop-in failas: Restart=on-failure ir RestartSec=10 faile /etc/systemd/system/[email protected]/restart.conf. Drop-in skaitomas tik tada, kai systemd iš naujo įkelia savo apibrėžimus, todėl po to paleiskite systemctl daemon-reload. Patikrinkite su systemctl show -p Restart -p ExecMainStatus openvpn-client@office, o ne manykite, kad reikšmė atkeliavo. Failo pavadinime esantis egzempliorius turi būti profilis, kurį įrenginys iš tikrųjų įkelia, todėl failas, parašytas office, nieko nedaro openvpn-client@home.

on-failure ignoruoja vieną atvejį: švarų pasitraukimą su nuline būsena. Kai kurie išardymo keliai taip baigiasi, todėl skaitykite įrašytą būseną, o ne pasitikėkite vadovo puslapio formuluote. Jei jūsų klientas pasiduoda su nuliu, jums reikia Restart=always, o kaina yra tai, kad tikrai sugadintas profilis grįžta vėl ir vėl, kol suveikia paleidimo spartos limitas ir žurnalas prisipildo.

Restart=always suveikia ir po tyčinio sustabdymo. Techninei priežiūrai naudokite systemctl stop, o jei įrenginys turi likti išjungtas, kol dirbate, užmaskuokite jį.

Pagaukite nuotėkį, kol tunelis išjungtas

Priežiūra grąžina tunelį; ji netrukdo srautui išeiti, kol tunelio nėra. persist-tun išlaiko įrenginį ir jo maršrutus tarp pakartotinių prisijungimų, o tai patogu ir atveria langą. Įrenginys išlieka, maršrutai vis dar nukreipti į jį, o paketai išteka neapsaugoti ir nepranešti. Tai politikos pasirinkimas, o ne neutrali numatytoji reikšmė.

Kai priegloba apskritai negali siųsti neapsaugotų paketų, tai gali užtikrinti tik ugniasienė. Išeigos taisyklė, leidžianti tunelio sąsają ir VPN serverio adresą bei atmetanti visa kita, galioja ir po kliento mirties, o kliento konfigūracijoje nieko nėra, kas galėtų filtruoti srautą, kurio klientas neperduoda.

Išbandykite tyčia sustabdę klientą. Paleiskite systemctl stop openvpn-client@office, tada curl -m 5 https://example.com, kuris turėtų nepavykti, o ne pavykti per fizinį ryšį. Sėkmė reiškia, kad ugniasienės taisyklės trūksta arba ji pernelyg leidi.

Prisijunkite iš naujo, patvirtinkite, kad tunelis vėl perduoda srautą, ir tik tada pridėkite patikrinimą prie stebėjimo. ip addr apklausa per cron tun įrenginiui yra priežiūra, kuri nepavyksta dažniausiai, nes su persist-tun įrenginys išgyvena sesiją, o patikra praneša apie sveikatą, kai nieko neperduodama.