Kill switchi test: mõõtke lünka, mitte ainult taasuhendust

Ühe sekundiga lõppev taasuhendus ütleb, et klient on kiire. See ei ütle, kas tunnel oli maas ja midagi pääses põgenema. Minuti võttev taasuhendus ütleb, et klient on aeglane, ja ikkagi ei ütle, kas lüngas lubati otsest liiklust. Need on kaks mõõtmist, ja kill switchi test, mis raporteerib ainult esimest, ei ole lülitit testinud.

Kaks tähelepanekut, kaks eraldi otsust

Kättesaadavuse küsimus on lihtne: millal muutus tunnel uuesti kasutatavaks ja kas kaitstud rakendus vajas sinna jõudmiseks uut ühendust. Jõustamise küsimus on teine: millised paketid lahkusid masinast hetkest, mil kaitse kadus, kuni hetkeni, mil see naasis.

Vastake neile eraldi kirjetega. Üks rida ütleb, et lünk kestis teatud arvu sekundeid. Teine rida ütleb, kas kaitsmata päring õnnestus selle lünga ajal. Nende liitmine üheks läbitud või kukutud tulemuseks peidab kõige olulisema juhtumi: kiire taasuhendus koos lekkega.

Ehitage sond, mida saate ajastada

Kasutage päringut, mis on ohutu, odav ja sõltumatu tunneli enda juhtkanalist. Allolev tsükkel prindib kord sekundis ajatempli, HTTP oleku ja kulunud aja ning ebaõnnestub valjult, selle asemel et rippuda:

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

Lugege curli väljumiskoode, mitte ainult olekut. 28 tähendab, et päringu aeg lõppes, selline näeb blokeeritud tee välja. 6 tähendab, et nimede lahendamine ebaõnnestus, mis on teine leid ja sageli huvitavam. 200 väikese kulunud ajaga lünga ajal tähendab, et liiklus lasti välja.

Kirjutage väljund faili ja hoidke seda. Terminali kerimisajalugu ei ole tõend, ja huvitav osa on tavaliselt kolm rida keskel.

Tekitage tõeline rike, mitte korralik

Kliendi enda menüüst lahtiühendamine testib koostöölist teed, kus kliendil on aega oma blokeerimisreeglid paigaldada. Tapa hoopis protsess või katkesta aluseks olev link, ja testid teed, mille tõeline rike võtab.

Iga päästik harjutab erinevat kooditeed. Serveripoolne katkestus, kohaliku lingi kadu ja kliendi krahh võivad jätta erineva oleku, ja üks neist on tõenäoliselt juhtum, millega lõpuks kokku puutute. Käivitage sond vähemalt kahe päästiku korral ja märgistage tulemused päästiku järgi.

Lugege logi, et näha, milline näeb välja lubatud liiklus

200 või kiire ühenduse ebaõnnestumine lünga ajal on leke, ükskõik mis suunas see osutab. Aegumised kogu lünga vältel on blokeerimispoliitika ootuspärane kuju. Nimede lahendamine, mis õnnestub samal ajal kui ühendused ebaõnnestuvad, viitab sellele, et lahendaja on endiselt kättesaadav, mis on teist tüüpi leke.

Olemasolevad soketid nõuavad hoolt. Programm võib jätkata ühenduse kasutamist, mille see avas enne lahtiühendamist, nii et näiliselt elav liiklus ei pruugi tõestada, et uus tee oli lubatud. Soketite loend näitab, kas ühendus on sündmusest vanem:

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

Võrrelge soketi algusaega lahtiühendamise ajatempliga. Katkestusest vanem ühendus on tõend soketi korduskasutuse, mitte lekke kohta, ja selle rikkena raporteerimine saadab järgmise inimese otsima viga, mida ei ole olemas.

Salvestage tulemus kujul, mis elab üle uuenduse

Kirjutage üles päästik, lünk sekundites, kas mõni blokeerimata päring õnnestus, kas nimede lahendamine õnnestus ning kliendi ja operatsioonisüsteemi versioonid. Seda viiest faktist koosnevat kogumit saab väljaannete vahel võrrelda, mida proosaparagrahv ei suuda.

Käivitage sama test uuesti pärast kliendi uuendust või profiili muutust, sest blokeerimiskäitumine on teostuse detail ja see liigub. Kirje mõte on märgata liikumist enne, kui sellest saab intsident, mitte kliendile üks kord sertifikaati anda.