Kill switch-test: mål hullet, ikke kun genopkoblingen

En genopkobling, der er færdig på et sekund, fortæller dig, at klienten er hurtig. Den fortæller ikke, om noget slap ud, mens tunnelen var nede. En genopkobling, der tager et minut, fortæller dig, at klienten er langsom, og stadig ikke om direkte trafik var tilladt i hullet. Det er to målinger, og en kill switch-test, der kun rapporterer den første, har ikke testet kontakten.

To observationer, to separate domme

Tilgængelighedsspørgsmålet er enkelt: hvornår blev tunnelen brugbar igen, og havde den beskyttede applikation brug for en ny forbindelse for at nå dertil. Håndhævelsesspørgsmålet er anderledes: hvilke pakker forlod maskinen mellem det øjeblik, beskyttelsen faldt, og det øjeblik, den vendte tilbage.

Besvar dem med separate registreringer. Én linje siger, at hullet varede et bestemt antal sekunder. En anden linje siger, om en ubeskyttet anmodning lykkedes i hullet. At slå dem sammen til et enkelt bestået eller ikke bestået skjuler det tilfælde, der betyder mest: en hurtig genopkobling med en lækage.

Byg en sonde, du kan tidsmåle

Brug en anmodning, der er harmløs, billig og uafhængig af tunnelens egen kontrolkanal. Løkken nedenfor udskriver et tidsstempel, en HTTP-status og den forløbne tid én gang i sekundet, og den fejler højlydt i stedet for at hænge:

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

Læs curls exitkoder i stedet for kun status. 28 betyder, at anmodningen timede ud, sådan ser en blokeret vej ud. 6 betyder, at navneopløsningen fejlede, hvilket er et andet fund og ofte det mere interessante. 200 med kort forløben tid i hullet betyder, at trafik fik lov at komme ud.

Skriv outputtet til en fil, og gem den. Terminalens rullehistorik er ikke bevis, og den interessante del er normalt tre linjer i midten.

Udløs en rigtig fejl, ikke en pæn en

Afbrydelse fra klientens egen menu tester den samarbejdsvillige vej, hvor klienten har tid til at installere sine blokeringsregler. Dræb processen i stedet, eller slip det underliggende link, og du tester den vej, en faktisk fejl tager.

Hver udløser gennemløber en anden kodesti. Et udfald på serversiden, et lokalt linktab og et klientnedbrud kan hver især efterlade forskellig tilstand, og en af dem er sandsynligvis det tilfælde, du ender med at møde. Kør sonden ved mindst to udløsere, og mærk resultaterne efter udløser.

Læs loggen for at se, hvordan tilladt trafik ser ud

200 eller en hurtig forbindelsesfejl i hullet er en lækage, uanset hvilken retning det peger. Timeouts gennem hele hullet er den forventede form af en blokeringspolitik. Navneopløsning, der lykkes, mens forbindelser fejler, tyder på, at resolveren stadig er nåbar, hvilket er en lækage af en anden slags.

Eksisterende sockets kræver omhu. Et program kan fortsætte med at bruge en forbindelse, det åbnede før afbrydelsen, så tilsyneladende levende trafik beviser måske ikke, at en ny vej var tilladt. Socketlisten viser, om en forbindelse er ældre end hændelsen:

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

Sammenlign socketens starttid med tidsstemplet for afbrydelsen. En forbindelse ældre end udfaldet er bevis på genbrug af socket, ikke på en lækage, og at rapportere den som en fejl sender den næste person på jagt efter en fejl, der ikke findes.

Registrér resultatet i en form, der overlever en opdatering

Skriv udløseren ned, hullet i sekunder, om en ublokeret anmodning lykkedes, om navneopløsning lykkedes, og klientens og styresystemets versioner. Det sæt af fem fakta kan sammenlignes på tværs af udgivelser, hvilket et afsnit prosa ikke kan.

Kør den samme test igen efter en klientopdatering eller en profilændring, fordi blokeringsadfærd er en implementeringsdetalje, og den flytter sig. Pointen med registreringen er at bemærke flytningen, før den bliver en hændelse, ikke at certificere klienten én gang.