En dvalekrog alene bringer ikke VPN'et tilbage

En krog, der afslutter med nul, beviser kun, at scriptet kørte. Sæt den efter netværket, brug den rigtige identitet, og kontroller, om profilen overhovedet er egnet.

Sæt en genopkoblingskommando i dvalekrogen, og problemet ser løst ud. Det er kun løst, hvis krogen kører, efter at netværket findes, som en identitet, klienten genkender, ad en vej, klienten faktisk implementerer. De fleste fejl efter genoptagelse er en af de tre, og ingen af dem vises som en fejl i selve krogen. Krogen returnerer succes uanset hvad.

Et script, der afslutter med nul, har ikke fortalt dig noget om, hvorvidt en tunnel kom tilbage.

Krogen kører, og hvad så?

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

Hver hændelse kalder krogen to gange, før og efter overgangen, og giver den fasen og hændelsesnavnet. Den kører som root med et minimalt miljø, så absolutte stier er nødvendige, og ingen skrivebordssessionsvariabel bør forventes. At begge kald vender hurtigt tilbage siger kun, at scriptet kørte. Om profilen kom op bagefter, er en separat observation og kræver sine egne beviser i loggen.

Behandl faseargumentet som en del af designet. Et genopkoblingsforsøg i pre-fasen sker, mens maskinen er ved at miste alt, og det kan ikke lykkes.

Root, minimalt miljø, forkert bruger

Hvis klienten gemmer sit login-token pr. bruger, efterlader det at køre krogen som root den uden noget at fremvise. Kontroller tilstanden under den identitet, krogen faktisk bruger, ikke den, du testede fra en skrivebordsterminal. Nogle builds efterlader også en daemon, der holder grænsefladen efter en afbrydelse, så en genopkobling lander i en forældet tilstand, og rydning af processen først gendanner den på bekostning af en uren nedlukning. Ingen af de to adfærd er synlige, hvis du kun tester den glade vej.

Skriv krogen med absolutte stier, hold den ejet af root og eksekverbar, og log, hvad den gjorde. Uden den log starter den næste undersøgelse fra nul.

Automatisk forbindelse er ikke VPN-vejen

NetworkManager tilbyder to aktiveringsmekanismer: et automatisk forbindelsesflag på profilen og sekundære forbindelser, der starter, når en primær profil aktiveres. Indfødte enhedstyper implementerer den første; VPN-plugins har historisk kun implementeret den anden, så et flueben ved automatisk forbindelse på en OpenVPN-profil kan slet ikke have nogen effekt. Undersøg begge egenskaber, og vedhæft derefter VPN'et som sekundært til Wi-Fi- eller Ethernet-profilen i stedet.

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

En WireGuard-grænseflade styret af en systemd-unit har brug for den drop-in i stedet for en krog, ordnet efter at netværket er online.

Vent på netværket, med et loft

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 genoptagelse kan tunnelen blive efterspurgt, mens Wi-Fi stadig genopretter forbindelse, hvilket gør enhver fast søvn til et gæt. Vent på en tilgængelig adresse, bring derefter profilen op, og begræns ventetiden, så en krog ikke kan holde genoptagelsesvejen åben i det uendelige. Foretræk profilnavnet frem for et numerisk indeks, og hvis den korrekte profil varierer efter netværk, lad den sunde tunnel skrive sit valg til en fil på forhånd.

Værn også mod genstartsstorme ved at tælle forsøg og stoppe. En watchdog, der reagerer på hver mislykket sondering, gør et udfald til en løkke.

Suspendér én gang, og læs derefter journalen for krogens egen output. Det er den eneste test, der beviser rækkefølgen.

Relaterede artikler