Pritunls private DNS feiler? Legg til en smal resolver-rute

Private navn løses for alle på bedriftsnettet og utløper for alle på VPN-et. Resolveren svarer gatewayen, ruten dit finnes, og spørringen får likevel aldri noe svar. Det som mangler er ikke en annen offentlig resolver eller en bredere rute: det er en kildeadresse som den private DNS-serveren er villig til å svare på.

Bekreft at resolveren avviser klientbassenget ditt

Begynn med å bevise at feilen handler om kilden, ikke om rekkevidde. Fra en tilkoblet klient, spør den private resolveren direkte og se om forespørselen utløper eller kommer tilbake som en avvisning. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 som utløper mens den samme spørringen fra gatewayen lykkes, peker på en tilgangspolicy på resolveren. Et SERVFAIL-svar peker et helt annet sted, vanligvis på sonen eller videresenderen oppstrøms.

Noter klientens adresse før testingen. ip -4 addr show tun0 på klienten, eller lease-en som vises i konsollen, forteller deg hvilket basseng resolveren ser.

Bekreft deretter at stien i det hele tatt finnes. En rute som sender resolverens adresse inn i tunnelen er en forutsetning, ikke løsningen; hvis pakkene aldri kommer fram, blir kilde-policyen aldri konsultert. Sjekk det med ip route get 10.40.0.53 på klienten.

Legg til én vertsrute i stedet for å oversette alt

Pritunls veiledning for privat DNS beskriver det smale middelet: en NAT-aktivert /32-rute for resolverens adresse, med den adressen valgt som klientenes DNS-server. Ruten endrer kilden resolveren ser kun for DNS-trafikk. Applikasjonstrafikk beholder det kildebevarende designet du valgte for den.

Konfigurer den via serverens støttede ruteeier, etter å ha gjennomgått eksisterende ruter for overlapp. I eksempelet over er destinasjonen 10.40.0.53/32 med NAT aktivert, og klientbassenget forblir 10.90.0.0/24. Ikke oversett hele det private området for å fikse én tjeneste, fordi hver nedstrøms policy som er avhengig av klientens virkelige adresse vil begynne å se gatewayen i stedet. Bekreft adressen resolveren faktisk mottar ved å se på spørringsloggen under et testoppslag. En vertsrute alene beviser ingenting om oversettelse eller tillatelse.

Resolveren må fortsatt tillate den oversatte kilden på UDP og TCP, og svarene må kunne komme tilbake. Å endre kilden kan ikke skape en manglende sone eller post.

Bestem om serveren eller klienten sender spørringen

Pritunl dokumenterer også et DNS-proxyoppsett knyttet til VPN Client DNS Mapping, der serveren videresender oppstrøms spørringer for klienter. I den modellen tilhører oppstrømskilden serverens eget nettverkskontekst, og et unntak på klientsiden er feil løsning.

Identifiser hvilken modell som er aktiv før du legger til noe. Tre overlappende reparasjoner, en proxy, en overstyring av resolveren på klienten og et manuelt NAT-skript betyr vanligvis at ingen har fastslått: hvilken komponent som skal sende spørringen. Sjekk også bootstrap: en kun-privat resolver kan ikke være den eneste måten å finne endepunktet på før tunnelen finnes, og en permanent resolver-endring bør ikke overleve tilkoblingen.

Test et privat oppslag, ikke en offentlig nettside

Etter å ha brukt endringen og koblet til på nytt, inspiser klientens effektive resolver-konfigurasjon, og løs deretter et navn du vet bare finnes i den private sonen. dig intranet.example.net uten en eksplisitt server viser hva klienten faktisk bruker. Følg opp med en forespørsel til adressen det oppslaget returnerte, fordi oppslag og tjenestetilgang er separate trinn. En nettleser som laster offentlige nettsteder via DNS-over-HTTPS beviser ingenting om operativsystemets private resolver-sti. En offentlig sekundær resolver er heller ikke autoritet for en intern sone.

Skriv ned resolverens adresse, /32-ruten og klientens DNS-innstilling sammen i servernotatene. Halvparten av den konfigurasjonen gjenopprettet alene gjenskaper den opprinnelige feilen.

Til slutt, bekreft at tunnelen fortsatt ruter applikasjonens destinasjon etter at DNS lykkes. Rute, tjenestetilgang og autentisering forblir uavhengige av navneoppslag, og et fungerende oppslag sier ingenting om gjennomstrømning. Hvis den private siden er treg men løses, gjorde resolveren jobben sin og problemet flyttet til stien.