Kodėl OpenVPN miršta po to, kai nešiojamasis kompiuteris pabunda?

Miegas gali nužudyti OpenVPN sesiją ir palikti tun0. Išbandykite tunelį, tada iš naujo paleiskite vienetą per systemd miego kabliuką, o ne įrenginį.

Įveskite mašiną į miego režimą, pažadinkite ją, tada, prieš liesdami bet kokią konfigūraciją, šia tvarka patikrinkite tris dalykus: ar tun0 dar egzistuoja, ar maršrutas į vidinį adresą jį dar renkasi ir ar serveris dar išvardija šį peer. Įrenginys, kuris išgyvena miegą, nors maršrutas rodo kitur, yra likutis, o ne tunelis. Kai maršrutas teisingas, o srautas vis tiek miršta, gedimas yra virš tunelio, ir kliento paleidimas iš naujo to nepakeis. Automatizuoti paleidimą iš naujo prasminga tik po to, kai rankinis bandymas parodė, kuris iš šių trijų atvejų yra jūsų.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Atkurkite pabudimą prieš jį automatizuodami

Miegas dažniau užbaigia šifruotą sesiją, nei pašalina įrenginį. UDP srautas, kuris palaikė tunelį gyvą, sustoja, serveris gali numesti peer, o klientas arba tai pastebi ir prisijungia iš naujo, arba palieka sąsają, už kurios nieko nėra. Vien sąsajos patikra mažai ką įrodo, nes pasenęs įrenginys atrodo lygiai taip pat kaip veikiantis kol paketams tenka per jį praeiti. Paleiskite maršruto paiešką ir vieną tikrą užklausą per tunelį, tada perskaitykite žurnalą apie pabudimo momentą.

Jei klientas grįžta pats, kabliukas prideda triukšmo, o ne patikimumo. Jei jis niekada neatsistato, automatizavimas yra sąžiningas sprendimas.

Kur iš tikrųjų gyvena systemd miego kabliukas

Daugelis senesnių vadovų nurodo /etc/pm/sleep.d, katalogą, kuris priklauso pm-utils ir į kurį systemd pagrindu veikiantis miegas niekada nesikreipia. systemd skaito kabliukus iš /usr/lib/systemd/system-sleep/ ir /etc/systemd/system-sleep/, perduodamas pirmiausia fazę, o po to operaciją, todėl pre ir post yra vienintelės reikšmės, pagal kurias kabliukas išsišakoja. Laikykite vietinę kopiją po /etc, o ne redaguokite supakuotą failą, ir atsiminkite, kad scenarijus veikia kaip root perėjimo viduryje, todėl jis turi grįžti greitai.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart paliečia vienetą tik kai jis jau aktyvus, todėl sąmoningai išjungtas tunelis lieka išjungtas per visą pabudimą. --no-block neleidžia kabliukui laukti, kol klientas derasi, o tai svarbu, kai tinklas dar nepakilęs. Abu požymiai kartu reiškia kabliuką, kuris tyliai nepavyksta, o ne sulaiko visą pabudimo seką. Kai vienetas jau sustabdytas, nieko visiškai nevyksta, ir tai yra būtent tas rezultatas, kurio ten norite.

Atkurkite paslaugą, palikite tun0 ramybėje

Nuleidus tun0 ranka, demonas ir toliau prižiūri sąsają, kurios nebevaldo, o kitas būsenos pokytis sukuria painias klaidas. Taikykitės į paslaugą arba jos ryšio profilį, o ne į sąsają; pirmiausia patikrinkite tikslų vieneto pavadinimą, nes platinimo paketai, OpenVPN 3 ir NetworkManager visi renkasi skirtingus. NetworkManager profilis grįžta, kai tas ryšys perjungiamas iš naujo, todėl systemd vienetas ten nėra taikinys. Kad ir koks būtų mechanizmas, tai turėtų būti tas pats veiksmas, kurį patikrinote ranka.

Paleidimas iš naujo iš naujo įdiegia maršrutus, kuriuos klientas įstūmė prisijungdamas. Daugumai pabudimų to reikia. Mašinai, kurioje pridėjote savo kelių, ne, todėl patikrinkite juos iš naujo, o ne manykite, kad atkūrimas juos grąžino, ir užrašykite juos ten, kur kitas pabudimas galės juos rasti.

Tvarkykite laiką, kurio negalite kontroliuoti

Bevielis prisijungimas ir DHCP dažnai baigiasi po to, kai kabliukas jau įvykdytas, todėl paleidimas iš naujo gali nepavykti, kol kelio į serverį dar nėra. Trumpai palaukite to adreso, pabandykite dar kartą ir užregistruokite rezultatą.

Vardų skyrimas yra atskiras lenktyniavimas, nes darbalaukio tinklo stekas gali atkurti DNS po to, kai tunelis jau pakilęs. Tikrinkite užklausas atskirai su resolvectl query internal.example, o ne darykite išvadas iš veikiančio maršruto. Tunelis, kuris teisingai maršrutizuoja ir nieko neišsprendžia, yra DNS problema, o ne kabliuko problema.

Laikykite kabliuko sprendimą matomą įrašydami fazę, vieneto pavadinimą ir rezultatą į žurnalą. Užsirašykite mašinos pastabose, kokį pabudimo testą atlikote, kad veikiantis atkūrimas skirtųsi nuo sėkmingo atsitiktinai. Pasirinkite mažiausiai trikdantį veiksmą, kuris grąžina paslaugą, ir leiskite pačiam atsistatančiam klientui tai padaryti. Visiškas paleidimas iš naujo numeta vykstančias sesijas, o tai yra tikra kaina nešiojamajame kompiuteryje, kuris pabunda kelis kartus per dieną.

Susiję straipsniai