En ping-vagt kan ikke skelne en brudt tunnel fra en sund
Et ping til internettet beviser mindre, end det ser ud til. Undersøg tunnelen indefra, tæl fejl før du handler, og behandl skift til en anden server som en selvstændig beslutning.
Tre forhold afgør, om en vagt hjælper eller skader: hvad sonden kan skelne, hvor mange fejl i træk der berettiger en handling, og om handlingen er en genopkobling eller et skift. En cron-linje, der pinger en offentlig adresse, svarer ikke godt på nogen af dem. Den genopkobler tunneler, der er i orden, og lader tunneler, der er brudt, være, og den gør begge dele uden en registrering. Det design, der er værd at beholde, gør de tre valg eksplicitte.
Sonden er den del, der afgør alt andet.
Hvad et ping til internettet faktisk beviser
At pinge en offentlig resolver viser, at den lokale internetvej er levende. Det beviser ikke, at tunnelen bærer trafik, og på en profil med fuld tunnel rejser selve pinget gennem tunnelen, så et sundt svar og en brudt tunnel kan findes samtidig, mens klienten stadig videresender pakker. Hvis profilen sender navneopslag gennem tunnelen, læses en DNS-fejl som en død forbindelse og starter en genopkobling, der ikke kan rette noget.
Ingen af fejlens to retninger vises i exitkoden. En vagt bygget på det signal er et møntkast med en cron-tidsplan.
Undersøg noget, der lever bag tunnelen
ip -brief addr show tun0 ip route get 10.100.20.10 nc -z -w3 10.100.20.10 443
Undersøg indefra, den billigste kontrol først. Om grænsefladen findes, fortæller at tunnelen er oppe; et ruteopslag til en kendt intern adresse fortæller, at trafik ville gå ind i den; en TCP-sonde til en vært på den anden side fortæller, at noget faktisk svarer. Kun echo-anmodninger vildleder: mange interne værter svarer gerne på TCP, men dropper ICMP, så en vagt bygget på ping bliver ved med at genopkoble en tunnel, der aldrig holdt op med at virke.
Hold sonden tidsbegrænset og giv den en egen exitstatus. En sonde, der hænger i tredive sekunder, gør en vagt til en udfaldsdetektor med indbygget forsinkelse.
Vælg mellem en enkelt linje og en løkke
* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect
En cron-post er en enkelt linje uden hukommelse, hvilket passer til en bærbar, hvor en ekstra genopkobling ikke koster noget. En overvåget løkke holder en tæller og handler først efter flere fejl, hvilket forhindrer et ustabilt link i at udløse en storm af genopkoblinger. Under alle omstændigheder skal du køre den under en supervisor, så den overlever et nedbrud og skriver til journalen. Vælg efter, om en falsk genopkobling betyder noget, ikke efter hvilken version der er kortere.
failures=0 while sleep 30; do if nc -z -w5 10.100.20.10 443; then failures=0 else failures=$((failures+1)); fi if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi done
Den løkke tæller fejl i træk i stedet for en brøkdel over et vindue. Et vindue kræver et ur og en hukommelse af prøver, og de fleste fejl i håndskrevne vagter bor i den aritmetik.
Skift til en anden server er en anden beslutning
At skifte server er noget andet end at genopkoble. Riv den gamle forbindelse ned først, fordi en anden klient, der starter, mens den første stadig har adressen, vil støde sammen. Tæl fejl i træk før skiftet, begræns forsøgene, og undersøg igen, når den nye forbindelse er oppe, i stedet for at stole på connect-kommandos exitstatus. En forkert konfiguration bør ikke rotere gennem hver server i en løkke.
Undersøg ikke VPN-serverens egen offentlige adresse indefra en fuld tunnel. Den kontrol afhænger af det, den tester, og den rapporterer succes, mens den vej, den skulle bekræfte, er væk.
Registrer, hvilken sonde der kørte, hvad den returnerede, og hvilken handling der fulgte. Den registrering gør en mystisk genopkobling til en begivenhed, der kan diagnosticeres.