Test kill stikala: merite vrzel, ne le ponovne povezave

Ponovna povezava, ki se konča v sekundi, vam pove, da je odjemalec hiter. Ne pove, ali je med izpadom tunela kaj ušlo. Ponovna povezava, ki traja minuto, vam pove, da je odjemalec počasen, in še vedno ne pove, ali je bil v vrzeli dovoljen neposreden promet. To sta dve meritvi, in test kill stikala, ki poroča le o prvi, stikala ni preizkusil.

Dve opažanji, dve ločeni sodbi

Vprašanje razpoložljivosti je preprosto: kdaj je bil tunel spet uporaben in ali je zaščitena aplikacija potrebovala novo povezavo, da je prišla tja. Vprašanje izvajanja je drugačno: kateri paketi so zapustili stroj od trenutka, ko je zaščita padla, do trenutka, ko se je vrnila.

Odgovorite nanju z ločenimi zapisi. Ena vrstica pove, da je vrzel trajala določeno število sekund. Druga vrstica pove, ali je v tej vrzeli uspela nezaščitena zahteva. Zlivanje v eno uspelo ali padlo skrije primer, ki je najpomembnejši: hitro ponovno povezavo z uhajanjem.

Zgradite sondo, ki jo lahko merite

Uporabite zahtevo, ki je neškodljiva, poceni in neodvisna od lastnega krmilnega kanala tunela. Spodnja zanka enkrat na sekundo izpiše časovni žig, status HTTP in pretečeni čas ter glasno odpove, namesto da bi se obesila:

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

Berite izhodne kode curl, ne le statusa. 28 pomeni, da je zahteva potekla, tako izgleda blokirana pot. 6 pomeni, da razreševanje imen ni uspelo, kar je druga ugotovitev in pogosto bolj zanimiva. 200 s kratkim pretečenim časom v vrzeli pomeni, da je promet smel ven.

Izpis zapišite v datoteko in jo shranite. Zgodovina terminala ni dokaz, zanimivi del pa so običajno tri vrstice v sredini.

Povzročite resnično okvaro, ne urejene

Odklop iz odjemalčevega lastnega menija preizkusi sodelovalno pot, kjer ima odjemalec čas namestiti svoja pravila blokiranja. Namesto tega ubijte proces ali pretrgajte spodnjo povezavo in preizkusili boste pot, po kateri gre resnična okvara.

Vsak sprožilec vadi drugo pot kode. Izpad na strani strežnika, izguba lokalne povezave in sesutje odjemalca lahko pustijo različno stanje, in eden od njih je verjetno primer, s katerim se boste na koncu srečali. Zaženite sondo z vsaj dvema sprožilcema in rezultate označite po sprožilcu.

Berite dnevnik, da vidite, kako izgleda dovoljen promet

200 ali hitra okvara povezave v vrzeli je uhajanje, v katero koli smer že kaže. Potekli časi skozi celotno vrzel so pričakovana oblika politike blokiranja. Uspešno razreševanje imen ob neuspešnih povezavah kaže, da je razreševalnik še dosegljiv, kar je uhajanje druge vrste.

Obstoječe vtičnice zahtevajo previdnost. Program lahko še naprej uporablja povezavo, ki jo je odprl pred odklopom, zato navidezno živi promet morda ne dokazuje, da je bila nova pot dovoljena. Seznam vtičnic pokaže, ali je povezava starejša od dogodka:

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

Primerjajte začetni čas vtičnice s časovnim žigom odklopa. Povezava, starejša od izpada, je dokaz ponovne uporabe vtičnice, ne uhajanja, in poročanje o njej kot o okvari pošlje naslednjo osebo iskat napako, ki ne obstaja.

Zabeležite rezultat v obliki, ki preživi posodobitev

Zapišite sprožilec, vrzel v sekundah, ali je uspela katera koli neblokirana zahteva, ali je uspelo razreševanje imen ter različici odjemalca in operacijskega sistema. Ta nabor petih dejstev je mogoče primerjati med izdajami, česar odstavek proze ne zmore.

Znova zaženite isti test po posodobitvi odjemalca ali spremembi profila, ker je vedenje blokiranja podrobnost izvedbe in se premika. Smisel zapisa je opaziti premik, preden postane incident, ne pa enkrat potrditi odjemalca.