Test kill switcha: mjerite prazninu, ne samo ponovno povezivanje

Ponovno povezivanje koje završi u sekundi kaže da je klijent brz. Ne kaže da li je nešto pobjeglo dok je tunel bio isključen. Ponovno povezivanje koje traje minutu kaže da je klijent spor, i dalje ne kaže da li je direktni saobraćaj bio dozvoljen u praznini. To su dva mjerenja, a test kill switcha koji izvještava samo prvo nije testirao prekidač.

Dva zapažanja, dvije odvojene presude

Pitanje dostupnosti je jednostavno: kada je tunel ponovo postao upotrebljiv i da li je zaštićenoj aplikaciji trebala nova veza da tamo stigne. Pitanje primjene je drugačije: koji su paketi napustili mašinu između trenutka kada je zaštita pala i trenutka kada se vratila.

Odgovorite na njih odvojenim zapisima. Jedan red kaže da je praznina trajala određeni broj sekundi. Drugi red kaže da li je nezaštićen zahtjev uspio tokom te praznine. Spajanje u jedno prošlo ili palo skriva slučaj koji je najvažniji: brzo ponovno povezivanje s curenjem.

Napravite sondu koju možete mjeriti

Koristite zahtjev koji je bezopasan, jeftin i nezavisan od vlastitog kontrolnog kanala tunela. Petlja ispod ispisuje vremensku oznaku, HTTP status i proteklo vrijeme jednom u sekundi i glasno pada umjesto da visi:

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

Čitajte izlazne kodove curl-a, a ne samo status. 28 znači da je zahtjev istekao, tako izgleda blokiran put. 6 znači da razrješavanje imena nije uspjelo, što je drugačiji nalaz i često zanimljiviji. 200 s malim proteklim vremenom tokom praznine znači da je saobraćaju dozvoljeno da izađe.

Zapišite izlaz u datoteku i sačuvajte je. Historija terminala nije dokaz, a zanimljivi dio je obično tri reda u sredini.

Izazovite stvarni kvar, a ne uredan

Isključivanje iz vlastitog menija klijenta testira kooperativni put, gdje klijent ima vremena da instalira svoja pravila blokiranja. Umjesto toga ubijte proces ili prekinite donju vezu, pa ćete testirati put kojim ide stvarni kvar.

Svaki okidač vježba drugačiji put kroz kod. Ispad na strani servera, gubitak lokalne veze i pad klijenta mogu ostaviti različito stanje, a jedan od njih je vjerovatno slučaj na koji ćete na kraju naići. Pokrenite sondu kroz najmanje dva okidača i označite rezultate po okidaču.

Čitajte zapisnik da vidite kako izgleda dozvoljeni saobraćaj

200 ili brz neuspjeh veze tokom praznine je curenje, u kojem god smjeru pokazivalo. Istekla vremena kroz cijelu prazninu očekivani su oblik politike blokiranja. Uspješno razrješavanje imena dok veze padaju sugerira da je razrješivač još dostupan, što je curenje druge vrste.

Postojeći soketi traže pažnju. Program može nastaviti koristiti vezu koju je otvorio prije isključenja, pa naizgled živ saobraćaj možda ne dokazuje da je novi put dozvoljen. Lista soketa pokazuje da li veza prethodi događaju:

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

Uporedite vrijeme početka soketa s vremenskom oznakom isključenja. Veza starija od ispada dokaz je ponovne upotrebe soketa, a ne curenja, i prijavljivanje kao neuspjeha šalje sljedeću osobu u lov na grešku koja ne postoji.

Zapišite rezultat u obliku koji preživi ažuriranje

Zapišite okidač, prazninu u sekundama, da li je neki neblokiran zahtjev uspio, da li je razrješavanje imena uspjelo, te verzije klijenta i operativnog sistema. Taj skup od pet činjenica može se porediti između izdanja, što paragraf proze ne može.

Ponovite isti test nakon ažuriranja klijenta ili promjene profila, jer je ponašanje blokiranja detalj implementacije i ono se pomjera. Smisao zapisa je primijetiti pomak prije nego postane incident, a ne certificirati klijent jednom.