Håll flera vpnc-tunnlar igång med prober per profil

En vpnc-profil återansluter rent efter en roaming; tre av dem bryter turvis varandras sockets, rutter och resolver-tillstånd. Återanslutningsskriptet från paketet är skrivet för en enda tunnel, så det startar om varje profil så fort någon av dem är nere. Att rätta det kräver tre saker: separata lokala portar, en prob som testar en riktig tjänst per profil och en enda ordnad kedja som aldrig kör två anslutningar samtidigt.

Ge varje profil sin egen lokala port

En vpnc-profil som lämnas på den lokala standardporten konkurrerar med profilen som redan kör. Den andra anslutningen misslyckas medan den första håller porten, och loggraden ser ut som ett gateway-problem snarare än en lokal konflikt. Sätt i stället en rad per profilfil:

Local Port 0

Noll låter kärnan välja en tillfällig port, så två profiler kan etableras samtidigt. Namnge varje fil efter gatewaven och gruppen den betjänar, håll den läsbar bara för root och anslut alltid med den matchande profilen i stället för en delad standard. En delad standardfil är sättet ett skript återansluter fel tunnel efter att någon har bytt namn på en profil.

Profilfiler innehåller inloggningsuppgifter, så behörigheter hör till designen och inte till städningen. En fil under /etc/vpnc som alla kan läsa ger grupphemligheten till varje lokal användare. Håll läget på 0600 med root som ägare och låt skripten läsa filen som root i stället för att kopiera hemligheter till argument. Det är också därför ett probskript aldrig bör skriva filens innehåll till loggen.

Testa en tjänst per profil, inte tunneladressen

En eko-förfrågan till tunnelns egen adress bevisar mest att gränssnittet finns. Den säger inget om huruvida värden bakom fortfarande når applikationen som rättfärdigar tunneln. Gränssnittet kan vara uppe medan rutten bakom redan är borta.

Testa en tjänst per profil med en kort TCP-timeout och återanslut bara profilen vars prob misslyckades. Två sekunder skiljer en död väg från en långsam, och en TCP-prob beror inte på att ICMP tillåts någonstans längs vägen. Ändra bara målet och konfigurationsnamnet mellan profilerna:

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

Spara det som /usr/local/bin/ensure-vpn-ops.sh, gör det körbart och upprepa för varje profil med bara probmålet och konfigurationsnamnet ändrat. En prob som svarar på en protokollfråga överlever gateways som kastar eko men fortfarande vidarebefordrar de tjänster användarna bryr sig om.

Kedja proberna så att de aldrig kapplöper

Återanslutningsskriptet från paketet kan anropa dina prober i tur och ordning, och ordningen är hela poängen. Två vpnc-connect-anrop som kör samtidigt skriver om routingtabellen i en ordning som ingen kontrollerar, och det är så en frisk profil förlorar sin rutt.

Håll anropen i förgrunden, lägg till en kort insvängningsfördröjning för gränssnittet under och schemalägg kedjan från roots crontab, eftersom bara root kan skriva om tunnelrutterna:

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

Håll ordningen identisk mellan startskriptet och cronposten, eftersom en kedja som vid start kör i en annan ordning i praktiken är ett annat program. När en profil beror på en annans rutter, placera beroendet först och låt den senare proben misslyckas ofarligt medan den tidigare tunneln fortfarande kommer upp.

Håll koll på loggen och bryt sedan en med avsikt

Logga en rad per körning med profilen, probmålet, resultatet och den vidtagna åtgärden. Utan det ser en tunnel som fladdrar varje minut exakt ut som en som aldrig föll, och ett probfel går inte att skilja från ett gatewayavbrott. Loggen bevisar också att kedjan bara rörde profilen som misslyckades. Skriv den någonstans som överlever en omstart, annars försvinner bevisen med processen.

Bryt sedan en tunnel med avsikt och se vad som händer. Stoppa en enda profil och bekräfta vilka processer och rutter som fortfarande finns:

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

Bara den stoppade profilen bör återanslutas, och de andra sessionerna bör behålla både sina processer och sina rutter. Om två profiler startar om kör din kedja parallellt någonstans du inte förväntade dig.

Vad watchdoggen inte får göra

En watchdog som startar om allt så fort något misslyckas ser frisk ut under tester och orsakar ett avbrott i ett underhållsfönster. Starta om per profil, aldrig globalt.

Föredra en underhållen klient när gatewaven erbjuder en för samma protokoll, och hårdkoda aldrig ett lösenord i skriptet eller skicka ett på en kommandorad, eftersom profilfilen redan håller hemligheten. Om en uppgift måste köras som vanlig användare när tunneln är uppe, sänk behörigheterna inifrån skriptet i stället för att låta hela kedjan köra under det kontot. Läs slutligen om rutterna efter en återanslutning, eftersom en profil kan komma tillbaka med en annan tilldelad adress och lämna en inaktuell rutt som ingen prob riktad mot tunneladressen någonsin kommer att märka.