Kill switch-test: mät gapet, inte bara återanslutningen

En återanslutning som blir klar på en sekund säger att klienten är snabb. Den säger inte om något slapp ut medan tunneln låg nere. En återanslutning som tar en minut säger att klienten är långsam, och fortfarande inte om direkt trafik var tillåten i gapet. Det är två mätningar, och ett kill switch-test som bara rapporterar den första har inte testat brytaren.

Två observationer, två separata domar

Tillgänglighetsfrågan är enkel: när blev tunneln användbar igen, och behövde det skyddade programmet en ny anslutning för att komma dit. Efterlevnadsfrågan är annorlunda: vilka paket lämnade maskinen mellan ögonblicket då skyddet föll och ögonblicket då det kom tillbaka.

Besvara dem med separata registreringar. En rad säger att gapet varade ett visst antal sekunder. En annan rad säger om en oskyddad begäran lyckades under gapet. Att slå ihop dem till ett enda godkänt eller underkänt döljer fallet som betyder mest: en snabb återanslutning med en läcka.

Bygg en sond du kan tidsmäta

Använd en begäran som är ofarlig, billig och oberoende av tunnelns egen kontrollkanal. Slingan nedan skriver ut en tidsstämpel, en HTTP-status och förfluten tid en gång i sekunden, och den misslyckas högljutt i stället för att hänga:

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 utgångskoder, inte bara statusen. 28 betyder att begäran tog slut på tid, så ser en blockerad väg ut. 6 betyder att namnmatchningen misslyckades, vilket är ett annat fynd och ofta det mer intressanta. 200 med kort förfluten tid under gapet betyder att trafiken släpptes ut.

Skriv utdata till en fil och spara den. Terminalens rullningshistorik är inte bevis, och den intressanta delen är oftast tre rader i mitten.

Utlös ett verkligt fel, inte ett prydligt

Att koppla från i klientens egen meny testar den samarbetsvilliga vägen, där klienten har tid att installera sina blockeringsregler. Döda i stället processen, eller bryt den underliggande länken, och du testar den väg ett verkligt fel tar.

Varje utlösare tränar en annan kodväg. Ett avbrott på serversidan, förlust av en lokal länk och en klientkrasch kan var och en lämna olika tillstånd, och en av dem är sannolikt det fall du till slut möter. Kör sonden med minst två utlösare och märk resultaten efter utlösare.

Läs loggen för att se hur tillåten trafik ser ut

En 200 eller ett snabbt anslutningsfel under gapet är en läcka, oavsett vilken riktning den pekar. Tidsgränser genom hela gapet är den förväntade formen av en blockeringspolicy. Namnmatchning som lyckas medan anslutningar misslyckas tyder på att resolvern fortfarande är nåbar, vilket är en läcka av annat slag.

Befintliga sockets kräver omsorg. Ett program kan fortsätta använda en anslutning som det öppnade före frånkopplingen, så till synes levande trafik bevisar kanske inte att en ny väg var tillåten. Socketlistan visar om en anslutning är äldre än händelsen:

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

Jämför socketens starttid med tidsstämpeln för frånkopplingen. En anslutning som är äldre än avbrottet är bevis på återanvändning av socket, inte på en läcka, och att rapportera den som ett fel skickar nästa person på jakt efter en bugg som inte finns.

Registrera resultatet i en form som överlever en uppdatering

Skriv ned utlösaren, gapet i sekunder, om någon icke-blockerad begäran lyckades, om namnmatchningen lyckades, och versionerna av klienten och operativsystemet. Den uppsättningen av fem fakta kan jämföras mellan utgåvor, vilket ett stycke prosa inte kan.

Kör samma test igen efter en klientuppdatering eller en profiländring, eftersom blockeringsbeteende är en implementeringsdetalj och den flyttar sig. Poängen med registreringen är att märka flytten innan den blir en incident, inte att certifiera klienten en gång.