Mențineți mai multe tuneluri vpnc cu sondări pe fiecare profil

Un profil vpnc se reconectează curat după un roaming; trei dintre ele își strică pe rând socket-urile, rutele și starea resolver-ului. Scriptul de reconectare din pachet este scris pentru un singur tunel, așa că repornește fiecare profil ori de câte ori oricare dintre ele este jos. Repararea necesită trei lucruri: porturi locale separate, o sondare care testează un serviciu real pentru fiecare profil și un singur lanț ordonat care nu rulează niciodată două conexiuni simultan.

Dați fiecărui profil propriul port local

Un profil vpnc lăsat pe portul local implicit concurează cu profilul care rulează deja. A doua conexiune eșuează în timp ce prima ține portul, iar linia din jurnal arată ca o problemă de gateway, nu ca un conflict local. În schimb, puneți o linie pentru fiecare fișier de profil:

Local Port 0

Zero lasă kernelul să aleagă un port efemer, așa că două profiluri pot fi stabilite simultan. Numiți fiecare fișier după gateway-ul și grupul pe care îl deservește, păstrați-l lizibil doar pentru root și conectați-vă întotdeauna cu profilul potrivit, nu cu un implicit partajat. Un fișier implicit partajat este modul în care un script reconectează tunelul greșit după ce cineva redenumește un profil.

Fișierele de profil conțin acreditări, așa că permisiunile fac parte din proiectare, nu din gospodărie. Un fișier lizibil de toți sub /etc/vpnc predă secretul grupului fiecărui utilizator local. Păstrați modul la 0600 cu root ca proprietar și lăsați scripturile să citească fișierul ca root în loc să copieze secrete în argumente. De aceea un script de sondare nu ar trebui să scrie niciodată conținutul fișierului într-un jurnal.

Sondați un serviciu pentru fiecare profil, nu adresa tunelului

O cerere echo către adresa tunelului însuși dovedește în principal că interfața există. Nu spune nimic despre faptul că gazda din spate mai ajunge la aplicația care justifică tunelul. Interfața poate fi activă în timp ce ruta de dincolo a dispărut deja.

Sondați un serviciu pentru fiecare profil cu un scurt timeout TCP și reconectați doar profilul a cărui sondare a eșuat. Două secunde despart un drum mort de unul lent, iar o sondare TCP nu depinde de permisiunea ICMP undeva pe traseu. Schimbați doar ținta și numele configurației între profiluri:

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

Salvați asta ca /usr/local/bin/ensure-vpn-ops.sh, faceți-l executabil și repetați pentru fiecare profil schimbând doar ținta sondării și numele configurației. O sondare care răspunde la o întrebare de protocol supraviețuiește gateway-urilor care aruncă echo dar încă mai trimit serviciile care contează pentru utilizatori.

Înlănțuiți sondările astfel încât să nu concureze niciodată

Scriptul de reconectare din pachet poate apela sondările dvs. în secvență, iar secvența este tot sensul. Două apeluri vpnc-connect care rulează împreună rescriu tabelul de rutare într-o ordine pe care nimeni nu o controlează, și așa un profil sănătos își pierde ruta.

Țineți apelurile în prim-plan, adăugați o scurtă întârziere de stabilizare pentru interfața de dedesubt și programați lanțul din tabelul cron al root, deoarece doar root poate rescrie rutele tunelului:

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

Țineți ordinea identică între scriptul de pornire și intrarea cron, deoarece un lanț care la pornire rulează într-o altă ordine este în practică alt program. Când un profil depinde de rutele altuia, puneți dependența prima și lăsați sondarea ulterioară să eșueze fără pericol în timp ce tunelul anterior încă urcă.

Urmăriți jurnalul, apoi rupeți unul intenționat

Înregistrați o linie pe rulare cu profilul, ținta sondării, rezultatul și acțiunea întreprinsă. Fără asta, un tunel care oscilează în fiecare minut arată exact ca unul care nu a căzut niciodată, iar o eroare de sondare nu poate fi distinsă de o pană a gateway-ului. Jurnalul dovedește și că lanțul a atins doar profilul care a eșuat. Scrieți-l undeva unde supraviețuiește unei reporniri, altfel dovezile pleacă împreună cu procesul.

Apoi rupeți intenționat un tunel și urmăriți ce se întâmplă. Opriți un singur profil și confirmați ce procese și rute mai sunt prezente:

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

Doar profilul oprit ar trebui reconectat, iar celelalte sesiuni ar trebui să păstreze atât procesele, cât și rutele. Dacă două profiluri repornesc, lanțul dvs. rulează în paralel undeva unde nu vă așteptați.

Ce nu trebuie să facă supraveghetorul

Un supraveghetor care repornește totul ori de câte ori ceva eșuează pare sănătos în teste și provoacă o pană într-o fereastră de mentenanță. Reporniți pe profil, niciodată global.

Preferați un client întreținut când gateway-ul oferă unul pentru același protocol și nu codificați niciodată o parolă în script și nu o transmiteți pe o linie de comandă, deoarece fișierul de profil deține deja secretul. Dacă o sarcină trebuie să ruleze ca utilizator obișnuit după ce tunelul este activ, reduceți privilegiile din interiorul scriptului în loc să faceți întregul lanț să ruleze sub acel cont. În final, recitiți rutele după o reconectare, deoarece un profil poate reveni cu altă adresă atribuită și poate lăsa o rută învechită pe care nicio sondare îndreptată spre adresa tunelului nu o va observa vreodată.