Një hook gjumi i vetëm nuk e kthen VPN-në

Vendosni një komandë rilidhjeje në hook-un e gjumit dhe problemi duket i zgjidhur. Zgjidhet vetëm nëse hook-u ekzekutohet pasi rrjeti ekziston, si një identitet që klienti e njeh, përmes një rruge që klienti e zbaton vërtet. Shumica e dështimeve pas zgjimit janë një nga këto tre, dhe asnjëra nuk shfaqet si gabim në vetë hook-un. Hook-u kthen sukses gjithsesi.

Një skript që del me zero nuk ju tha asgjë nëse u kthye një tunel.

Hook-u ekzekutohet, dhe pastaj?

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

Çdo ngjarje e thërret hook-un dy herë, para dhe pas kalimit, duke i dhënë fazën dhe emrin e ngjarjes. Ai ekzekutohet si root me një mjedis minimal, kështu që nevojiten shtigje absolute dhe nuk duhet pritur asnjë variabël sesioni desktop. Fakti që të dyja thirrjet kthehen shpejt thotë vetëm se skripti u ekzekutua. Nëse profili u ngrit më pas është një vëzhgim i veçantë dhe kërkon provën e vet në log.

Trajtojeni argumentin e fazës si pjesë e projektimit. Një përpjekje rilidhjeje në fazën pre ndodh ndërsa makina është gati të humbasë gjithçka, dhe nuk mund të ketë sukses.

Root, mjedis minimal, përdorues i gabuar

Nëse klienti e mban tokenin e hyrjes për çdo përdorues, ekzekutimi i hook-ut si root e lë pa asgjë për të paraqitur. Kontrolloni gjendjen nën identitetin që hook-u përdor vërtet, jo atë që testuat nga një terminal desktop. Disa ndërtime pas shkëputjes lënë edhe një demon që mban ndërfaqen, kështu që rilidhja përfundon në një gjendje të vjetruar, dhe pastrimi i procesit fillimisht e rikthen atë me koston e një mbylljeje jo të pastër. Asnjëra nga të dyja sjelljet nuk duket nëse testoni vetëm rrugën e lumtur.

Shkruani hook-un me shtigje absolute, mbajeni në pronësi të root dhe të ekzekutueshëm, dhe logoni çfarë bëri. Pa atë log hetimi tjetër fillon nga zero.

Lidhja automatike nuk është rruga e VPN

NetworkManager ofron dy mekanizma aktivizimi: një flamur lidhjeje automatike në profil, dhe lidhje dytësore që nisin kur aktivizohet një profil parësor. Llojet e pajisjeve amtare zbatojnë të parin; shtojcat VPN historikisht kanë zbatuar vetëm të dytin, kështu që shënimi i lidhjes automatike në një profil OpenVPN mund të mos ketë fare efekt. Inspektoni të dyja vetitë, pastaj lidhni VPN-në si dytësore të profilit Wi-Fi ose Ethernet.

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

Një ndërfaqe WireGuard e menaxhuar nga një njësi systemd ka nevojë për atë skedar shtesë në vend të një hook-u, e renditur pasi rrjeti të jetë online.

Prisni rrjetin, me një tavan

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"

Pas zgjimit tuneli mund të kërkohet ndërsa Wi-Fi po rilidhet ende, gjë që e kthen çdo gjumë fiks në hamendje. Prisni një adresë të arritshme, pastaj ngrini profilin, dhe kufizoni pritjen që një hook të mos mund ta mbajë rrugën e zgjimit hapur pafundësisht. Preferoni emrin e profilit ndaj një indeksi numerik, dhe nëse profili i saktë ndryshon sipas rrjetit, lëreni tunelin e shëndetshëm ta regjistrojë zgjedhjen e tij në një skedar paraprakisht.

Mbrohuni edhe nga stuhitë e rinisjes, duke numëruar përpjekjet dhe duke ndaluar. Një rojtar që reagon ndaj çdo prove të dështuar e kthen një ndërprerje në një lak.

Pezullojeni sistemin një herë, pastaj lexoni ditarin për daljen e vetë hook-ut. Ky është i vetmi test që vërteton renditjen.