En sovhook ensam hämtar inte tillbaka VPN:en

En hook som avslutas med noll bevisar bara att skriptet kördes. Sätt den efter nätverket, använd rätt identitet och kontrollera om profilen ens är kvalificerad.

Sätt ett återanslutningskommando i sovhooken och problemet ser löst ut. Det är bara löst om hooken körs efter att nätverket finns, som en identitet klienten känner igen, via en väg klienten faktiskt implementerar. De flesta fel efter återupptagning är en av dessa tre, och ingen av dem visas som ett fel i själva hooken. Hooken returnerar framgång ändå.

Ett skript som avslutas med noll har inte sagt dig något om huruvida en tunnel kom tillbaka.

Hooken körs, och sedan?

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

Varje händelse anropar hooken två gånger, före och efter övergången, och ger den fasen och händelsenamnet. Den körs som root med en minimal miljö, så absoluta sökvägar krävs och ingen skrivbordssessionsvariabel bör förväntas. Att båda anropen återvänder snabbt säger bara att skriptet kördes. Om profilen kom upp efteråt är en separat observation och behöver sitt eget bevis i loggen.

Behandla fasargumentet som en del av designen. Ett återanslutningsförsök i pre-fasen sker medan maskinen är på väg att förlora allt, och det kan inte lyckas.

Root, minimal miljö, fel användare

Om klienten håller inloggningstoken per användare lämnar det att köra hooken som root den utan något att visa upp. Kontrollera tillståndet under den identitet som hooken faktiskt använder, inte den du testade från en skrivbordsterminal. Vissa byggen lämnar också en daemon som håller gränssnittet efter en frånkoppling, så en återanslutning landar i ett föråldrat tillstånd, och att rensa processen först återställer den till priset av en oren avstängning. Ingen av de två beteendena syns om du bara testar den lyckliga vägen.

Skriv hooken med absoluta sökvägar, håll den ägd av root och körbar, och logga vad den gjorde. Utan den loggen börjar nästa utredning från noll.

Automatisk anslutning är inte VPN-vägen

NetworkManager erbjuder två aktiveringsmekanismer: en flagga för automatisk anslutning på profilen och sekundära anslutningar som startar när en primär profil aktiveras. Inbyggda enhetstyper implementerar den första; VPN-insticksprogram har historiskt bara implementerat den andra, så att kryssa i automatisk anslutning på en OpenVPN-profil kan inte ha någon effekt alls. Inspektera båda egenskaperna och koppla sedan VPN:en som sekundär till Wi-Fi- eller Ethernet-profilen i stället.

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

Ett WireGuard-gränssnitt som hanteras av en systemd-enhet behöver den drop-in-filen i stället för en hook, ordnad efter att nätverket är online.

Vänta på nätverket, med ett 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"

Vid återupptagning kan tunneln efterfrågas medan Wi-Fi fortfarande återansluter, vilket gör varje fast sömn till en gissning. Vänta på en nåbar adress, lyft sedan profilen, och begränsa väntan så att en hook inte kan hålla återupptagningsvägen öppen i oändlighet. Föredra profilnamnet framför ett numeriskt index, och om rätt profil varierar mellan nätverk, låt den friska tunneln skriva sitt val till en fil i förväg.

Skydda dig också mot omstartsstormar genom att räkna försök och stoppa. En watchdog som reagerar på varje misslyckad kontroll förvandlar ett avbrott till en loop.

Suspendera en gång och läs sedan journalen för hookens egen utskrift. Det är det enda testet som bevisar ordningen.

Relaterade artiklar