Kill switch -testi: mittaa aukko, älä vain yhteyden palautumista

Sekunnissa valmistuva yhteyden palautuminen kertoo, että asiakas on nopea. Se ei kerro, pääsikö jotain karkaamaan tunnelin ollessa alhaalla. Minuutin kestävä palautuminen kertoo, että asiakas on hidas, eikä edelleenkään kerro, sallittiinko suoraa liikennettä aukossa. Nämä ovat kaksi mittausta, ja kill switch -testi, joka raportoi vain ensimmäisen, ei testannut kytkintä.

Kaksi havaintoa, kaksi erillistä tuomiota

Saatavuuskysymys on yksinkertainen: milloin tunnelista tuli taas käyttökelpoinen, ja tarvitsiko suojattu sovellus uuden yhteyden päästäkseen sinne. Toteutuskysymys on toinen: mitkä paketit lähtivät koneesta hetken, jolloin suojaus putosi, ja hetken, jolloin se palasi, välillä.

Vastaa niihin erillisillä kirjauksilla. Yksi rivi kertoo, että aukko kesti tietyn määrän sekunteja. Toinen rivi kertoo, onnistuiko suojaamaton pyyntö aukon aikana. Niiden yhdistäminen yhdeksi hyväksytyksi tai hylätyksi piilottaa tärkeimmän tapauksen: nopean palautumisen, johon liittyy vuoto.

Rakenna anturi, jonka voit ajoittaa

Käytä pyyntöä, joka on vaaraton, halpa ja riippumaton tunnelin omasta ohjauskanavasta. Alla oleva silmukka tulostaa aikaleiman, HTTP-tilan ja kuluneen ajan kerran sekunnissa, ja se epäonnistuu äänekkäästi sen sijaan että jäisi jumiin:

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

Lue curlin paluukoodit, älä vain tilaa. 28 tarkoittaa, että pyynnön aika loppui, sellaiselta estetty polku näyttää. 6 tarkoittaa, että nimien selvitys epäonnistui, mikä on eri löydös ja usein kiinnostavampi. 200 ja lyhyt kulunut aika aukon aikana tarkoittaa, että liikenne päästettiin ulos.

Kirjoita tuloste tiedostoon ja säilytä se. Päätteen vierityshistoria ei ole todiste, ja kiinnostava osa on yleensä kolme riviä keskellä.

Aiheuta todellinen vika, älä siistiä

Asiakkaan omasta valikosta irrottaminen testaa yhteistoiminnallisen polun, jossa asiakkaalla on aikaa asentaa estossäännöt. Tapa sen sijaan prosessi tai katkaise alla oleva linkki, niin testaat polun, jota todellinen vika kulkee.

Jokainen laukaisin harjoittaa eri koodipolkua. Palvelinpuolen katko, paikallisen linkin menetys ja asiakkaan kaatuminen voivat jättää erilaisen tilan, ja yksi niistä on todennäköisesti tapaus, johon lopulta törmäät. Aja anturi ainakin kahdella laukaisimella ja merkitse tulokset laukaisimen mukaan.

Lue lokia ja katso, miltä sallittu liikenne näyttää

200 tai nopea yhteysvirhe aukon aikana on vuoto, mihin suuntaan tahansa se osoittaa. Aikakatkokset koko aukon ajan ovat estävän käytännön odotettu muoto. Nimien selvitys, joka onnistuu yhteyksien epäonnistuessa, viittaa siihen, että selvittäjä on yhä tavoitettavissa, mikä on toisenlainen vuoto.

Olemassa olevat pistokkeet vaativat huolellisuutta. Ohjelma voi jatkaa ennen irrotusta avaamansa yhteyden käyttöä, joten näennäisesti elävä liikenne ei välttämättä todista, että uusi polku sallittiin. Pistokeluettelo näyttää, onko yhteys tapahtumaa vanhempi:

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

Vertaa pistokkeen aloitusaikaa irrotuksen aikaleimaan. Katkoa vanhempi yhteys on todiste pistokkeen uudelleenkäytöstä, ei vuodosta, ja sen raportoiminen vikana lähettää seuraavan ihmisen etsimään bugia, jota ei ole.

Tallenna tulos muotoon, joka kestää päivityksen

Kirjaa laukaisin, aukko sekunteina, onnistuiko jokin estämätön pyyntö, onnistuiko nimien selvitys sekä asiakkaan ja käyttöjärjestelmän versiot. Tätä viiden tosiasian joukkoa voi verrata julkaisujen välillä, mihin proosakappale ei pysty.

Aja sama testi uudelleen asiakaspäivityksen tai profiilin muutoksen jälkeen, koska estokäyttäytyminen on toteutuksen yksityiskohta ja se liikkuu. Kirjauksen tarkoitus on huomata liike ennen kuin siitä tulee incidentti, ei sertifioida asiakasta kerran.