Zakaj OpenVPN umre po prebujanju prenosnika?

Spanje lahko ubije sejo OpenVPN in pusti tun0. Preizkusite tunel, nato znova zaženite enoto iz kaveljčka spanja systemd, ne naprave.

Uspavajte stroj, prebudite ga in nato v tem vrstnem redu preverite tri stvari, preden se dotaknete katere koli konfiguracije: ali tun0 še obstaja, ali pot do notranjega naslova še vedno izbere njega in ali strežnik še vedno navaja tega peerja. Naprava, ki spanje preživi, medtem ko pot kaže drugam, je ostanek, ne tunel. Ko je pot pravilna in promet vseeno umre, je napaka nad tunelom in ponovni zagon odjemalca tega ne bo spremenil. Avtomatizacija ponovnega zagona je smiselna šele potem, ko je ročni preizkus pokazal, kateri od teh treh primerov je vaš.

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

Ponovite prebujanje, preden ga avtomatizirate

Spanje pogosteje konča šifrirano sejo, kot odstrani napravo. Tok UDP, ki je držal tunel pri življenju, se ustavi, strežnik lahko spusti peerja in odjemalec bodisi to opazi in se znova poveže bodisi obdrži vmesnik, za katerim ni ničesar. Preverjanje vmesnika samo po sebi dokaže malo, ker zastarela naprava je videti natanko kot delujoča dokler morajo paketi iti skoznjo. Zaženite iskanje poti in eno resnično zahtevo skozi tunel, nato preberite dnevnik okoli trenutka prebujanja.

Če se odjemalec vrne sam, kaveljček doda nemir namesto zanesljivosti. Če si nikoli ne opomore, je avtomatizacija poštena rešitev.

Kje v resnici živi kaveljček spanja systemd

Številni starejši priročniki kažejo na /etc/pm/sleep.d, imenik, ki ga ima v lasti pm-utils in ki ga spanje, zasnovano na systemd, nikoli ne posvetuje. systemd bere kaveljčke iz /usr/lib/systemd/system-sleep/ in /etc/systemd/system-sleep/, najprej posreduje fazo in nato operacijo, zato sta pre in post edini vrednosti, po katerih se kaveljček razveja. Hranite lokalno kopijo pod /etc, namesto da bi urejali pakirano datoteko, in zapomnite si, da skript teče kot root sredi prehoda, zato se mora hitro vrniti.

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

try-restart se enote dotakne le, ko je že aktivna, zato tunel, ki ste ga namenoma izklopili, ostane izklopljen tudi med prebujanjem. --no-block prepreči, da bi kaveljček čakal, medtem ko se odjemalec pogaja, kar je pomembno, ko omrežje še ni dvignjeno. Skupaj obe zastavici pomenita kaveljček, ki tiho spodleti, namesto da bi zadrževal celotno zaporedje prebujanja. Ko je enota že ustavljena, se ne zgodi popolnoma nič, in to je natanko rezultat, ki ga tam želite.

Obnovite storitev, pustite tun0 pri miru

Ročno spuščanje tun0 pusti demona, da nadzoruje vmesnik, ki ga ne poseduje več, in naslednja sprememba stanja ustvari zmedene napake. Ciljajte na storitev ali njen profil povezave, ne na vmesnik; najprej preverite točno ime enote, ker distribucijski paketi, OpenVPN 3 in NetworkManager vsi izberejo drugačne. Profil NetworkManager se vrne, ko se ta povezava reciklira, zato systemd enota tam ni cilj. Karkoli je mehanizem, to bi moralo biti isto dejanje, ki ste ga preverili ročno.

Ponovni zagon znova namesti poti, ki jih je odjemalec potisnil ob povezavi. Večina prebujanj to želi. Stroj, kjer ste dodali svoje poti, ne, zato jih znova preverite, namesto da bi predpostavili, da jih je obnovitev vrnila, in jih zapišite tam, kjer jih bo naslednje prebujanje lahko našlo.

Ukvarjajte se s časovnim usklajevanjem, ki ga ne morete nadzorovati

Brezžična povezava in DHCP se pogosto končata šele potem, ko je kaveljček že tekel, zato lahko ponovni zagon spodleti, medtem ko pot do strežnika še ne obstaja. Malo počakajte na ta naslov, poskusite še enkrat in zabeležite rezultat.

Razreševanje imen je ločena tekma, ker lahko omrežni sklad namizja obnovi DNS šele potem, ko je tunel že dvignjen. Preizkuse poizvedb izvedite ločeno s resolvectl query internal.example, namesto da bi jih sklepali iz delujoče poti. Tunel, ki pravilno usmerja in ničesar ne razreši, je težava DNS, ne težava kaveljčka.

Odločitev kaveljčka ohranite vidno tako, da v dnevnik zapišete fazo, ime enote in rezultat. V zapiskih stroja zabeležite, kateri preizkus prebujanja ste izvedli, da bo delujočo obnovitev mogoče ločiti od srečne. Izberite najmanj moteče dejanje, ki vrne storitev, in pustite odjemalcu, ki si opomore sam, da to stori. Popoln ponovni zagon zavrže seje v teku, kar je resničen strošek na prenosniku, ki se prebuja večkrat na dan.

Sorodni članki