Bekreft at en delt tunnel fungerer: ett IP-resultat er ikke en test

En enkelt nettleserside som viser en IP-adresse beviser nesten ingenting om en delt tunnel. En synlig adresse kan være den riktige av feil grunn, og en utelukket flyt blir aldri prøvd av den. Skriv ned det forventede resultatet før du tester: hvilken applikasjon eller destinasjon som skal bruke tunnelen, hvilken som skal holde seg direkte, og hva som skal stoppe når tunnelen svikter. Uten den planen ser ethvert sannsynlig tall ut som suksess.

Myten: et adresseoppslag beviser dekning

IP-sjekken svarer på ett spørsmål: hva omverdenen ser fra én applikasjon på ett tidspunkt. Den sier ingenting om et internt prefiks, en andre nettleserprofil eller et navn som skal løses privat. Den sier heller ingenting om svikt, og det er den halvdelen av et delt tunneldesign som ryker i produksjon.

En adresseside kan heller ikke vise ruten, resolveren eller sviktpolicyen. Behandle den som én observasjon, ikke som en dom.

Prøv en inkludert flyt og en utelukket

Send en ufarlig forespørsel fra applikasjonen som skal inkluderes, eller til prefikset du forventer å rute gjennom tunnelen, og logg kilde, destinasjon, adressefamilie og observert vei. Gjør det samme for en flyt som skal holde seg direkte. Den utelukkede siden er den folk hopper over, og det er det eneste beviset på at delingen er bevisst og ikke tilfeldig. En hjelpeprosess kan bære en egen policyidentitet, så test i prosessen som eier sockelen.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Derfor kan en test i feil applikasjon vise det motsatte av det designet tar sikte på. Skriv ned de fire feltene for begge sider før du trekker noen konklusjon.

Legg til DNS og svikttilfellet

Spør systemets resolver og resolveren appen bruker, og sammenlign deretter svarene med utgangsadressen nettstedet rapporterer. De to lagene kan være uenige med vilje, og ett nettleseroppslag prøver ikke operativsystemets policy. Et skall gjør sammenligningen repeterbar: Bryt tunnelen med vilje, og lag deretter en forespørsel nettleseren ikke har bufret; en side servert fra bufferen forteller deg ingenting om hvilken vei reserveveien tok. Registrer hva som faktisk skjedde i stedet for hva designet forutsa.

curl -s https://ifconfig.me
nslookup intranet.example

En delt tunnel som svikter lukket og en som svikter åpen ser identiske ut til du bryter tunnelen med vilje. Registrer hvilken atferd du observerte, ikke hvilken du forventet.

Gjenta etter at tilstanden har endret seg

Gjenta de samme observasjonene etter en gjenoppkobling, et nettverksbytte og en relevant applikasjonsoppdatering. En lagret utelukkelse kan fortsette å peke på en vei eller en applikasjonsidentitet som ikke lenger finnes, og designet slutter stille å samsvare med dokumentasjonen. De tre hendelsene er der delte tunneler driver, og hver av dem er billig å teste på nytt. En test som bare kjøres én gang ved utrulling beskriver en konfigurasjon som ikke lenger finnes.

Hvis et resultat avviker, finn regeleieren og behandlingstrinnet før du endrer flere innstillinger på en gang. Å endre fem ting og observere ett resultat er ikke en diagnose, det er en ny konfigurasjon.

Hva resultatet skal fastslå

Knytt observasjonene til policyen og klientversjonen du faktisk testet. Målet er å vise at denne utrullingen samsvarer med dekningen den hevder, ikke at enhver fremtidig applikasjon vil være privat. Det er en smalere påstand, og det er den du faktisk kan underbygge med bevis. Skriv påstanden, versjonen og firefeltresultatene inn i endringsloggen.

Da kan den neste anmelderen se om designet endret seg eller testen gjorde det. En delt tunnel er bekreftet når begge sider, resolverdelingen og sviktatferden samsvarer med det du skrev ned i starten. Ett IP-resultat bekrefter ingen av dem.