Test kill switcha: mjerite prazninu, ne samo ponovno spajanje

Ponovno spajanje koje završi u sekundi govori da je klijent brz. Ne govori je li nešto pobjeglo dok je tunel bio isključen. Ponovno spajanje koje traje minutu govori da je klijent spor, i dalje ne govori je li izravni promet bio dopušten u praznini. To su dva mjerenja, a test kill switcha koji izvješćuje samo prvo nije testirao prekidač.

Dva zapažanja, dvije odvojene presude

Pitanje dostupnosti je jednostavno: kada je tunel ponovno postao upotrebljiv i je li zaštićenoj aplikaciji trebala nova veza da tamo stigne. Pitanje provedbe je drukčije: koji su paketi napustili računalo između trenutka kad je zaštita pala i trenutka kad se vratila.

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

Izgradite sondu koju možete mjeriti

Upotrijebite zahtjev koji je bezopasan, jeftin i neovisan o vlastitom kontrolnom kanalu 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 zahtjevu istekao rok, tako izgleda blokirani put. 6 znači da razrješavanje imena nije uspjelo, što je drukčiji nalaz i često zanimljiviji. 200 s malim proteklim vremenom tijekom praznine znači da je prometu dopušteno izaći.

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

Izazovite stvarni kvar, a ne uredan

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

Svaki okidač vježba drukčiji put kroz kod. Ispad na strani poslužitelja, gubitak lokalne veze i pad klijenta mogu ostaviti različito stanje, a jedan od njih vjerojatno je 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 dopušteni promet

200 ili brz neuspjeh veze tijekom 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 upućuje na to da je razrješivač još dostupan, što je curenje druge vrste.

Postojeći socketi traže pažnju. Program može nastaviti koristiti vezu koju je otvorio prije isključenja, pa naizgled živ promet možda ne dokazuje da je novi put bio dopušten. Popis socketa pokazuje je li veza prethodila događaju:

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

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

Zabilježite rezultat u obliku koji preživi ažuriranje

Zapišite okidač, prazninu u sekundama, je li neki neblokirani zahtjev uspio, je li razrješavanje imena uspjelo te verzije klijenta i operacijskog sustava. Taj skup od pet činjenica može se uspoređivati između izdanja, što odlomak proze ne može.

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