Kvifor døyr OpenVPN etter at den bærbare vaknar?

Set maskina i dvale, vekk ho, og sjekk deretter tre ting i denne rekkjefølgja før du rører nokon konfigurasjon: om tun0 framleis finst, om ruta til ein intern adresse framleis vel ho, og om serveren framleis listar denne peer-en. Ei eining som overlever dvale medan ruta peikar ein annan stad, er ein rest, ikkje ein tunnel. Når ruta er rett og trafikken likevel døyr, sit feilen over tunnelen, og ein omstart av klienten endrar ikkje det. Det er berre meiningsfullt å automatisere ein omstart etter at ein manuell test har vist kva av dei tre tilfella du har.

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

Reproduser oppvakninga før du automatiserer ho

Dvale avsluttar oftare den krypterte økta enn ho fjernar eininga. UDP-straumen som heldt tunnelen i live, stoppar, serveren kan droppe peer-en, og klienten antingen merkar det og koplar til på nytt eller held på eit grensesnitt utan noko bak seg. Ein grensesnittsjekk åleine beviser lite, fordi eit forelda eining ser nøyaktig ut som ei som verkar heilt til pakkar må passere gjennom ho. Køyr ruteoppslaget pluss éin reell førespurnad gjennom tunnelen, og les deretter journalen rundt oppvakningsaugneblinken.

Viss klienten kjem tilbake av seg sjølv, gir ein hook ekstra mas i staden for pålitelegheit. Viss han aldri kjem seg, er automatisering den ærlege løysinga.

Kvar ein systemd-dvalehook faktisk bur

Mange eldre rettleiarar peikar på /etc/pm/sleep.d, ein katalog som pm-utils eig og som dvale basert på systemd aldri konsulterer. systemd les hooks frå /usr/lib/systemd/system-sleep/ og /etc/systemd/system-sleep/, og gir fasen først og operasjonen som andre argument, så pre og post er dei einaste verdiane ein hook forgreinar seg på. Hald den lokale kopien under /etc i staden for å redigere ei pakka fil, og hugs at skriptet køyrer som root midt i overgangen, så det må returnere raskt.

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

try-restart rører berre ei eining når ho allereie er aktiv, så ein tunnel du bevisst har slått av, blir verande av gjennom oppvakninga. --no-block hindrar hooken i å vente medan klienten forhandlar, noko som betyr noko når nettverket enno ikkje er oppe. Saman betyr dei to flagga ein hook som feilar stille i staden for å halde heile oppvakningssekvensen tilbake. Når eininga allereie er stoppa, skjer ingenting i det heile, og det er nøyaktig resultatet du ønskjer der.

Gjenopprett tenesta, lat tun0 vere

Tar du tun0 ned for hand, står daemonen att og overvakar eit grensesnitt han ikkje lenger eig, og neste tilstandsendring gir forvirrande feil. Rett deg mot tenesta eller tilkoplinga sin profil i staden for grensesnittet; sjekk det nøyaktige einingnamnet først, fordi distribusjonspakkar, OpenVPN 3 og NetworkManager vel alle forskjellige. Ein NetworkManager-profil kjem tilbake når den tilkoplinga blir resirkulert, så systemd-eininga er ikkje målet der. Uansett mekanisme bør det vere den same handlinga du verifiserte for hand.

Ein omstart installerer på nytt rutene klienten pusja då han kopla til. Dei fleste oppvakningar vil ha det. Ei maskin der du har lagt til eigne ruter vil ikkje, så sjekk dei på nytt i staden for å anta at gjenopprettinga la dei tilbake, og skriv dei ned der neste oppvakning kan finne dei.

Handter timinga du ikkje kontrollerer

Trådlaus tilkopling og DHCP blir ofte ferdige etter at hooken har køyrt, så ein omstart kan mislykkast medan det enno ikkje finst nokon veg til serveren. Vent kort på den adressa, prøv éin gong til og logg resultatet.

Namneoppslag er eit eige kapplaup, fordi nettverksstakken på skrivebordet kan gjenopprette DNS etter at tunnelen allereie er oppe. Test oppslaga for seg med resolvectl query internal.example i staden for å utleie dei frå ei fungerande rute. Ein tunnel som rutar rett og ikkje løyser opp noko, er eit DNS-problem, ikkje eit hook-problem.

Hald avgjerda til hooken synleg ved å skrive fasen, einingnamnet og resultatet i journalen. Noter i maskinnotata kva oppvakningstest du køyrde, slik at ei fungerande gjenoppretting kan skiljast frå ei heldig. Vel den minst forstyrrande handlinga som får tenesta tilbake, og lat ein klient som kjem seg av seg sjølv gjere det. Ein full omstart droppar økter som pågår, noko som er ein reell kostnad på ein bærbar som vaknar fleire gonger om dagen.