Testo de kill switch: mezuru la breĉon, ne nur la rekonekton

Rapida rekonekto pruvas, ke la kliento estas rapida. Registru, kio forlasis la maŝinon dum la breĉo, kune kun la uzita ellasilo, alie la testo mezuris nur duonon.

Rekonekto, kiu finiĝas en sekundo, diras al vi, ke la kliento estas rapida. Ĝi ne diras, ĉu io eskapis dum la tunelo estis malaktiva. Rekonekto, kiu daŭras minuton, diras al vi, ke la kliento estas malrapida, kaj ankoraŭ ne diras, ĉu rekta trafiko estis permesita en la breĉo. Tiuj estas du mezuroj, kaj testo de kill switch, kiu raportas nur la unuan, ne testis la ŝaltilon.

Du observoj, du apartaj verdiktoj

La demando pri havebleco estas simpla: kiam la tunelo denove fariĝis uzebla, kaj ĉu la protektita aplikaĵo bezonis novan konekton por atingi ĝin. La demando pri plenumado estas alia: kiuj pakaĵoj forlasis la maŝinon inter la momento, kiam la protekto falis, kaj la momento, kiam ĝi revenis.

Respondu al ili per apartaj registroj. Unu linio diras, ke la breĉo daŭris certan nombron da sekundoj. Alia linio diras, ĉu neprotektita peto sukcesis dum tiu breĉo. Kunfandi ilin en unu sola pasis aŭ malsukcesis kaŝas la kazon, kiu plej gravas: rapida rekonekto kun liko.

Konstruu sondilon, kiun vi povas tempigi

Uzu peton, kiu estas sendanĝera, malmultekosta kaj sendependa de la propra regkanalo de la tunelo. La buklo sube presas tempomarkon, HTTP-statusson kaj la pasintan tempon unufoje en sekundo, kaj ĝi malsukcesas laŭte anstataŭ pendi:

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

Legu la elirkodojn de curl, ne nur la statuson. 28 signifas, ke la peto tempolimis, tiel aspektas blokita vojo. 6 signifas, ke nomrezolucio malsukcesis, kio estas alia trovo kaj ofte la pli interesa. 200 kun mallonga pasinta tempo dum la breĉo signifas, ke oni permesis al trafiko eliri.

Skribu la eligon al dosiero kaj konservu ĝin. Terminala rulumhistorio ne estas pruvo, kaj la interesa parto kutime estas tri linioj meze.

Kaŭzu realan fiaskon, ne ordeman

Malkonekto el la propra menuo de la kliento testas la kooperan vojon, kie la kliento havas tempon instali siajn blokajn regulojn. Anstataŭe mortigu la procezon, aŭ rompu la suban ligon, kaj vi testas la vojon, kiun prenas reala fiasko.

Ĉiu ellasilo ekzercas alian kodvojon. Servila paneo, perdo de loka ligo kaj kraŝo de la kliento povas lasi malsaman staton, kaj unu el ili verŝajne estos la kazo, kiun vi fine renkontos. Rulu la sondilon ĉe almenaŭ du ellasiloj kaj etikedu la rezultojn laŭ ellasilo.

Legu la protokolon por vidi, kiel aspektas permesita trafiko

200 aŭ rapida konekta fiasko dum la breĉo estas liko, en kiun ajn direkton ĝi montras. Tempolimoj tra la tuta breĉo estas la atendata formo de bloka politiko. Sukcesa nomrezolucio dum konektoj malsukcesas sugestas, ke la solvilo ankoraŭ estas atingebla, kio estas liko de alia speco.

Ekzistantaj ingoj bezonas zorgon. Programo povas daŭre uzi konekton, kiun ĝi malfermis antaŭ la malkonekto, do ŝajne viva trafiko eble ne pruvas, ke nova vojo estis permesita. La ingolisto montras, ĉu konekto antaŭas la eventon:

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

Komparu la komencan tempon de la ingo kun la tempomarko de la malkonekto. Konekto pli malnova ol la paneo estas pruvo de reuzo de ingo, ne de liko, kaj raporti ĝin kiel fiaskon sendas la sekvan personon ĉasi cimon, kiu ne ekzistas.

Registru la rezulton en formo, kiu postvivas ĝisdatigon

Notu la ellasilon, la breĉon en sekundoj, ĉu iu neblokita peto sukcesis, ĉu nomrezolucio sukcesis, kaj la versiojn de la kliento kaj la operaciumo. Tiu aro de kvin faktoj estas komparebla inter eldonoj, kion paragrafo da prozo ne povas.

Relanu la saman teston post klienta ĝisdatigo aŭ profila ŝanĝo, ĉar bloka konduto estas efektiviga detalo kaj ĝi moviĝas. La senco de la registro estas rimarki la moviĝon antaŭ ol ĝi fariĝos incidento, ne atesti la klienton unufoje.

Rilataj artikoloj