Een slaap-hook alleen brengt de VPN niet terug

Zet een herverbindingscommando in de slaap-hook en het probleem lijkt opgelost. Het is alleen opgelost als de hook draait nadat het netwerk bestaat, als een identiteit die de client herkent, via een pad dat de client echt implementeert. De meeste fouten na hervatten zijn een van die drie, en geen ervan verschijnt als fout in de hook zelf. De hook geeft hoe dan ook succes terug.

Een script dat met nul eindigt, heeft je niets verteld over of er een tunnel terugkwam.

De hook draait, en dan?

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

Elke gebeurtenis roept de hook twee keer aan, voor en na de overgang, en geeft hem de fase en de gebeurtenisnaam. Hij draait als root met een minimale omgeving, dus absolute paden zijn nodig en er moet geen variabele van een desktopsessie worden verwacht. Dat beide aanroepen snel terugkeren, zegt alleen dat het script draaide. Of het profiel daarna omhoogkwam, is een aparte observatie en heeft zijn eigen bewijs in het log nodig.

Behandel het faseargument als onderdeel van het ontwerp. Een herverbindingspoging in de pre-fase gebeurt terwijl de machine op het punt staat alles te verliezen, en die kan niet slagen.

Root, minimale omgeving, verkeerde gebruiker

Als de client zijn logintoken per gebruiker bewaart, laat de hook als root niets over om te presenteren. Controleer de toestand onder de identiteit die de hook echt gebruikt, niet die je vanaf een desktopterminal hebt getest. Sommige builds laten na een verbreking ook een daemon achter die de interface vasthoudt, zodat een herverbinding in een verouderde toestand belandt, en het eerst opruimen van het proces herstelt hem ten koste van een onnette afsluiting. Geen van beide gedragingen is zichtbaar als je alleen het gelukkige pad test.

Schrijf de hook met absolute paden, houd hem eigendom van root en uitvoerbaar, en log wat hij deed. Zonder dat log begint het volgende onderzoek bij nul.

Autoconnect is niet het VPN-pad

NetworkManager biedt twee activeringsmechanismen: een autoconnect-vlag op het profiel en secundaire verbindingen die starten wanneer een primair profiel activeert. Native apparaattypen implementeren de eerste; VPN-plug-ins hebben historisch alleen de tweede geïmplementeerd, dus autoconnect aanvinken op een OpenVPN-profiel kan helemaal geen effect hebben. Inspecteer beide eigenschappen en koppel de VPN daarna in plaats daarvan als secundaire van het Wi-Fi- of Ethernet-profiel.

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

Een WireGuard-interface die door een systemd-unit wordt beheerd, heeft die drop-in nodig in plaats van een hook, geordend nadat het netwerk online is.

Wacht op het netwerk, met een plafond

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"

Bij hervatten kan de tunnel worden gevraagd terwijl Wi-Fi nog opnieuw koppelt, waardoor elke vaste slaap een gok wordt. Wacht op een bereikbaar adres, breng dan het profiel omhoog, en begrens het wachten zodat een hook het hervatpad niet onbeperkt open kan houden. Geef de voorkeur aan de profielnaam boven een numerieke index, en als het juiste profiel per netwerk verschilt, laat de gezonde tunnel zijn keuze vooraf naar een bestand schrijven.

Beveilig je ook tegen herstartstormen door pogingen te tellen en te stoppen. Een watchdog die op elke mislukte controle reageert, maakt van één storing een lus.

Suspend één keer en lees daarna het journaal voor de eigen uitvoer van de hook. Dat is de enige test die de volgorde bewijst.