Killswitch-test: meet de opening, niet alleen de herverbinding

Een herverbinding die in een seconde klaar is, vertelt u dat de client snel is. Het vertelt niet of er iets ontsnapte terwijl de tunnel plat lag. Een herverbinding die een minuut duurt, vertelt u dat de client traag is, en nog steeds niet of direct verkeer in de opening was toegestaan. Dat zijn twee metingen, en een killswitch-test die alleen de eerste meldt, heeft de schakelaar niet getest.

Twee observaties, twee aparte oordelen

De beschikbaarheidsvraag is eenvoudig: wanneer was de tunnel weer bruikbaar, en had de beschermde applicatie een nieuwe verbinding nodig om daar te komen. De handhavingsvraag is anders: welke pakketten verlieten de machine tussen het moment dat de bescherming wegviel en het moment dat die terugkwam.

Beantwoord ze met aparte registraties. Eén regel zegt dat de opening een bepaald aantal seconden duurde. Een andere regel zegt of een onbeschermd verzoek tijdens die opening slaagde. Ze samenvoegen tot één geslaagd of gezakt verbergt het geval dat het meest telt: een snelle herverbinding met een lek.

Bouw een sonde die u kunt timen

Gebruik een verzoek dat onschadelijk, goedkoop en onafhankelijk van het eigen besturingskanaal van de tunnel is. De lus hieronder drukt één keer per seconde een tijdstempel, een HTTP-status en de verstreken tijd af, en faalt luid in plaats van te blijven hangen:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

Lees de exitcodes van curl, niet alleen de status. Een 28 betekent dat het verzoek een time-out kreeg, zo ziet een geblokkeerde route eruit. Een 6 betekent dat naamresolutie mislukte, wat een andere bevinding is en vaak de interessantere. Een 200 met een korte verstreken tijd tijdens de opening betekent dat verkeer naar buiten mocht.

Schrijf de uitvoer naar een bestand en bewaar het. De scrolgeschiedenis van de terminal is geen bewijs, en het interessante deel zijn meestal drie regels in het midden.

Veroorzaak een echte storing, geen nette

Loskoppelen via het menu van de client test het coöperatieve pad, waarbij de client tijd heeft om zijn blokkeerregels te installeren. Beëindig in plaats daarvan het proces, of breek de onderliggende verbinding, en u test het pad dat een echte storing neemt.

Elke trigger oefent een ander codepad. Een storing aan de serverkant, verlies van een lokale verbinding en een crash van de client kunnen elk een andere toestand achterlaten, en een ervan is waarschijnlijk het geval dat u uiteindelijk zult tegenkomen. Voer de sonde met minstens twee triggers uit en label de resultaten per trigger.

Lees het log om te zien hoe toegestaan verkeer eruitziet

Een 200 of een snelle verbindingsfout tijdens de opening is een lek, welke richting het ook op wijst. Time-outs gedurende de hele opening zijn de verwachte vorm van een blokkeerbeleid. Naamresolutie die slaagt terwijl verbindingen falen, wijst erop dat de resolver nog bereikbaar is, wat een lek van een andere soort is.

Bestaande sockets vragen om zorg. Een programma kan een verbinding blijven gebruiken die het vóór de ontkoppeling opende, dus schijnbaar levend verkeer bewijst misschien niet dat een nieuwe route was toegestaan. De socketlijst laat zien of een verbinding ouder is dan de gebeurtenis:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

Vergelijk de starttijd van de socket met de tijdstempel van de ontkoppeling. Een verbinding die ouder is dan de storing is bewijs van hergebruik van de socket, niet van een lek, en haar als fout rapporteren stuurt de volgende persoon op jacht naar een bug die niet bestaat.

Leg het resultaat vast in een vorm die een update overleeft

Noteer de trigger, de opening in seconden, of een niet-geblokkeerd verzoek slaagde, of naamresolutie slaagde, en de versies van de client en het besturingssysteem. Die set van vijf feiten is over releases heen te vergelijken, wat een alinea proza niet kan.

Voer dezelfde test opnieuw uit na een clientupdate of een profielwijziging, want blokkeergedrag is een implementatiedetail en het verschuift. Het doel van de registratie is de verschuiving opmerken voordat die een incident wordt, niet de client één keer certificeren.