Hvorfor dør OpenVPN, når bærbaren vågner?

Dvale kan dræbe OpenVPN-sessionen og efterlade tun0. Test tunnelen, og genstart derefter tjenesten fra et sleep-hook i systemd, ikke netværksenheden.

Send maskinen i dvale, væk den, og kontrollér derefter tre ting i denne rækkefølge, før du rører ved nogen konfiguration: om tun0 stadig findes, om ruten til en intern adresse stadig vælger den, og om serveren stadig lister denne peer. En enhed, der overlever dvale, mens ruten peger et andet sted hen, er en rest, ikke en tunnel. Når ruten er rigtig, og trafikken alligevel dør, sidder fejlen over tunnelen, og en genstart af klienten ændrer det ikke. At automatisere en genstart giver først mening, efter at en manuel test har vist, hvilket af de tre tilfælde du har.

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

Genskab opvågningen, før du automatiserer den

Dvale afslutter oftere den krypterede session, end den fjerner enheden. Den UDP-strøm, der holdt tunnelen i live, stopper, serveren kan droppe peer'en, og klienten opdager det enten og genopretter forbindelsen eller beholder et interface uden noget bag sig. Et interface-tjek alene beviser lidt, fordi en forældet enhed ser præcis ud som en fungerende indtil pakker skal passere igennem den. Kør ruteopslaget plus én rigtig forespørgsel gennem tunnelen, og læs derefter journalen omkring opvågningsøjeblikket.

Hvis klienten kommer tilbage af sig selv, tilføjer et hook ekstra besvær i stedet for pålidelighed. Hvis den aldrig kommer sig, er automatisering den ærlige løsning.

Hvor et sleep-hook i systemd faktisk bor

Mange ældre vejledninger peger på /etc/pm/sleep.d, en mappe, der ejes af pm-utils og aldrig konsulteres af en systemd-baseret dvale. systemd læser hooks fra /usr/lib/systemd/system-sleep/ og /etc/systemd/system-sleep/, giver fasen først og operationen som andet argument, så pre og post er de eneste værdier, et hook forgrener sig på. Behold den lokale kopi under /etc i stedet for at redigere en pakket fil, og husk, at scriptet kører som root midt i overgangen, så det skal vende hurtigt tilbage.

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

try-restart rører kun ved en enhed, når den allerede er aktiv, så en tunnel, du selv har lukket, forbliver lukket gennem opvågningen. --no-block forhindrer hooket i at vente, mens klienten forhandler, hvilket betyder noget, når netværket endnu ikke er oppe. Sammen betyder de to flag et hook, der fejler stille i stedet for at holde hele opvågningssekvensen tilbage. Der sker slet ingenting, når enheden allerede er stoppet, og det er præcis det resultat, du ønsker der.

Genopret tjenesten, lad tun0 være

Tager du tun0 ned i hånden, efterlades daemonen med at overvåge et interface, den ikke længere ejer, og den næste tilstandændring giver forvirrende fejl. Ret dig mod tjenesten eller dens forbindelsesprofil i stedet for interfacet; tjek det præcise enhedsnavn først, fordi distributionspakker, OpenVPN 3 og NetworkManager alle vælger forskellige. En NetworkManager-profil vender tilbage, når den forbindelse cykles, så systemd-enheden er ikke målet der. Uanset mekanismen bør det være den samme handling, du har verificeret i hånden.

En genstart geninstallerer de ruter, klienten lagde ind, da den oprettede forbindelsen. De fleste opvågninger vil have det. En maskine, hvor du selv har tilføjet ruter, vil ikke, så tjek dem igen i stedet for at antage, at gendannelsen har lagt dem tilbage, og skriv dem ned, hvor den næste opvågning kan finde dem.

Håndtér den timing, du ikke styrer

Trådløs association og DHCP bliver ofte færdige, efter at hooket har kørt, så en genstart kan fejle, mens der endnu ikke er nogen vej til serveren. Vent kort på den adresse, prøv én gang mere, og log resultatet.

Navneopløsning er et selvstændigt kapløb, fordi skrivebordets netværksstack kan gendanne DNS, efter at tunnelen allerede er oppe. Test opslag alene med resolvectl query internal.example i stedet for at udlede dem af en fungerende rute. En tunnel, der router korrekt og ikke opløser noget, er et DNS-problem, ikke et hook-problem.

Hold hookets beslutning synlig ved at skrive fasen, enhedsnavnet og resultatet i journalen. Notér i maskinens noter, hvilken opvågningstest du kørte, så en fungerende gendannelse kan skelnes fra en heldig. Vælg den mindst indgribende handling, der bringer tjenesten tilbage, og lad en klient, der kommer sig selv, gøre det. En fuld genstart dropper igangværende sessioner, og det er en reel omkostning på en bærbar, der vågner flere gange om dagen.

Relaterede artikler