Ein kvilekrok åleine hentar ikkje VPN-en tilbake

Ein krok som avsluttar med null, beviser berre at skriptet køyrde. Set han etter netverket, bruk rett identitet, og sjekk om profilen i det heile er kvalifisert.

Set ein attkoplingskommando i kvilekroken, og problemet ser løyst ut. Det er berre løyst dersom kroken køyrer etter at netverket finst, som ein identitet klienten kjenner att, via ein veg klienten faktisk implementerer. Dei fleste feil etter attopptaking er ein av desse tre, og ingen av dei viser seg som ein feil i kroken sjølv. Kroken returnerer suksess uansett.

Eit skript som avsluttar med null, har ikkje fortalt deg noko om ein tunnel kom tilbake.

Kroken køyrer, og kva så?

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

Kvar hending kallar kroken to gonger, før og etter overgangen, og gjev han fasen og hendingsnamnet. Han køyrer som root med eit minimalt miljø, så absolutte stiar er naudsynte, og ingen skrivebordsøktvariabel bør ein vente. At begge kalla kjem snøgt tilbake, seier berre at skriptet køyrde. Om profilen kom opp etterpå, er ei eiga observasjon og treng sitt eige bevis i loggen.

Behandle faseargumentet som ein del av designet. Eit attkoplingsforsøk i pre-fasen skjer medan maskinen er i ferd med å miste alt, og det kan ikkje lukkast.

Root, minimalt miljø, feil brukar

Dersom klienten held på innloggingstokenet per brukar, lèt det å køyre kroken som root han stå utan noko å visa fram. Sjekk tilstanden under identiteten kroken faktisk brukar, ikkje den du testa frå ein skrivebordsterminal. Nokre bygg lèt også ein daemon halde grensesnittet etter ei fråkopling, slik at ei attkopling landar i ein forelda tilstand, og å rydde prosessen først gjenopprettar han på kostnad av ei uren avslutning. Ingen av dei to åtferdene er synlege om du berre testar den glade vegen.

Skriv kroken med absolutte stiar, hald han eigd av root og køyrbar, og logg kva han gjorde. Utan den loggen startar neste gransking frå null.

Automatisk tilkopling er ikkje VPN-vegen

NetworkManager tilbyr to aktiveringsmekanismar: eit automatisk tilkoplingsflagg på profilen, og sekundære tilkoplingar som startar når ein primær profil aktiverast. Innfødde einingstypar implementerer den første; VPN-pluginar har historisk berre implementert den andre, så å krysse av for automatisk tilkopling på ein OpenVPN-profil kan ikkje ha nokon effekt i det heile. Undersøk begge eigenskapane, og fest deretter VPN-en som sekundær til Wi-Fi- eller Ethernet-profilen i staden.

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

Eit WireGuard-grensesnitt styrt av ei systemd-eining treng den drop-in-fila i staden for ein krok, ordna etter at netverket er på nett.

Vent på netverket, med eit 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 attopptaking kan tunnelen bli bede om medan Wi-Fi framleis koplar til på nytt, noko som gjer kvar fast kvile til ei gissing. Vent på ei tilgjengeleg adresse, løft deretter profilen, og avgrens ventetida slik at ein krok ikkje kan halde attopptakingsvegen open på ubestemt tid. Føretrekk profilnamnet framfor ein numerisk indeks, og dersom rett profil varierer etter netverk, lat den friske tunnelen skrive valet sitt til ei fil på førehand.

Vern også mot omstartstormar ved å telje forsøk og stoppe. Ein vakthund som reagerer på kvar mislukka sjekk, gjer eitt utfall om til ei løkke.

Suspender ein gong, og les deretter journalen for kroken si eiga utskrift. Det er den einaste testen som beviser rekkjefølgja.

Relaterte artiklar