'n Russtand-hook alleen bring die VPN nie terug nie

'n Hook wat nul teruggee, bewys net dat die skrip geloop het. Rangskik dit ná die netwerk, gebruik die regte identiteit en kyk of die profiel selfs geskik is.

Plaas 'n herverbindingsopdrag in die russtand-hook en die probleem lyk opgelos. Dit is slegs opgelos as die hook loop nadat die netwerk bestaan, as 'n identiteit wat die kliënt herken, deur 'n pad wat die kliënt werklik implementeer. Die meeste mislukkings ná hervatting is een van daardie drie, en nie een daarvan verskyn as 'n fout in die hook self nie. Die hook gee in elk geval sukses terug.

'n Skrip wat nul teruggee, het jou niks vertel oor of 'n tonnel teruggekom het nie.

Die hook loop, en dan?

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

Elke gebeurtenis roep die hook twee keer op, voor en ná die oorgang, en gee dit die fase en die gebeurtenisnaam. Dit loop as root met 'n minimale omgewing, dus is absolute paaie nodig en geen lessenaarsessie-veranderlike moet verwag word nie. Dat albei oproepe vinnig terugkeer, sê net dat die skrip geloop het. Of die profiel daarna opgekom het, is 'n aparte waarneming en het sy eie bewyse in die log nodig.

Behandel die fase-argument as deel van die ontwerp. 'n Herverbindingspoging in die pre-fase gebeur terwyl die masjien op die punt is om alles te verloor, en dit kan nie slaag nie.

Root, minimale omgewing, verkeerde gebruiker

As die kliënt sy aanmeldingstoken per gebruiker hou, laat die hook as root dit met niks om aan te bied nie. Kontroleer die toestand onder die identiteit wat die hook werklik gebruik, nie die een wat jy van 'n lessenaarsterminaal getoets het nie. Sommige boue laat ook 'n daemon die koppelvlak hou ná 'n ontkoppeling, so 'n herverbinding beland in 'n verouderde toestand, en om die proses eers skoon te maak, herstel dit teen die prys van 'n onskoon afsluiting. Nie een van die gedrag is sigbaar as jy net die gelukkige pad toets nie.

Skryf die hook met absolute paaie, hou dit deur root besit en uitvoerbaar, en teken aan wat dit gedoen het. Sonder daardie log begin die volgende ondersoek by nul.

Outoverbinding is nie die VPN-pad nie

NetworkManager bied twee aktiveringsmeganismes: 'n outoverbindingsvlag op die profiel, en sekondêre verbindings wat begin wanneer 'n primêre profiel aktiveer. Inheemse toesteltipes implementeer die eerste; VPN-inproppe het histories net die tweede geïmplementeer, so om outoverbinding op 'n OpenVPN-profiel te merk, kan heeltemal geen effek hê nie. Inspekteer albei eienskappe en koppel die VPN dan eerder as 'n sekondêre van die Wi-Fi- of Ethernet-profiel.

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

'n WireGuard-koppelvlak wat deur 'n systemd-eenheid bestuur word, het daardie drop-in nodig eerder as 'n hook, georden nadat die netwerk aanlyn is.

Wag vir die netwerk, met 'n plafon

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"

By hervatting kan die tonnel gevra word terwyl Wi-Fi nog herassosieer, wat enige vaste slaap 'n raaiskoot maak. Wag vir 'n bereikbare adres, bring dan die profiel op, en beperk die wag sodat 'n hook nie die hervattingpad onbepaald oop kan hou nie. Verkies die profielnaam bo 'n numeriese indeks, en as die korrekte profiel per netwerk verskil, laat die gesonde tonnel sy keuse vooraf na 'n lêer skryf.

Waak ook teen herbegin-storms deur pogings te tel en te stop. 'n Waghond wat op elke mislukte ondersoek reageer, verander een onderbreking in 'n lus.

Suspendeer een keer en lees dan die joernaal vir die hook se eie uitset. Dit is die enigste toets wat die ordening bewys.

Verwante artikels