Pritunl privat DNS fejler? Tilføj en smal resolver-rute

Private navne opløses for alle på virksomhedsnetværket og løber ud for alle på VPN’et. Resolveren svarer gatewayen, ruten dertil findes, og forespørgslen får stadig aldrig noget svar. Det, der mangler, er ikke endnu en offentlig resolver eller en bredere rute: det er en kildeadresse, som den private DNS-server er villig til at svare på.

Bekræft, at resolveren afviser din klientpulje

Start med at bevise, at fejlen handler om kilden, ikke om rækkevidde. Fra en tilsluttet klient skal du spørge den private resolver direkte og se, om anmodningen løber ud eller kommer tilbage som en afvisning. dig @10.40.0.53 intranet.example.net +time=2 +tries=1, der løber ud, mens den samme forespørgsel fra gatewayen lykkes, peger på en adgangspolitik på resolveren. Et SERVFAIL-svar peger et helt andet sted hen, normalt på zonen eller den opstrøms videresender.

Notér klientens adresse før testen. ip -4 addr show tun0 på klienten, eller den lease, der vises i konsollen, fortæller dig, hvilken pulje resolveren ser.

Bekræft derefter, at stien overhovedet findes. En rute, der sender resolverens adresse ind i tunnelen, er en forudsætning, ikke løsningen; hvis pakkerne aldrig ankommer, bliver kildefortegnelsen aldrig konsulteret. Kontrollér det med ip route get 10.40.0.53 på klienten.

Tilføj én værtsrute i stedet for at oversætte alt

Pritunls vejledning til privat DNS beskriver det smalle middel: en NAT-aktiveret /32-rute til resolverens adresse, med den adresse valgt som klienternes DNS-server. Ruten ændrer den kilde, resolveren ser, kun for DNS-trafik. Applikationstrafik beholder det kildebevarende design, du valgte til den.

Konfigurér den via serverens understøttede ruteejer, efter du har gennemgået eksisterende ruter for overlapning. I eksemplet ovenfor er destinationen 10.40.0.53/32 med NAT aktiveret, og klientpuljen forbliver 10.90.0.0/24. Oversæt ikke hele det private område for at rette én tjeneste, fordi hver nedstrøms politik, der afhænger af klientens rigtige adresse, vil begynde at se gatewayen i stedet. Bekræft den adresse, resolveren faktisk modtager, ved at se dens forespørgselslog under et testopslag. En værtsrute alene beviser intet om oversættelse eller tilladelse.

Resolveren skal stadig tillade den oversatte kilde på UDP og TCP, og dens svar skal kunne vende tilbage. At ændre kilden kan ikke skabe en manglende zone eller post.

Beslut, om serveren eller klienten sender forespørgslen

Pritunl dokumenterer også et DNS-proxyarrangement knyttet til VPN Client DNS Mapping, hvor serveren videresender opstrøms forespørgsler for klienter. I den model tilhører opstrømskilden serverens egen netværkskontekst, og en undtagelse på klientsiden er den forkerte løsning.

Identificér, hvilken model der er aktiv, før du tilføjer noget. Tre overlappende reparationer, en proxy, en tilsidesættelse af resolveren på klienten og et manuelt NAT-script betyder normalt, at ingen har fastslået: hvilken komponent der skal sende forespørgslen. Kontrollér også bootstrap: en kun-privat resolver kan ikke være den eneste måde at finde endepunktet på, før tunnelen findes, og en permanent resolverændring bør ikke overleve forbindelsen.

Test et privat opslag, ikke en offentlig webside

Når du har anvendt ændringen og genoprettet forbindelsen, skal du inspicere klientens effektive resolver-konfiguration og derefter opløse et navn, du ved kun findes i den private zone. dig intranet.example.net uden en eksplicit server viser, hvad klienten faktisk bruger. Følg op med en anmodning til den adresse, som det opslag returnerede, fordi opløsning og tjenesteadgang er separate trin. En browser, der indlæser offentlige websteder via DNS-over-HTTPS, beviser intet om operativsystemets private resolver-sti. En offentlig sekundær resolver er heller ikke autoritet for en intern zone.

Skriv resolverens adresse, /32-ruten og klientens DNS-indstilling sammen i serverens noter. Den halvdel af konfigurationen, der gendannes alene, genskaber den oprindelige fejl.

Bekræft til sidst, at tunnelen stadig ruter applikationens destination, efter DNS lykkes. Rute, tjenesteadgang og godkendelse forbliver uafhængige af navneopløsning, og et fungerende opslag siger intet om gennemstrømning. Hvis den private side er langsom men opløses, gjorde resolveren sit arbejde, og problemet flyttede til stien.