Delt tunnel utelater nettleseren, ikke DNS-spørringene dens

Nettleseren utelatt fra tunnelen, siden med offentlig IP bekrefter at trafikken går ut via hjemmeforbindelsen, og den interne wikien åpnes fortsatt ikke. Navneoppslag gikk et annet sted, og det andre stedet er vanligvis resolveren som VPN-en satte opp. Datastien og resolverstien er separate beslutninger i de fleste design for delt tunnel. Kontroller hvilken nettleseren faktisk brukte før du kaller utelatelsen ødelagt.

Datastien og resolverstien skilles

En utelatelse fjerner pakkene til et program fra tunnelen, noe som er en rute- og brannmurkonfigurasjon på datastien. Navneoppslag er et annet oppslag: en prosess spør systemets resolver, og den resolveren bestemmer hvilken server som mottar spørsmålet.

Begge kan være tilsiktet og forskjellige. En arbeidsutrulling kan holde interne navnerom hos bedriftsresolveren mens den sender utvalgt offentlig surfing utenfor tunnelen, nettopp fordi interne navn ikke løses opp noe annet sted. Det forvirrende tilfellet er det motsatte: et offentlig nettsted feiler fordi nettleseren aldri spurte resolveren som utrullingen forventet. Noter ruten og resolveren separat, og halvparten av diskusjonene forsvinner.

Finn ut hvilken prosess som stiller spørsmålet

En nettleser kan bruke systemets resolver, sin egen krypterte DNS-tjeneste eller en resolver som operativsystemet tildeler per nettverk. Den første følger plattformens policy, den andre omgår policyen helt, og den tredje avhenger av hvilken lenke spørringen rutes til.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Les gjeldende konfigurasjon før du tester: hvilke lenker som bærer DNS-servere, hvilke navnerom de hevder, og om en policy per navn overstyrer standarden. På Linux bruker delt DNS rutingsdomener; på Windows gjør tabellen for navneoppslagspolicy det samme for navnerom. Ingen av dem er synlige fra en lekkasjetestside.

Bestem hvilken resolver som ser hvilket navn

Skriv ned den tiltenkte tilordningen før du endrer noe: interne navn til bedriftsresolveren, offentlige navn til tjenesten policyen tillater, og unntak med en eier. Uten den listen blir hver etikett i lekkasjetesten en policydebatt ingen kan avgjøre.

Kontroller deretter nettleserens egen innstilling, fordi kryptert DNS i en nettleser brukes før operativsystemet mottar spørringen. En bruker som aktiverte det for å omgå en captive portal, har stille overstyrt resolveren utrullingen valgte. Det er en konfigurasjonsbeslutning og ikke en lekkasje, og den fortjener en beslutning, ikke en blokkeringsliste.

Ikke skriv om hvert DNS-felt for å gjøre én testetikett grønn. Etiketten beskriver én spørring fra én prosess på ett tidspunkt.

Verifiser spørring og tilkobling separat

Test de to stiene uavhengig. Tilkoblingstesten viser dataruten, og resolvertesten viser hvem som mottok navnet.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Spør resolveren også eksplisitt, slik at en feil kan tilskrives serveren og ikke stien. Start deretter nettleseren på nytt og gjenta, fordi programmer bufrer negative svar, og en gammel feil ser vedvarende ut.

Etter en godkjent endring, noter dataruten og mottakeren av resolveren som to separate linjer med datoen. Hvis virkemåten kommer tilbake ved neste tilkobling, er profilen som leverer den det som må rettes, ikke nettleseren.