Stadfest at ein delt tunnel verkar: eitt IP-resultat er ikkje ein test

Ei einsleg nettlesarside som viser ein IP-adresse, provar nesten ingenting om ein delt tunnel. Ei synleg adresse kan vere den rette av galen grunn, og ein utelukka flyt vert aldri prøvd av ho. Skriv ned det venta resultatet før du testar: kva applikasjon eller destinasjon som skal bruke tunnelen, kva som skal halde seg direkte, og kva som skal stoppe når tunnelen sviktar. Utan den planen ser kvart sannsynleg tal ut som suksess.

Myten: eit adresseoppslag provar dekning

IP-sjekken svarar på eitt spørsmål: kva omverda ser frå éin applikasjon på eitt tidspunkt. Han seier ingenting om eit internt prefiks, ein andre nettlesarprofil eller eit namn som skal løysast privat. Han seier heller ingenting om svikt, og det er den halvdelen av eit delt tunneldesign som ryker i produksjon.

Ei adresseside kan heller ikkje vise ruta, resolvaren eller sviktpolicyen. Handsame ho som éi observasjon, ikkje som ein dom.

Prøv ein inkludert flyt og ein utelukka

Send ei ufarleg førespurnad frå applikasjonen som skal inkluderast, eller til prefikset du ventar å rute gjennom tunnelen, og logg kjelde, destinasjon, adressefamilie og observert veg. Gjer det same for ein flyt som skal halde seg direkte. Den utelukka sida er den folk hoppar over, og det er det einaste provet på at delinga er medvite og ikkje tilfeldig. Ein hjelpeprosess kan bere ein eigen policyidentitet, så test i prosessen som eig 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 ein test i feil applikasjon vise det motsette av det designet tar sikte på. Skriv ned dei fire felta for begge sider før du dreg noka konklusjon.

Legg til DNS og svikttilfellet

Spør systemresolvaren og resolvaren appen brukar, og samanlikn så svara med utgangsadressa nettstaden rapporterer. Dei to laga kan vere usamde med vilje, og eitt nettlesaroppslag prøvar ikkje operativsystempolicyn. Eit skal gjer samanlikninga repeterbar: Bryt tunnelen med vilje, og lag så ei førespurnad nettlesaren ikkje har bufra; ei side servert frå bufferen fortel deg ingenting om kva veg reservevegen gjekk. Registrer kva som faktisk hende i staden for kva designet føresåg.

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

Ein delt tunnel som sviktar lukka og ein som sviktar open ser identiske ut til du bryt tunnelen med vilje. Registrer kva åtferd du observerte, ikkje kva du venta.

Gjenta etter at tilstanden har endra seg

Gjenta dei same observasjonane etter ei attoppkopling, eit nettverksbyte og ei relevant applikasjonsoppdatering. Ei lagra utelukking kan halde fram med å peike på ein veg eller ein applikasjonsidentitet som ikkje lenger finst, og designet sluttar stille å samsvare med dokumentasjonen. Dei tre hendingane er der delte tunnelar driv, og kvar av dei er billeg å teste på nytt. Ein test som berre køyrer éin gong ved utrullinga, skildrar ein konfigurasjon som ikkje lenger finst.

Om eit resultat avvik, finn regeleigaren og handsamingstrinnet før du endrar fleire innstillingar på ein gong. Å endre fem ting og observere eitt resultat er ikkje ein diagnose, det er ein ny konfigurasjon.

Kva resultatet skal slå fast

Knytt observasjonane til policyen og klientversjonen du faktisk testa. Målet er å vise at denne utrullinga samsvarar med dekninga ho hevdar, ikkje at kvar framtidig applikasjon vil vere privat. Det er ein smalare påstand, og det er den du faktisk kan grunngje med prov. Skriv påstanden, versjonen og firefeltresultata inn i endringsloggen.

Då kan den neste vurderaren sjå om designet endra seg eller testen gjorde det. Ein delt tunnel er stadfesta når begge sider, resolverdelinga og sviktåtferda samsvarar med det du skreiv ned i starten. Eitt IP-resultat stadfester ingen av dei.