Kill switch-test: mål gapet, ikkje berre attoppkoblinga

Ei attoppkobling som er ferdig på eit sekund, fortel deg at klienten er rask. Ho fortel ikkje om noko slapp ut medan tunnelen var nede. Ei attoppkobling som tek eit minutt, fortel deg at klienten er treg, og framleis ikkje om direkte trafikk var tillaten i gapet. Det er to målingar, og ein kill switch-test som berre rapporterer den fyrste, har ikkje testa brytaren.

To observasjonar, to separate dommar

Tilgjengelegheitsspørsmålet er enkelt: når vart tunnelen brukbar att, og trong den verna applikasjonen ei ny tilkopling for å kome dit. Handhevingsspørsmålet er annleis: kva pakkar forlét maskina mellom augneblinken då vernet fall og augneblinken då det kom tilbake.

Svar på dei med separate registreringar. Éi linje seier at gapet varte eit visst tal sekund. Ei anna linje seier om ein uvarna førespurnad lukkast i gapet. Å slå dei saman til eitt bestått eller ikkje bestått løyner tilfellet som tyder mest: ei rask attoppkobling med ein lekkasje.

Bygg ein sonde du kan tidfeste

Bruk ein førespurnad som er ufarleg, billeg og uavhengig av den eigne kontrollkanalen til tunnelen. Løkka nedanfor skriv ut eit tidsstempel, ein HTTP-status og forlopen tid éin gong i sekundet, og ho feilar høgt i staden 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 utgangskodane til curl, ikkje berre statusen. 28 tyder at førespurnaden gjekk ut på tid, slik ser ein blokkert veg ut. 6 tyder at namneoppslaget feila, noko som er eit anna funn og ofte det meir interessante. 200 med kort forlopen tid i gapet tyder at trafikken fekk lov å gå ut.

Skriv utdataa til ei fil og ta vare på henne. Rullehistoria i terminalen er ikkje bevis, og den interessante delen er vanlegvis tre linjer i midten.

Utløys ein ekte feil, ikkje ein ryddig ein

Å kople frå i menyen til klienten sjølv testar den samarbeidsvillige vegen, der klienten har tid til å installere blokkeringsreglane sine. Drep prosessen i staden, eller bryt den underliggjande lenka, og du testar vegen ein faktisk feil tek.

Kvar utløysar trenar ein annan kodeveg. Eit utfall på serversida, tap av lokal lenke og eit klientkrasj kan kvar for seg etterlate ulik tilstand, og ein av dei er truleg tilfellet du endar med å møte. Køyr sonden med minst to utløysarar og merk resultata etter utløysar.

Les loggen for å sjå korleis tillaten trafikk ser ut

200 eller ein rask tilkoplingsfeil i gapet er ein lekkasje, same kva retning han peikar. Tidsavbrot gjennom heile gapet er den venta forma til ein blokkeringspolicy. Namneoppslag som lukkast medan tilkoplingar feilar, tyder på at resolvaren framleis er nåbar, noko som er ein lekkasje av ein annan sort.

Eksisterande sockets krev varsemd. Eit program kan halde fram med å bruke ei tilkopling det opna før fråkoplinga, så tilsynelatande levande trafikk beviser kanskje ikkje at ein ny veg var tillaten. Socketlista viser om ei tilkopling er eldre enn hendinga:

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

Samanlikn starttida til socketen med tidsstempelet for fråkoplinga. Ei tilkopling eldre enn utfallet er bevis på gjenbruk av socket, ikkje på ein lekkasje, og å rapportere henne som ein feil sender neste person på jakt etter ein feil som ikkje finst.

Registrer resultatet i ei form som overlever ei oppdatering

Skriv ned utløysaren, gapet i sekund, om ein ublokkert førespurnad lukkast, om namneoppslaget lukkast, og versjonane til klienten og operativsystemet. Det settet med fem fakta kan samanliknast på tvers av utgjevingar, noko eit avsnitt prosa ikkje kan.

Køyr den same testen på nytt etter ei klientoppdatering eller ei profilendring, fordi blokkeringsåtferd er ein implementasjonsdetalj og han flyttar seg. Poenget med registreringa er å leggje merke til flyttinga før ho blir ei hending, ikkje å sertifisere klienten éin gong.