Test kill switch: měřte mezeru, ne jen opětovné připojení

Rychlé opětovné připojení dokazuje, že klient je rychlý. Zaznamenejte, co během mezery opustilo stroj, spolu se spouštěčem, který jste použili, jinak test změřil jen polovinu.

Opětovné připojení, které skončí za sekundu, vám říká, že klient je rychlý. Neříká, zda během výpadku tunelu něco uniklo. Opětovné připojení, které trvá minutu, vám říká, že klient je pomalý, a stále neříká, zda byl v mezeře povolen přímý provoz. To jsou dvě měření a test kill switch, který hlásí jen první z nich, přepínač neotestoval.

Dvě pozorování, dva oddělené verdikty

Otázka dostupnosti je jednoduchá: kdy byl tunel znovu použitelný a potřebovala chráněná aplikace nové připojení, aby se tam dostala. Otázka vynucení je jiná: které pakety opustily stroj mezi okamžikem, kdy ochrana spadla, a okamžikem, kdy se vrátila.

Odpovězte na ně oddělenými záznamy. Jeden řádek říká, že mezera trvala určitý počet sekund. Jiný řádek říká, zda během této mezery uspěl nechráněný požadavek. Sloučení do jediného prošlo či neprošlo skrývá případ, na kterém záleží nejvíc: rychlé opětovné připojení s únikem.

Postavte sondu, kterou můžete změřit

Použijte požadavek, který je neškodný, levný a nezávislý na vlastním řídicím kanálu tunelu. Smyčka níže vypisuje časové razítko, stav HTTP a uplynulý čas jednou za sekundu a místo zaseknutí hlasitě selže:

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

Čtěte návratové kódy curl, ne jen stav. 28 znamená, že požadavku vypršel čas, tak vypadá blokovaná cesta. 6 znamená, že selhalo překlad jmen, což je jiné zjištění a často to zajímavější. 200 s krátkým uplynulým časem během mezery znamená, že provoz směl ven.

Zapište výstup do souboru a uchovejte ho. Historie terminálu není důkaz a zajímavá část jsou obvykle tři řádky uprostřed.

Vyvolejte skutečnou poruchu, ne uklizenou

Odpojení z vlastní nabídky klienta testuje kooperativní cestu, kdy má klient čas nainstalovat svá pravidla blokování. Zabijte místo toho proces nebo přetrhněte podkladové spojení a testujete cestu, kterou jde skutečná porucha.

Každý spouštěč procvičuje jinou cestu kódu. Výpadek na straně serveru, ztráta místního spojení a pád klienta mohou zanechat různý stav a jeden z nich je pravděpodobně případ, na který nakonec narazíte. Spusťte sondu alespoň při dvou spouštěčích a výsledky označte podle spouštěče.

Čtěte log a hledejte, jak vypadá povolený provoz

200 nebo rychlé selhání spojení během mezery je únik, ať už ukazuje kterýmkoli směrem. Vypršení časového limitu po celou mezeru je očekávaný tvar blokovací politiky. Úspěšný překlad jmen při selhávajících spojeních naznačuje, že překladač je stále dostupný, což je únik jiného druhu.

Stávající sockety vyžadují péči. Program může dál používat spojení otevřené před odpojením, takže zdánlivě živý provoz nemusí dokazovat, že nová cesta byla povolena. Seznam socketů ukazuje, zda spojení vzniklo před událostí:

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

Porovnejte čas spuštění socketu s časovým razítkem odpojení. Spojení starší než výpadek je důkazem znovupoužití socketu, ne úniku, a jeho nahlášení jako selhání pošle dalšího člověka hledat chybu, která neexistuje.

Zaznamenejte výsledek ve formě, která přežije aktualizaci

Zapište spouštěč, mezeru v sekundách, zda uspěl nějaký neblokovaný požadavek, zda uspěl překlad jmen a verze klienta a operačního systému. Tato sada pěti faktů se dá porovnávat mezi verzemi, což odstavec prózy nedokáže.

Spusťte stejný test znovu po aktualizaci klienta nebo změně profilu, protože chování blokování je implementační detail a posouvá se. Smyslem záznamu je všimnout si posunu dřív, než se stane incidentem, ne certifikovat klienta jednou provždy.

Související články