En hvilekrok alene henter ikke VPN-en tilbake

Sett en gjenoppkoblingskommando i hvilekroken, og problemet ser løst ut. Det er bare løst hvis kroken kjører etter at nettverket finnes, som en identitet klienten kjenner igjen, via en vei klienten faktisk implementerer. De fleste feil etter gjenopptak er én av disse tre, og ingen av dem vises som en feil i kroken selv. Kroken returnerer suksess uansett.

Et skript som avslutter med null, har ikke fortalt deg noe om hvorvidt en tunnel kom tilbake.

Kroken kjører, og hva så?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

Hver hendelse kaller kroken to ganger, før og etter overgangen, og gir den fasen og hendelsesnavnet. Den kjører som root med et minimalt miljø, så absolutte stier er nødvendige, og ingen skrivebordsøktvariabel bør forventes. At begge kallene kommer raskt tilbake, sier bare at skriptet kjørte. Om profilen kom opp etterpå, er en egen observasjon og trenger sitt eget bevis i loggen.

Behandle faseargumentet som en del av designet. Et gjenoppkoblingsforsøk i pre-fasen skjer mens maskinen er i ferd med å miste alt, og det kan ikke lykkes.

Root, minimalt miljø, feil bruker

Hvis klienten holder på innloggingstokenet per bruker, lar det å kjøre kroken som root den stå uten noe å vise fram. Sjekk tilstanden under identiteten kroken faktisk bruker, ikke den du testet fra en skrivebordsterminal. Noen bygg lar også en daemon holde grensesnittet etter en frakobling, slik at en gjenoppkobling lander i en foreldet tilstand, og å rydde prosessen først gjenoppretter den på bekostning av en uren avslutning. Ingen av de to oppførslene er synlige hvis du bare tester den glade veien.

Skriv kroken med absolutte stier, hold den eid av root og kjørbar, og loggfør hva den gjorde. Uten den loggen starter neste undersøkelse fra null.

Automatisk tilkobling er ikke VPN-veien

NetworkManager tilbyr to aktiveringsmekanismer: et automatisk tilkoblingsflagg på profilen, og sekundære tilkoblinger som starter når en primær profil aktiveres. Innfødte enhetstyper implementerer den første; VPN-plugins har historisk bare implementert den andre, så å krysse av for automatisk tilkobling på en OpenVPN-profil kan ikke ha noen effekt i det hele tatt. Undersøk begge egenskapene, og fest deretter VPN-en som sekundær til Wi-Fi- eller Ethernet-profilen i stedet.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

Et WireGuard-grensesnitt styrt av en systemd-enhet trenger den drop-in-filen i stedet for en krok, ordnet etter at nettverket er online.

Vent på nettverket, med et tak

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

Ved gjenopptak kan tunnelen bli bedt om mens Wi-Fi fortsatt kobler til på nytt, noe som gjør enhver fast hvile til en gjetning. Vent på en tilgjengelig adresse, løft deretter profilen, og begrens ventingen slik at en krok ikke kan holde gjenopptakelsesveien åpen på ubestemt tid. Foretrekk profilnavnet framfor en numerisk indeks, og hvis riktig profil varierer etter nettverk, la den friske tunnelen skrive valget sitt til en fil på forhånd.

Vern også mot omstartstormer ved å telle forsøk og stoppe. En vaktbikkje som reagerer på hver mislykkede sjekk, gjør ett utfall om til en løkke.

Suspender én gang, og les deretter journalen for krokens egen utskrift. Det er den eneste testen som beviser rekkefølgen.