Een ping-wachter onderscheidt geen kapotte tunnel van een gezonde

Een ping naar internet bewijst minder dan het lijkt. Onderzoek de tunnel van binnenuit, tel fouten voordat je handelt, en behandel de overstap naar een andere server als een aparte beslissing.

Drie voorwaarden bepalen of een wachter helpt of schaadt: wat de sonde kan onderscheiden, hoeveel opeenvolgende fouten een actie rechtvaardigen, en of de actie een herverbinding of een overstap is. Een cronregel die een openbaar adres pingt, beantwoordt geen van drieën goed. Hij verbindt tunnels die in orde zijn opnieuw en laat tunnels die kapot zijn liggen, en hij doet beide zonder vastlegging. Het ontwerp dat de moeite waard is om te houden, maakt die drie keuzes expliciet.

De sonde is het deel dat al het andere bepaalt.

Wat een ping naar internet werkelijk bewijst

Een openbare resolver pingen toont aan dat het lokale internetpad leeft. Het bewijst niet dat de tunnel verkeer draagt, en op een profiel met volledige tunnel reist de ping zelf door de tunnel, zodat een gezond antwoord en een kapotte tunnel naast elkaar kunnen bestaan terwijl de client nog pakketten doorstuurt. Als het profiel naamzoekopdrachten door de tunnel stuurt, wordt een DNS-fout gelezen als een dode verbinding en start een herverbinding die niets kan repareren.

Geen van beide richtingen van de fout verschijnt in de exitcode. Een wachter die op dat signaal is gebouwd, is een muntworp met een cronschema.

Onderzoek iets dat achter de tunnel leeft

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

Onderzoek van binnenuit, de goedkoopste controle eerst. Of de interface bestaat, zegt dat de tunnel omhoog is; een routeopzoeking naar een bekend intern adres zegt dat verkeer erin zou gaan; een TCP-sonde naar een host aan de andere kant zegt dat er werkelijk iets antwoordt. Alleen echo-verzoeken misleiden: veel interne hosts antwoorden graag op TCP maar laten ICMP vallen, dus een wachter op basis van ping verbindt steeds opnieuw een tunnel die nooit ophield te werken.

Houd de sonde in de tijd begrensd en geef hem een eigen exitstatus. Een sonde die dertig seconden blijft hangen, maakt van een wachter een storingsdetector met ingebouwde vertraging.

Kies tussen één regel en een lus

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

Een cronregel is één regel zonder geheugen, wat past bij een laptop waar een extra herverbinding niets kost. Een bewaakte lus houdt een teller bij en handelt pas na meerdere fouten, wat voorkomt dat een wankele verbinding een storm van herverbindingen ontketent. Laat hem in ieder geval onder een supervisor draaien zodat hij een crash overleeft en naar het journaal schrijft. Kies op grond van of een onterechte herverbinding ertoe doet, niet op grond van welke versie korter is.

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

Die lus telt opeenvolgende fouten in plaats van een fractie over een venster. Een venster vereist een klok en een geheugen van monsters, en de meeste fouten in handgemaakte wachters zitten in dat rekenwerk.

De overstap is een andere beslissing

Van server wisselen is iets anders dan opnieuw verbinden. Breek eerst de oude verbinding af, want een tweede client die start terwijl de eerste het adres nog houdt, botst. Tel opeenvolgende fouten voordat je wisselt, begrens de pogingen, en onderzoek opnieuw zodra de nieuwe verbinding staat in plaats van de exitstatus van het connect-commando te vertrouwen. Een verkeerde configuratie zou niet in een lus door elke server moeten roteren.

Onderzoek niet het eigen openbare adres van de VPN-server van binnenuit een volledige tunnel. Die controle hangt af van wat hij test, en hij meldt succes terwijl het pad dat hij moest valideren al weg is.

Noteer welke sonde liep, wat hij teruggaf en welke actie volgde. Die vastlegging maakt van een mysterieuze herverbinding een gebeurtenis die te diagnosticeren is.

Gerelateerde artikelen