Kill switch-test: mål gapet, ikke bare gjenoppkoblingen

En gjenoppkobling som er ferdig på et sekund, forteller deg at klienten er rask. Den forteller ikke om noe slapp ut mens tunnelen var nede. En gjenoppkobling som tar et minutt, forteller deg at klienten er treg, og fortsatt ikke om direkte trafikk var tillatt i gapet. Det er to målinger, og en kill switch-test som bare rapporterer den første, har ikke testet bryteren.

To observasjoner, to separate dommer

Tilgjengelighetsspørsmålet er enkelt: når ble tunnelen brukbar igjen, og trengte den beskyttede applikasjonen en ny tilkobling for å komme dit. Håndhevelsesspørsmålet er annerledes: hvilke pakker forlot maskinen mellom øyeblikket beskyttelsen falt og øyeblikket den kom tilbake.

Svar på dem med separate registreringer. Én linje sier at gapet varte et bestemt antall sekunder. En annen linje sier om en ubeskyttet forespørsel lyktes i gapet. Å slå dem sammen til ett bestått eller ikke bestått skjuler tilfellet som betyr mest: en rask gjenoppkobling med en lekkasje.

Bygg en sonde du kan tidfeste

Bruk en forespørsel som er ufarlig, billig og uavhengig av tunnelens egen kontrollkanal. Løkken nedenfor skriver ut et tidsstempel, en HTTP-status og forløpt tid én gang i sekundet, og den feiler høylytt i stedet for å henge:

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

Les curls utgangskoder, ikke bare statusen. 28 betyr at forespørselen timet ut, slik ser en blokkert vei ut. 6 betyr at navneoppslaget feilet, noe som er et annet funn og ofte det mer interessante. 200 med kort forløpt tid i gapet betyr at trafikken fikk lov å gå ut.

Skriv utdataene til en fil og ta vare på den. Terminalens rullehistorikk er ikke bevis, og den interessante delen er vanligvis tre linjer i midten.

Utløs en ekte feil, ikke en ryddig en

Å koble fra i klientens egen meny tester den samarbeidsvillige veien, der klienten har tid til å installere blokkeringsreglene sine. Drep prosessen i stedet, eller bryt den underliggende lenken, og du tester veien en faktisk feil tar.

Hver utløser trener en annen kodesti. Et utfall på serversiden, tap av lokal lenke og en klientkrasj kan hver for seg etterlate ulik tilstand, og en av dem er sannsynligvis tilfellet du ender med å møte. Kjør sonden med minst to utløsere og merk resultatene etter utløser.

Les loggen for å se hvordan tillatt trafikk ser ut

200 eller en rask tilkoblingsfeil i gapet er en lekkasje, uansett hvilken retning den peker. Tidsavbrudd gjennom hele gapet er den forventede formen til en blokkeringspolicy. Navneoppslag som lykkes mens tilkoblinger feiler, tyder på at resolvere fortsatt er nåbar, noe som er en lekkasje av en annen sort.

Eksisterende sockets krever omhu. Et program kan fortsette å bruke en tilkobling det åpnet før frakoblingen, så tilsynelatende levende trafikk beviser kanskje ikke at en ny vei var tillatt. Socketlisten viser om en tilkobling er eldre enn hendelsen:

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 frakoblingen. En tilkobling eldre enn utfallet er bevis på gjenbruk av socket, ikke på en lekkasje, og å rapportere den som en feil sender neste person på jakt etter en feil som ikke finnes.

Registrer resultatet i en form som overlever en oppdatering

Skriv ned utløseren, gapet i sekunder, om en ublokkert forespørsel lyktes, om navneoppslaget lyktes, og versjonene til klienten og operativsystemet. Det settet med fem fakta kan sammenlignes på tvers av utgivelser, noe et avsnitt prosa ikke kan.

Kjør den samme testen på nytt etter en klientoppdatering eller en profilendring, fordi blokkeringsatferd er en implementasjonsdetalj og den flytter seg. Poenget med registreringen er å legge merke til flyttingen før den blir en hendelse, ikke å sertifisere klienten én gang.