Tenu plurajn vpnc-tunelojn per kontroloj laŭ profilo

La norma rekonekta skripto supozas unu tunelon. Donu al ĉiu vpnc-profillo sian propran pordon, kontrolu veran servon, kaj ĉenigu la kontrolojn en unu fiksan ordon.

Unu vpnc-profillo rekonektiĝas pure post rea vagado; tri el ili laŭvice rompas la konektejojn, itinerojn kaj staton de la solvilo de la aliaj. La pakaĵa rekonekta skripto estas verkita por unu tunelo, do ĝi restartigas ĉiun profilon kiam ajn unu el ili estas malaktiva. Ripari tion postulas tri aferojn: apartajn lokajn pordojn, kontrolon kiu testas veran servon po profilo, kaj unu ordigitan ĉenon kiu neniam lanĉas du konektojn samtempe.

Donu al ĉiu profilo sian propran lokan pordon

vpnc-profillo lasita sur la implicita loka pordo konkuras kun la jam kuranta profilo. La dua konekto malsukcesas dum la unua tenas la pordon, kaj la protokola linio aspektas kiel problemo de la pordego anstataŭ loka konflikto. Anstataŭe metu unu linion po profil-dosiero:

Local Port 0

Nulo lasas al la kerno elekti efemeran pordon, do du profiloj povas esti starigitaj samtempe. Nomu ĉiun dosieron laŭ la pordego kaj la grupo kiun ĝi servas, tenu ĝin legebla nur de root, kaj ĉiam konektu per la kongrua profilo anstataŭ per komuna implicito. Komuna implica dosiero estas la maniero kiel skripto rekonektas la malĝustan tunelon post kiam iu renomas profilon.

Profil-dosieroj portas akreditaĵojn, do permesoj apartenas al la dezajno, ne al mastrumado. Dosiero legebla de ĉiuj sub /etc/vpnc transdonas la grupan sekreton al ĉiu loka uzanto. Tenu la reĝimon je 0600 kun root kiel posedanto, kaj lasu la skriptojn legi la dosieron kiel root anstataŭ kopii sekretojn en argumentojn. Tial ankaŭ kontrola skripto neniam rajtas skribi la enhavon de la dosiero en protokolon.

Kontrolu unu servon po profilo, ne la tunelan adreson

Eĥa peto al la propra adreso de la tunelo plejparte pruvas ke la interfaco ekzistas. Ĝi diras nenion pri tio, ĉu la gastiganto malantaŭ ĝi ankoraŭ atingas la aplikaĵon kiu pravigas la tunelon. La interfaco povas esti aktiva dum la itinero preter ĝi jam malaperis.

Kontrolu unu servon po profilo kun mallonga TCP-tempo kaj rekonektu nur la profilon kies kontrolo malsukcesis. Du sekundoj apartigas mortan vojon de malrapida, kaj TCP-kontrolo ne dependas de tio, ĉu ICMP estas permesita ie ajn laŭ la vojo. Ŝanĝu nur la celon kaj la agordan nomon inter profiloj:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

Savu tion kiel /usr/local/bin/ensure-vpn-ops.sh, faru ĝin plenumebla, kaj ripetu por ĉiu profilo ŝanĝante nur la kontrol-celon kaj la agordan nomon. Kontrolo kiu respondas protokolan demandon postvivas pordegojn kiuj faligas eĥon sed ankoraŭ plusendas la servojn pri kiuj zorgas uzantoj.

Ĉenigu la kontrolojn por ke ili neniam vetkuru

La pakaĵa rekonekta skripto povas voki viajn kontrolojn sinsekve, kaj la sinsekvo estas la tuta senco. Du alvokoj de vpnc-connect kurantaj kune reskribas la itinertabelon laŭ ordo kiun neniu kontrolas, kaj tiel sana profilo perdas sian itineron.

Tenu la alvokojn malfone, aldonu mallongan paŭzon por stabiliĝo de la suba interfaco, kaj planu la ĉenon el la cron-tabelo de root, ĉar nur root povas reskribi la tunelajn itinerojn:

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

Tenu la ordon identa inter la startiga skripto kaj la cron-ero, ĉar ĉeno kiu ĉe starto kuras laŭ alia ordo estas efektive alia programo. Kiam unu profilo dependas de la itineroj de alia, metu la dependecon unue kaj lasu la postan kontrolon malsukcesi senĝene dum la antaŭa tunelo ankoraŭ suprengrimpas.

Observu la protokolon, poste rompu unu intence

Skribu unu linion po rulado kun la profilo, kontrol-celo, rezulto kaj prenita ago. Sen tio, tunelo kiu flirtas ĉiun minuton aspektas ĝuste kiel tiu kiu neniam falis, kaj cimo en kontrolo ne estas distingebla de pordega misfunkcio. La protokolo ankaŭ pruvas ke la ĉeno tuŝis nur la profilon kiu malsukcesis. Skribu ĝin ie, kie ĝi postvivas restarton, alie la pruvoj foriras kun la procezo.

Poste rompu tunelon intence kaj rigardu kio okazas. Haltigu unu solan profilon kaj konfirmu kiuj procezoj kaj itineroj ankoraŭ ĉeestas:

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

Nur la haltigita profilo devus rekonektiĝi, kaj la aliaj sesioj devus teni kaj siajn procezojn kaj siajn itinerojn. Se du profiloj restartas, via ĉeno kuras paralele ie, kie vi ne atendis.

Kion la gardanto ne rajtas fari

Gardanto kiu restartigas ĉion kiam io ajn malsukcesas aspektas sana dum testado kaj kaŭzas misfunkcion en prizorga fenestro. Restartigu po profilo, neniam tutmonde.

Preferu prizorgatan klienton kiam la pordego ofertas unu por la sama protokolo, kaj neniam enkodu pasvorton en la skripton nek transdonu unu sur komandlinio, ĉar la profil-dosiero jam tenas la sekreton. Se tasko devas kuri kiel ordinara uzanto post kiam la tunelo suprengrimpas, malaltigu privilegiojn el la interno de la skripto anstataŭ igi la tutan ĉenon kuri sub tiu konto. Fine, relegu la itinerojn post rekonekto, ĉar profilo povas reveni kun alia atribuita adreso kaj lasi malnoviĝintan itineron kiun neniu kontrolo celanta la tunelan adreson iam rimarkos.

Rilataj artikoloj