Sola dorma hoko ne revenigos la VPN-on

Hoko, kiu eliras kun nulo, pruvas nur, ke la skripto ruliĝis. Metu ĝin post la reto, uzu la ĝustan identecon kaj kontrolu, ĉu la profilo eĉ taŭgas.

Metu rekunligan komandon en la dorman hokon kaj la problemo ŝajnas solvita. Ĝi estas solvita nur se la hoko ruliĝas post kiam la reto ekzistas, kiel identeco, kiun la kliento rekonas, laŭ vojo, kiun la kliento efektive implementas. Plej multaj fiaskoj post rekomenco estas unu el tiuj tri, kaj neniu el ili aperas kiel eraro en la hoko mem. La hoko resendas sukceson ĉiel.

Skripto, kiu eliras kun nulo, diris al vi nenion pri tio, ĉu tunelo revenis.

La hoko ruliĝas, kaj poste?

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

Ĉiu okazaĵo vokas la hokon dufoje, antaŭ kaj post la transiro, donante al ĝi la fazon kaj la okazaĵan nomon. Ĝi ruliĝas kiel root kun minimuma medio, do absolutaj vojoj necesas, kaj neniu labortabla seanco-variablo estu atenda. Tio, ke ambaŭ vokoj rapide revenas, diras nur ke la skripto ruliĝis. Ĉu la profilo leviĝis poste, estas aparta observado kaj bezonas sian propran pruvon en la protokolo.

Traktu la fazan argumenton kiel parton de la dezajno. Rekunliga provo en la pre-fazo okazas dum la maŝino preskaŭ perdas ĉion, kaj ĝi ne povas sukcesi.

Root, minimuma medio, malĝusta uzanto

Se la kliento tenas sian ensalutan ĵetonon po uzanto, ruligi la hokon kiel root lasas ĝin sen io por prezenti. Kontrolu la staton sub la identeco, kiun la hoko efektive uzas, ne tiun, kiun vi testis el labortabla terminalo. Iuj buildoj ankaŭ lasas demonon tenantan la interfacon post malkonekto, do rekonekto alvenas en kadukan staton, kaj purigi la procezon unue restarigas ĝin je la kosto de malpura malŝalto. Neniu el la du kondutoj videblas, se vi testas nur la feliĉan vojon.

Skribu la hokon kun absolutaj vojoj, tenu ĝin posedata de root kaj plenumebla, kaj protokolu, kion ĝi faris. Sen tiu protokolo la sekva esploro komenciĝas de nulo.

Aŭtomata konekto ne estas la VPN-vojo

NetworkManager proponas du aktivigajn mekanismojn: aŭtomatan konektan flagon sur la profilo, kaj duarangajn konektojn, kiuj komenciĝas kiam ĉefa profilo aktiviĝas. Denaskaj aparatoj tipoj implementas la unuan; VPN kromaĵoj historie implementis nur la duan, do ŝalti aŭtomatan konekton sur OpenVPN profilo povas tute ne efiki. Esploru ambaŭ ecojn, poste alligu la VPN-on kiel duarangan al la Wi-Fi aŭ Ethernet profilo anstataŭe.

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

WireGuard-interfaco administrata de systemd-unuo bezonas tiun drop-in anstataŭ hoko, ordigita post kiam la reto estas en linio.

Atendu la reton, kun plafono

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"

Ĉe rekomenco la tunelo povas esti petata dum Wi-Fi ankoraŭ reasociiĝas, kio igas ĉiun fiksan dormon konjekto. Atendu atingeblan adreson, poste levu la profilon, kaj limigu la atendon tiel, ke hoko ne povu teni la rekomencan vojon malfermita senfine. Preferu la profilan nomon anstataŭ numera indekso, kaj se la ĝusta profilo varias laŭ reto, lasu la sanan tunnelon registri sian elekton al dosiero anticipe.

Gardu ankaŭ kontraŭ restartaj ŝtormoj, nombrando provojn kaj haltante. Gvatisto, kiu reagas al ĉiu malsukcesa sondado, igas unu paneon buklo.

Suspendu unufoje, poste legu la ĵurnalon por la propra eligo de la hoko. Tio estas la sola testo, kiu pruvas la ordon.

Rilataj artikoloj