Én vpnc-profil genopkobler rent efter et roam; tre af dem ødelægger efter tur hinandens sockets, ruter og resolver-tilstand. Genopkoblingsscriptet fra pakken er skrevet til en enkelt tunnel, så det genstarter hver profil, når bare én af dem er nede. At rette det kræver tre ting: separate lokale porte, en probe der tester en rigtig tjeneste pr. profil, og én ordnet kæde der aldrig kører to forbindelser samtidigt.

Giv hver profil sin egen lokale port

En vpnc-profil, der efterlades på den lokale standardport, konkurrerer med den profil, der allerede kører. Den anden forbindelse fejler, mens den første holder porten, og loglinjen ser ud som et gateway-problem snarere end en lokal konflikt. Sæt i stedet én linje pr. profilfil:

Local Port 0

Nul lader kernen vælge en tilfældig port, så to profiler kan etableres samtidigt. Navngiv hver fil efter den gateway og gruppe, den betjener, hold den læsbar for root alene, og forbind altid med den matchende profil i stedet for en delt standard. En delt standardfil er måden, hvorpå et script genopkobler den forkerte tunnel, efter at nogen har omdøbt en profil.

Profilfiler bærer legitimationsoplysninger, så rettigheder hører til designet og ikke til rengøringen. En fil under /etc/vpnc, som alle kan læse, giver gruppehemmeligheden til enhver lokal bruger. Hold tilstanden på 0600 med root som ejer, og lad scriptene læse filen som root i stedet for at kopiere hemmeligheder ind i argumenter. Det er også derfor, et probescript aldrig bør skrive filens indhold i en log.

Prob én tjeneste pr. profil, ikke tunneladressen

En ekkoanmodning til tunnelens egen adresse beviser mest, at interfacet findes. Den siger intet om, hvorvidt værten bagved stadig kan nå den applikation, der begrunder tunnelen. Interfacet kan være oppe, mens ruten bag det allerede er væk.

Prob én tjeneste pr. profil med en kort TCP-timeout, og genopkobl kun den profil, hvis probe fejlede. To sekunder skiller en død vej fra en langsom, og en TCP-probe afhænger ikke af, at ICMP er tilladt noget sted undervejs. Ændr kun målet og konfigurationsnavnet mellem profilerne:

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

Gem det som /usr/local/bin/ensure-vpn-ops.sh, gør det eksekverbart, og gentag for hver profil med kun probemålet og konfigurationsnavnet ændret. En probe, der besvarer et protokolspørgsmål, overlever gateways, som dropper ekko, mens de stadig videresender de tjenester, brugerne er interesserede i.

Kæd proberne, så de aldrig kapløber

Genopkoblingsscriptet fra pakken kan kalde dine prober i rækkefølge, og rækkefølgen er hele pointen. To vpnc-connect-kald, der kører samtidigt, skriver routingtabellen om i en orden, som ingen kontrollerer, og det er sådan en sund profil mister sin rute.

Hold kaldene i forgrunden, tilføj en kort afsætningsforsinkelse for det underliggende interface, og planlæg kæden fra roots cron-tabel, da kun root kan skrive tunnelruterne om:

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

Hold rækkefølgen identisk mellem opstartsscriptet og cron-posten, da en kæde, der ved opstart kører i en anden rækkefølge, reelt er et andet program. Når en profil afhænger af en andens ruter, skal du placere afhængigheden først og lade den senere probe fejle ufarligt, mens den tidligere tunnel stadig kommer op.

Hold øje med loggen, og ødelæg så en med vilje

Log én linje pr. kørsel med profilen, probemålet, resultatet og den udførte handling. Uden det ser en tunnel, der blafrer hvert minut, præcis ud som en, der aldrig er faldet, og en probefejl kan ikke skelnes fra et gatewayudfald. Loggen beviser også, at kæden kun rørte den profil, der fejlede. Skriv den et sted, der overlever en genstart, ellers forlader beviserne processen.

Ødelæg så en tunnel med vilje, og se, hvad der sker. Stop en enkelt profil, og bekræft, hvilke processer og ruter der stadig findes:

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

Kun den stoppede profil bør genopkobles, og de andre sessioner bør beholde både deres processer og deres ruter. Hvis to profiler genstarter, kører din kæde parallelt et sted, du ikke forventede.

Hvad watchdog'en ikke må gøre

En watchdog, der genstarter alt, når bare noget fejler, ser sund ud under test og forårsager et udfald i et vedligeholdelsesvindue. Genstart pr. profil, aldrig globalt.

Foretræk en vedligeholdt klient, når gatewayen tilbyder en til samme protokol, og hardkod aldrig en adgangskode i scriptet eller send en på en kommandolinje, fordi profilfilen allerede holder hemmeligheden. Hvis en opgave skal køre som almindelig bruger, når tunnelen er oppe, så sænk privilegierne inde fra scriptet i stedet for at lade hele kæden køre under den konto. Læs til sidst ruterne igen efter en genopkobling, fordi en profil kan vende tilbage med en anden tildelt adresse og efterlade en forældet rute, som ingen probe rettet mod tunneladressen nogensinde bemærker.

Relaterede artikler