Testul kill switch: măsurați golul, nu doar reconectarea

O reconectare care se termină într-o secundă vă spune că clientul este rapid. Nu vă spune dacă ceva a scăpat cât timp tunelul a fost jos. O reconectare care durează un minut vă spune că clientul este lent și tot nu vă spune dacă traficul direct a fost permis în gol. Sunt două măsurători, iar un test kill switch care raportează doar prima nu a testat comutatorul.

Două observații, două verdicte separate

Întrebarea disponibilității este simplă: când a redevenit tunelul utilizabil și dacă aplicația protejată a avut nevoie de o conexiune nouă ca să ajungă acolo. Întrebarea aplicării este diferită: ce pachete au părăsit mașina între momentul în care protecția a căzut și momentul în care a revenit.

Răspundeți-le cu înregistrări separate. O linie spune că golul a durat un anumit număr de secunde. O altă linie spune dacă o cerere neprotejată a reușit în acel gol. Topirea lor într-un singur trecut sau picat ascunde cazul care contează cel mai mult: o reconectare rapidă cu o scurgere.

Construiți o sondă pe care o puteți cronometra

Folosiți o cerere inofensivă, ieftină și independentă de canalul de control propriu al tunelului. Bucla de mai jos afișează o marcă de timp, un status HTTP și timpul scurs o dată pe secundă și eșuează zgomotos în loc să se blocheze:

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

Citiți codurile de ieșire ale curl, nu doar statusul. Un 28 înseamnă că cererea a expirat, așa arată o cale blocată. Un 6 înseamnă că rezolvarea numelor a eșuat, ceea ce este o altă constatare și adesea cea mai interesantă. Un 200 cu timp scurs mic în timpul golului înseamnă că traficului i s-a permis să iasă.

Scrieți ieșirea într-un fișier și păstrați-l. Istoricul terminalului nu este o dovadă, iar partea interesantă este de obicei trei linii la mijloc.

Provocați o defecțiune reală, nu una ordonată

Deconectarea din meniul propriu al clientului testează calea cooperativă, în care clientul are timp să-și instaleze regulile de blocare. Opriți în schimb procesul sau rupeți legătura de dedesubt și testați calea pe care merge o defecțiune reală.

Fiecare declanșator exersează o cale de cod diferită. O pană pe partea serverului, pierderea unei legături locale și o cădere a clientului pot lăsa stări diferite, iar unul dintre ele este probabil cazul în care veți ajunge. Rulați sonda cu cel puțin doi declanșatori și etichetați rezultatele după declanșator.

Citiți jurnalul ca să vedeți cum arată traficul permis

Un 200 sau o eșuare rapidă a conexiunii în timpul golului este o scurgere, în orice direcție ar arăta. Expirările pe tot parcursul golului sunt forma așteptată a unei politici de blocare. O rezolvare de nume care reușește în timp ce conexiunile eșuează sugerează că rezolvatorul este încă accesibil, ceea ce este o scurgere de alt tip.

Socketurile existente cer atenție. Un program poate continua să folosească o conexiune deschisă înainte de deconectare, așa că traficul aparent viu poate să nu dovedească faptul că o cale nouă a fost permisă. Lista de socketuri arată dacă o conexiune este mai veche decât evenimentul:

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

Comparați ora de început a socketului cu marca de timp a deconectării. O conexiune mai veche decât pană este dovada refolosirii socketului, nu a unei scurgeri, iar raportarea ei ca eșec trimite următoarea persoană să caute un bug care nu există.

Înregistrați rezultatul într-o formă care supraviețuiește unei actualizări

Notați declanșatorul, golul în secunde, dacă vreo cerere neblocată a reușit, dacă rezolvarea numelor a reușit și versiunile clientului și ale sistemului de operare. Acel set de cinci fapte poate fi comparat între versiuni, ceea ce un paragraf de proză nu poate.

Rulați din nou același test după o actualizare a clientului sau o schimbare de profil, pentru că comportamentul de blocare este un detaliu de implementare și se mișcă. Scopul înregistrării este să observați mișcarea înainte de a deveni un incident, nu să certificați clientul o dată.