Hvorfor dør OpenVPN etter at laptopen våkner?

Dvale kan drepe OpenVPN-økten mens tun0 blir igjen. Test tunnelen, og start deretter enheten på nytt fra en systemd-dvalehook, ikke fra enheten.

Sett maskinen i dvale, vekk den, og sjekk deretter tre ting i denne rekkefølgen før du rører noen konfigurasjon: om tun0 fortsatt finnes, om ruten til en intern adresse fortsatt velger den, og om serveren fortsatt lister denne peer-en. En enhet som overlever dvale mens ruten peker et annet sted, er en rest, ikke en tunnel. Når ruten er riktig og trafikken likevel dør, sitter feilen over tunnelen, og en omstart av klienten endrer ikke det. Det er bare meningsfullt å automatisere en omstart etter at en manuell test har vist hvilket av de tre tilfellene 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 oppvåkningen før du automatiserer den

Dvale avslutter oftere den krypterte økten enn den fjerner enheten. UDP-strømmen som holdt tunnelen i live, stopper, serveren kan droppe peer-en, og klienten enten merker det og kobler til på nytt eller beholder et grensesnitt uten noe bak seg. En grensesnittsjekk alene beviser lite, fordi en foreldet enhet ser nøyaktig ut som en som virker helt til pakker må passere gjennom den. Kjør ruteoppslaget pluss én reell forespørsel gjennom tunnelen, og les deretter journalen rundt oppvåkningsøyeblikket.

Hvis klienten kommer tilbake av seg selv, gir en hook ekstra mas i stedet for pålitelighet. Hvis den aldri kommer seg, er automatisering den ærlige løsningen.

Hvor en systemd-dvalehook faktisk bor

Mange eldre veiledninger peker på /etc/pm/sleep.d, en katalog som eies av pm-utils og aldri konsulteres av dvale basert på systemd. systemd leser hooks fra /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 de eneste verdiene en hook forgrener seg på. Behold den lokale kopien under /etc i stedet for å redigere en pakket fil, og husk at skriptet kjører 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 berører bare en enhet når den allerede er aktiv, så en tunnel du bevisst har slått av, forblir av gjennom oppvåkningen. --no-block hindrer hooken i å vente mens klienten forhandler, noe som betyr noe når nettverket ennå ikke er oppe. Sammen betyr de to flaggene en hook som feiler stille i stedet for å holde hele oppvåkningssekvensen tilbake. Når enheten allerede er stoppet, skjer ingenting i det hele tatt, og det er nøyaktig resultatet du ønsker der.

Gjenopprett tjenesten, la tun0 være

Tar du tun0 ned for hånd, står daemonen igjen og overvåker et grensesnitt den ikke lenger eier, og neste tilstandsendring gir forvirrende feil. Rett deg mot tjenesten eller tilkoblingsprofilen i stedet for grensesnittet; sjekk det nøyaktige enhetsnavnet først, fordi distribusjonspakker, OpenVPN 3 og NetworkManager velger alle forskjellige. En NetworkManager-profil kommer tilbake når den tilkoblingen resirkuleres, så systemd-enheten er ikke målet der. Uansett mekanisme bør det være den samme handlingen du verifiserte for hånd.

En omstart installerer på nytt rutene klienten pushet da den koblet til. De fleste oppvåkninger vil ha det. En maskin der du har lagt til egne ruter vil ikke, så sjekk dem på nytt i stedet for å anta at gjenopprettingen la dem tilbake, og skriv dem ned der neste oppvåkning kan finne dem.

Håndter timingen du ikke kontrollerer

Trådløs tilkobling og DHCP blir ofte ferdige etter at hooken har kjørt, så en omstart kan mislykkes mens det ennå ikke finnes noen vei til serveren. Vent kort på den adressen, prøv én gang til og logg resultatet.

Navneoppslag er et eget kappløp, fordi nettverksstakken på skrivebordet kan gjenopprette DNS etter at tunnelen allerede er oppe. Test oppslagene for seg med resolvectl query internal.example i stedet for å utlede dem fra en fungerende rute. En tunnel som ruter riktig og ikke løser opp noe, er et DNS-problem, ikke et hook-problem.

Hold hookens beslutning synlig ved å skrive fasen, enhetsnavnet og resultatet i journalen. Noter i maskinnotatene hvilken oppvåkningstest du kjørte, slik at en fungerende gjenoppretting kan skilles fra en heldig. Velg den minst forstyrrende handlingen som får tjenesten tilbake, og la en klient som kommer seg av seg selv gjøre det. En full omstart dropper økter som pågår, noe som er en reell kostnad på en laptop som våkner flere ganger om dagen.

Relaterte artikler