Pritunl sitt private DNS feilar? Legg til ei smal resolver-rute

Private namn vert løyste for alle på bedriftsnettet og går ut på tid for alle på VPN-et. Resolveren svarar gatewayen, ruta dit finst, og spørjinga får likevel aldri noko svar. Det som manglar er ikkje ein annan offentleg resolver eller ei breiare rute: det er ei kjeldeadresse som den private DNS-tenaren er villig til å svare på.

Stadfest at resolveren avviser klientbassenget ditt

Byrj med å prove at feilen handlar om kjelda, ikkje om rekkevidd. Frå ein tilkopla klient, spør den private resolveren direkte og sjå om førespurnaden går ut på tid eller kjem tilbake som ei avvising. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 som går ut på tid medan den same spørjinga frå gatewayen lukkast, peikar på ein tilgangspolicy på resolveren. Eit SERVFAIL-svar peikar ein heilt annan stad, vanlegvis på sona eller vidaresendaren oppstraums.

Noter adressa til klienten før testinga. ip -4 addr show tun0 på klienten, eller lease-en som vert vist i konsollen, fortel deg kva basseng resolveren ser.

Stadfest deretter at stien i det heile finst. Ei rute som sender resolveradressa inn i tunnelen er ein føresetnad, ikkje løysinga; om pakkane aldri kjem fram, vert kjelde-policyen aldri rådspurd. Sjekk det med ip route get 10.40.0.53 på klienten.

Legg til éi vertsrute i staden for å omsetje alt

Pritunl si rettleiing for privat DNS skildrar det smale middelet: ei NAT-aktivert /32-rute for resolveradressa, med den adressa vald som DNS-tenar for klientane. Ruta endrar kjelda resolveren ser berre for DNS-trafikk. Applikasjonstrafikk held på det kjeldebevarande designet du valde for han.

Konfigurer han via den støtta ruteeigaren til tenaren, etter å ha gått gjennom eksisterande ruter for overlapp. I dømet over er destinasjonen 10.40.0.53/32 med NAT aktivert, og klientbassenget held fram som 10.90.0.0/24. Ikkje omset heile det private området for å reparere éin teneste, fordi kvar nedstraums policy som er avhengig av den verkelege adressa til klienten vil byrje å sjå gatewayen i staden. Stadfest adressa resolveren faktisk mottek ved å sjå på spørjeloggen under eit testoppslag. Ei vertsrute åleine provar ingenting om omsetjing eller løyve.

Resolveren må framleis tillate den omsette kjelda på UDP og TCP, og svara må kunne kome tilbake. Å endre kjelda kan ikkje skape ei manglande sone eller post.

Avgjer om tenaren eller klienten sender spørjinga

Pritunl dokumenterer også eit DNS-proxyoppsett knytt til VPN Client DNS Mapping, der tenaren vidaresender oppstraums spørjingar for klientar. I den modellen høyrer oppstraumskjelda til tenaren sin eigen nettverkskontekst, og eit unntak på klientsida er feil løysing.

Identifiser kva modell som er aktiv før du legg til noko. Tre overlappande reparasjonar, ein proxy, ei overstyring av resolveren på klienten og eit manuelt NAT-skript betyr vanlegvis at ingen har fastslått: kva komponent som skal sende spørjinga. Sjekk også bootstrap: ein berre-privat resolver kan ikkje vere den einaste måten å finne endepunktet på før tunnelen finst, og ei permanent resolver-endring bør ikkje overleve tilkoplinga.

Test eit privat oppslag, ikkje ei offentleg nettside

Etter å ha brukt endringa og kopla til på nytt, inspiser den effektive resolver-konfigurasjonen til klienten, og løys deretter eit namn du veit berre finst i den private sona. dig intranet.example.net utan ein eksplisitt tenar viser kva klienten faktisk brukar. Følg opp med ein førespurnad til adressa det oppslaget returnerte, fordi oppslag og tenestetilgang er separate steg. Ein nettlesar som lastar offentlege nettstader via DNS-over-HTTPS provar ingenting om den private resolver-stien til operativsystemet. Ein offentleg sekundær resolver er heller ikkje autoritet for ei intern sone.

Skriv ned resolveradressa, /32-ruta og DNS-innstillinga til klienten saman i tenar-notata. Halvparten av den konfigurasjonen gjenoppretta åleine gjer den opphavlege feilen om att.

Til slutt, stadfest at tunnelen framleis rutar applikasjonsdestinasjonen etter at DNS lukkast. Rute, tenestetilgang og autentisering held fram som uavhengige av namneoppslag, og eit fungerande oppslag seier ingenting om gjennomstrøyming. Om den private sida er treg men vert løyst, gjorde resolveren jobben sin og problemet flytta til stien.