Houd meerdere vpnc-tunnels in de lucht met probes per profiel

Eén vpnc-profiel verbindt na een roaming weer schoon; drie ervan breken om de beurt elkaars sockets, routes en resolver-status. Het herverbindingsscript uit het pakket is voor één tunnel geschreven, dus het herstart elk profiel zodra een van hen plat ligt. Dat oplossen vraagt drie dingen: aparte lokale poorten, een probe die per profiel een echte dienst test, en één geordende keten die nooit twee verbindingen tegelijk start.

Geef elk profiel zijn eigen lokale poort

Een vpnc-profiel dat op de standaard lokale poort blijft staan, concurreert met het profiel dat al draait. De tweede verbinding mislukt terwijl de eerste de poort vasthoudt, en de logregel lijkt op een gateway-probleem in plaats van een lokaal conflict. Zet in plaats daarvan één regel per profielbestand:

Local Port 0

Nul laat de kernel een efemere poort kiezen, zodat twee profielen tegelijk kunnen worden opgezet. Noem elk bestand naar de gateway en groep die het bedient, houd het alleen leesbaar voor root, en verbind altijd met het bijpassende profiel in plaats van een gedeelde standaard. Een gedeeld standaardbestand is de manier waarop een script de verkeerde tunnel opnieuw verbindt nadat iemand een profiel heeft hernoemd.

Profielbestanden bevatten inloggegevens, dus rechten horen bij het ontwerp en niet bij het huishouden. Een bestand onder /etc/vpnc dat voor iedereen leesbaar is, geeft het groepsgeheim aan elke lokale gebruiker. Houd de modus op 0600 met root als eigenaar, en laat de scripts het bestand als root lezen in plaats van geheimen in argumenten te kopiëren. Daarom zou een proberscript de inhoud van het bestand nooit in een log moeten schrijven.

Test één dienst per profiel, niet het tunneladres

Een echo-verzoek naar het eigen adres van de tunnel bewijst vooral dat de interface bestaat. Het zegt niets over de vraag of de host erachter de applicatie nog bereikt die de tunnel rechtvaardigt. De interface kan omhoog zijn terwijl de route erachter al weg is.

Test één dienst per profiel met een korte TCP-timeout en verbind alleen het profiel opnieuw waarvan de probe faalde. Twee seconden scheiden een dood pad van een traag pad, en een TCP-probe hangt er niet van af of ICMP ergens onderweg is toegestaan. Wijzig tussen profielen alleen het doel en de configuratienaam:

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

Sla dat op als /usr/local/bin/ensure-vpn-ops.sh, maak het uitvoerbaar en herhaal het voor elk profiel waarbij u alleen het probedoel en de configuratienaam wijzigt. Een probe die een protocolvraag beantwoordt, overleeft gateways die echo laten vallen maar de diensten die gebruikers belangrijk vinden nog steeds doorsturen.

Keten de probes zodat ze nooit racen

Het herverbindingsscript uit het pakket kan uw probes op volgorde aanroepen, en de volgorde is het hele punt. Twee vpnc-connect-aanroepen die samen lopen herschrijven de routingtabel in een volgorde die niemand beheert, en zo verliest een gezond profiel zijn route.

Houd de aanroepen op de voorgrond, voeg een korte insteltijd toe voor de onderliggende interface, en plan de keten vanuit de cron-tabel van root, want alleen root kan de tunnelroutes herschrijven:

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

Houd de volgorde identiek tussen het opstartscript en de cron-regel, want een keten die bij het opstarten in een andere volgorde loopt, is in feite een ander programma. Als één profiel afhankelijk is van de routes van een ander, zet de afhankelijkheid dan vooraan en laat de latere probe onschadelijk mislukken terwijl de eerdere tunnel nog opkomt.

Houd de log in de gaten en breek er dan één met opzet

Log één regel per run met het profiel, het probedoel, het resultaat en de genomen actie. Zonder dat ziet een tunnel die elke minuut flappert er precies zo uit als een die nooit is weggevallen, en een probefout is niet te onderscheiden van een gateway-storing. De log bewijst ook dat de keten alleen het profiel heeft aangeraakt dat faalde. Schrijf hem ergens waar hij een herstart overleeft, anders vertrekken de bewijzen met het proces.

Breek dan met opzet een tunnel en kijk wat er gebeurt. Stop één enkel profiel en bevestig welke processen en routes er nog zijn:

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

Alleen het gestopte profiel zou opnieuw verbonden moeten worden, en de andere sessies zouden zowel hun processen als hun routes moeten behouden. Als er twee profielen herstarten, loopt uw keten ergens parallel waar u dat niet verwachtte.

Wat de watchdog niet mag doen

Een watchdog die alles herstart zodra iets faalt, ziet er bij het testen gezond uit en veroorzaakt een storing in een onderhoudsvenster. Herstart per profiel, nooit wereldwijd.

Geef de voorkeur aan een onderhouden client wanneer de gateway er een voor hetzelfde protocol biedt, en hardcode nooit een wachtwoord in het script of geef er een mee op een commandoregel, omdat het profielbestand het geheim al bevat. Als een taak als gewone gebruiker moet draaien zodra de tunnel staat, verlaag dan de rechten van binnenuit het script in plaats van de hele keten onder dat account te laten draaien. Lees ten slotte de routes opnieuw na een herverbinding, omdat een profiel kan terugkomen met een ander toegewezen adres en een verouderde route kan achterlaten die geen enkele probe gericht op het tunneladres ooit zal opmerken.