Delt tunnel utelèt nettlesaren, ikkje DNS-spørjingane hans

Nettlesaren utelaten frå tunnelen, sida med offentleg IP stadfester at trafikken går ut via heimekoplinga, og den interne wikien opnar framleis ikkje. Namneoppslag gjekk ein annan stad, og den andre staden er vanlegvis resolvaren som VPN-en sette opp. Datastien og resolverstien er separate avgjerder i dei fleste design for delt tunnel. Kontroller kva nettlesaren faktisk brukte før du kallar utelatinga øydelagd.

Datastien og resolverstien skil seg

Ei utelating fjernar pakkane til eit program frå tunnelen, noko som er ei rute- og brannmuravgjerd på datastien. Namneoppslag er eit anna oppslag: ein prosess spør resolvaren til systemet, og den resolvaren avgjer kva tenar som får spørsmålet.

Båe kan vere tilsikta og ulike. Ein arbeidsutrulling kan halde interne namnerom hos bedriftsresolvaren medan han sender utvald offentleg surfing utanfor tunnelen, nettopp fordi interne namn ikkje vert løyste nokon annan stad. Det forvirrande tilfellet er det motsette: ein offentleg nettstad feilar fordi nettlesaren aldri spurde resolvaren utrullinga venta. Noter ruta og resolvaren separat, og halvparten av diskusjonane forsvinn.

Finn ut kva prosess som stiller spørsmålet

Ein nettlesar kan bruke resolvaren til systemet, sin eigen krypterte DNS-teneste eller ein resolver som operativsystemet tildeler per nettverk. Den første følgjer plattformpolitikken, den andre omgår politikken heilt, og den tredje avheng av kva lenkje spørjinga vert ruta 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 gjeldande konfigurasjon før du testar: kva lenkjer som ber DNS-tenarar, kva namnerom dei hevdar, og om ein politikk per namn overstyrer standarden. På Linux brukar delt DNS rutingsdomene; på Windows gjer tabellen for namneoppslagspolitikk det same for namnerom. Ingen av dei er synlege frå ei lekkasjetestside.

Avgjer kva resolver som ser kva namn

Skriv ned den tiltenkte tilordninga før du endrar noko: interne namn til bedriftsresolvaren, offentlege namn til tenesta politikken tillèt, og unntak med ein eigar. Utan den lista vert kvar etikett i lekkasjetesten ein politikkdebatt ingen kan avgjere.

Kontroller deretter innstillinga til nettlesaren sjølv, fordi kryptert DNS i ein nettlesar vert brukt før operativsystemet får spørjinga. Ein brukar som slo det på for å omgå ein captive portal, har stille overstyrt resolvaren utrullinga valde. Det er ei konfigurasjonsavgjerd og ikkje ein lekkasje, og ho fortener ei avgjerd, ikkje ei blokkeringsliste.

Ikkje skriv om kvart DNS-felt for å gjere éin testetikett grøn. Etiketten skildrar éi spørjing frå éin prosess på eitt tidspunkt.

Stadfest spørjing og tilkopling separat

Test dei to stiane uavhengig. Tilkoplingstesten viser dataruta, og resolvertesten viser kven som fekk namnet.

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

Spør resolvaren òg eksplisitt, slik at ein feil kan tilskrivast tenaren og ikkje stien. Start deretter nettlesaren på nytt og gjer det om att, fordi program bufrer negative svar, og ein gammal feil ser vedvarande ut.

Etter ei godkjend endring, noter dataruta og mottakaren av resolvaren som to separate linjer med datoen. Om åtferda kjem tilbake ved neste tilkopling, er profilen som leverer ho det som må rettast, ikkje nettlesaren.