Test kill switch: merajte medzeru, nie len opätovné pripojenie

Opätovné pripojenie, ktoré sa skončí za sekundu, vám povie, že klient je rýchly. Nepovie, či počas výpadku tunela niečo uniklo. Opätovné pripojenie, ktoré trvá minútu, vám povie, že klient je pomalý, a stále nepovie, či bol v medzere povolený priamy prenos. To sú dve merania a test kill switch, ktorý hlási len prvé z nich, prepínač neotestoval.

Dve pozorovania, dva oddelené verdikty

Otázka dostupnosti je jednoduchá: kedy bol tunel znova použiteľný a potrebovala chránená aplikácia nové pripojenie, aby sa tam dostala. Otázka vynútenia je iná: ktoré pakety opustili stroj od okamihu, keď ochrana spadla, do okamihu, keď sa vrátila.

Odpovedzte na ne oddelenými záznamami. Jeden riadok hovorí, že medzera trvala určitý počet sekúnd. Iný riadok hovorí, či počas tejto medzery uspel nechránený príkaz. Zlúčenie do jedného prešlo či neprešlo skrýva prípad, na ktorom záleží najviac: rýchle opätovné pripojenie s únikom.

Postavte sondu, ktorú môžete zmerať

Použite požiadavku, ktorá je neškodná, lacná a nezávislá od vlastného riadiaceho kanála tunela. Slučka nižšie vypisuje časovú značku, stav HTTP a uplynulý čas raz za sekundu a namiesto zaseknutia hlasno zlyhá:

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

Čítajte návratové kódy curl, nie len stav. 28 znamená, že požiadavke vypršal čas, tak vyzerá blokovaná cesta. 6 znamená, že rozlíšenie mien zlyhalo, čo je iné zistenie a často to zaujímavejšie. 200 s krátkym uplynulým časom počas medzery znamená, že prevádzka smela von.

Zapíšte výstup do súboru a uchovajte ho. História terminálu nie je dôkaz a zaujímavá časť sú zvyčajne tri riadky v strede.

Vyvolajte skutočnú poruchu, nie upratanú

Odpojenie z vlastnej ponuky klienta testuje kooperatívnu cestu, kde má klient čas nainštalovať svoje pravidlá blokovania. Namiesto toho zabite proces alebo prerušte podkladové spojenie a testujete cestu, ktorou ide skutočná porucha.

Každý spúšťač precvičuje inú cestu kódu. Výpadok na strane servera, strata lokálneho spojenia a pád klienta môžu zanechať rôzny stav a jeden z nich je pravdepodobne prípad, na ktorý nakoniec natrafíte. Spustite sondu aspoň pri dvoch spúšťačoch a výsledky označte podľa spúšťača.

Čítajte log a hľadajte, ako vyzerá povolená prevádzka

200 alebo rýchle zlyhanie spojenia počas medzery je únik, nech ukazuje ktorýmkoľvek smerom. Vypršanie času po celú medzeru je očakávaný tvar blokovacej politiky. Úspešné rozlíšenie mien pri zlyhávajúcich spojeniach naznačuje, že prekladač je stále dosiahnuteľný, čo je únik iného druhu.

Existujúce sockety si vyžadujú pozornosť. Program môže ďalej používať spojenie otvorené pred odpojením, takže zdanlivo živá prevádzka nemusí dokazovať, že nová cesta bola povolená. Zoznam socketov ukazuje, či spojenie vzniklo pred udalosťou:

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

Porovnajte čas spustenia socketu s časovou značkou odpojenia. Spojenie staršie ako výpadok je dôkazom opätovného použitia socketu, nie úniku, a jeho nahlásenie ako zlyhania pošle ďalšieho človeka hľadať chybu, ktorá neexistuje.

Zaznamenajte výsledok vo forme, ktorá prežije aktualizáciu

Zapíšte spúšťač, medzeru v sekundách, či uspel nejaký neblokovaný príkaz, či uspelo rozlíšenie mien a verzie klienta a operačného systému. Táto sada piatich faktov sa dá porovnávať medzi vydaniami, čo odsek prózy nedokáže.

Spustite ten istý test znova po aktualizácii klienta alebo zmene profilu, pretože správanie blokovania je implementačný detail a posúva sa. Zmyslom záznamu je všimnúť si posun skôr, než sa stane incidentom, nie certifikovať klienta raz navždy.