Päättömässä laatikossa ei ole selainta avattavaksi eikä lukkoa katsottavaksi, joten tarkistuksen on oltava pyyntö, jonka vastauksen voi lukea. Se kuulostaa triviaalilta, kunnes huomaat, että yhtä ainoaa lähtöosoitteen tulosta käytetään laitteen sertifiointiin, vaikka laite ajaa tusinaa palvelua, kahta osoiteperhettä ja välityspalvelinta. Seuraava läpikäynti rakentaa yhden rajatun todisteen kerrallaan, samassa kontekstissa jossa työkuorma todella toimii.

Päätä, mitä testin on todistettava

Ennen kuin ajat mitään, kirjoita odotus yhdelle riville: mikä virtaus, minkä liittymän kautta, mihin kohteeseen ja mitä toisessa päässä pitäisi havaita. Testi ilman ilmaistua odotusta tuottaa luvun, jota kukaan ei osaa tulkita.

Hyödyllisin versio nimeää hyväksytyn päätepisteen, joka raportoi näkemänsä lähdeosoitteen.

Tuo päätepiste on ainoa osa, joka sinun on järjestettävä. Kaikki muu on asiakaspuolen havainto, ja asiakaspuolen havainnot menevät pieleen kiinnostavilla tavoilla.

Suorita havainto oikeassa kontekstissa

Järjestelmänvalvojan kuori ei ole työkuorman ympäristö. Siinä voi olla eri välityspalvelinmuuttuja, eri reititystaulukko toisessa nimiavaruudessa tai toisen käyttäjän ympäristötiedosto. Suorita testi samassa isännän, kontin, nimiavaruuden tai palvelun kontekstissa kuin tarkistettava asia. Muuten mittaat omaa kuortasi.

Tavallisella isännällä se tarkoittaa samaa käyttäjää ja samaa yksikköä. Konttiympäristössä se tarkoittaa kontin verkkonimiavaruuteen menemistä isännältä testaamisen sijaan. systemd-palvelussa se voi tarkoittaa tilapäistä yksikköä, jolla on samat asetukset.

Seuraava pyyntö on merkityksellinen vasta, kun olet oikeassa kontekstissa.

Tarkista osoiteperheet erikseen

Pyydä jokaista perhettä nimenomaisesti, koska onnistunut IPv4-pyyntö ei harjoita IPv6-polkua lainkaan. Valitsimet --ipv4 ja --ipv6 pakottavat valinnan, ja kahden tuloksen ero on itsessään tietoa.

curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-source

Epäonnistunut IPv6-pyyntö ei ole todiste tehokkaasta estosta. Se voi tarkoittaa, että päätepisteellä ei ole IPv6-osoitetta, että DNS ei palauttanut mitään käyttökelpoista tai että laitteella ei ole lainkaan IPv6-reittiä. Lue epäonnistuminen ennen johtopäätöksen tekemistä. Onnistunut IPv6-pyyntö tunnelin läpi on ainoa tulos, joka todistaa, että IPv6-polku on katettu.

Kirjaa molemmat vastaukset rinnakkain. Yksi niistä yksin on puolet tosiseikasta.

Lisää neljä asiaa, jotka lähtötarkistus jättää huomaamatta

Lähtöosoite vastaa yhteen kysymykseen. Neljä muuta ratkaisevat, käyttäytyykö tunneli suunnitellusti.

CheckWhat it provesWhat it does not
Included and excluded destinationsThe split behaves as designed for those flowsCoverage of any other destination
Resolver pathWhere a fresh lookup actually travelledWhere a cached answer came from
Tunnel-down behaviourThe failure policy for a new requestWhat an already open connection does
Reconnect and restartThe requirement survives the lifecycle eventBehaviour under load or partial failure

Kohdepolitiikka tulee ensin: testaa virtaus, joka pitäisi sisällyttää, ja virtaus, joka pitäisi jättää pois, kun suunnitelmassa on jaottelu. Sitten DNS, jossa tarkastelet todellista ratkaisijan polkua etkä asetettua arvoa, koska välimuistiin jäänyt vastaus tai tulostettu asetus ei kerro mitään siitä, minne uusi kysely meni.

Virhetilakäyttäytyminen tarvitsee suunnitelman ja säilytetyn palautumispolun. Havainnoi uutta pyyntöä, kun tunneli ei ole saatavilla, ja muista, että vanha avoin yhteys ei ole todiste virhepoliittisesta käytöksestä. Elinkaari tulee viimeisenä: toista havainto uudelleenyhdistämisen tai palvelun uudelleenkäynnistyksen jälkeen, jos nämä tapahtumat vaikuttavat vaatimukseen.

Kirjaa todisteita, ei tuomiota

Säilytä jokaisesta tuloksesta prosessin konteksti, kohde, osoiteperhe, aika ja havaittu lähde. Tämä joukko on rajattua todistetta harjoittamistasi virtauksista, ja se on puolustettavissa juuri siksi, että se kertoo, mitä se kattoi.

Se ei ole VPN-operaattorin tietueiden auditointi eikä sertifikaatti laitteen jokaiselle tulevalle sovellukselle.

Kirjoita rajat tuloksen viereen. Testi, joka ilmoittaa, mitä se ei kattanut, kestää katselmoinnin, kun taas väite laitteen vahvistamisesta ei kestä. Pidä curl-käsikirja käyttämiesi perhevalitsimien vieressä ja pidä nelirivinen taulukko tulosten kanssa.

Aiheeseen liittyvät artikkelit