Pritunl’s privé-DNS werkt niet? Voeg een smalle resolver-route toe

Privénamen worden op het bedrijfsnetwerk voor iedereen opgelost en verlopen op de VPN voor iedereen. De resolver antwoordt de gateway, de route ernaartoe bestaat, en de query krijgt toch nooit antwoord. Wat ontbreekt is geen andere publieke resolver of een bredere route: het is een bronadres waarop de privé-DNS-server bereid is te antwoorden.

Bevestig dat de resolver je clientpool weigert

Begin met te bewijzen dat de fout over de bron gaat, niet over bereikbaarheid. Vraag vanaf een verbonden client de privé-resolver rechtstreeks en kijk of het verzoek verloopt of als weigering terugkomt. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 dat verloopt terwijl dezelfde query vanaf de gateway slaagt, wijst op een toegangsbeleid op de resolver. Een SERVFAIL-antwoord wijst op iets heel anders, meestal de zone of de upstream-forwarder.

Noteer het adres van de client vóór de test. ip -4 addr show tun0 op de client, of de lease die in de console wordt getoond, vertelt je welke pool de resolver ziet.

Bevestig daarna of het pad überhaupt bestaat. Een route die het resolveradres de tunnel in stuurt, is een voorwaarde, niet de oplossing; als pakketten nooit aankomen, wordt het bronbeleid nooit geraadpleegd. Controleer het met ip route get 10.40.0.53 op de client.

Voeg één hostroute toe in plaats van alles te vertalen

Pritunl’s richtlijn voor privé-DNS beschrijft het smalle middel: een NAT-route /32 voor het resolveradres, met dat adres gekozen als de DNS-server van de clients. De route verandert de bron die de resolver ziet alleen voor DNS-verkeer. Applicatieverkeer behoudt het bronbehoudende ontwerp dat je ervoor koos.

Configureer hem via de ondersteunde route-eigenaar van de server, nadat je bestaande routes op overlap hebt gecontroleerd. In het voorbeeld hierboven is de bestemming 10.40.0.53/32 met NAT ingeschakeld, en de clientpool blijft 10.90.0.0/24. Vertaal niet het hele privébereik om één dienst te repareren, want elk downstreambeleid dat op het echte adres van de client vertrouwt, gaat in plaats daarvan de gateway zien. Bevestig het adres dat de resolver werkelijk ontvangt door tijdens een testopzoeking zijn querylog te bekijken. Een hostroute alleen bewijst niets over vertaling of toestemming.

De resolver moet de vertaalde bron nog steeds toestaan op UDP en TCP, en zijn antwoorden moeten kunnen terugkeren. De bron wijzigen kan geen ontbrekende zone of record maken.

Bepaal of de server of de client de query verstuurt

Pritunl documenteert ook een DNS-proxyregeling gekoppeld aan VPN Client DNS Mapping, waarbij de server upstream-query’s voor clients doorstuurt. In dat model hoort de upstream-bron bij de eigen netwerkcontext van de server, en een uitzondering aan de clientkant is de verkeerde oplossing.

Stel vast welk model actief is voordat je iets toevoegt. Drie overlappende reparaties, een proxy, een overschrijving van de resolver op de client en een handmatig NAT-script betekenen meestal dat niemand heeft vastgesteld: welke component de query hoort te versturen. Controleer ook de bootstrap: een alleen-privé-resolver kan niet de enige manier zijn om het eindpunt te vinden voordat de tunnel bestaat, en een permanente resolverwijziging hoort de verbinding niet te overleven.

Test een privé-opzoeking, geen openbare webpagina

Nadat je de wijziging hebt toegepast en opnieuw hebt verbonden, inspecteer je de effectieve resolverconfiguratie van de client, en lost dan een naam op waarvan je weet dat die alleen in de privézone bestaat. dig intranet.example.net zonder expliciete server laat zien wat de client werkelijk gebruikt. Laat het volgen door een verzoek naar het adres dat die opzoeking teruggaf, want resolutie en diensttoegang zijn aparte stappen. Een browser die openbare sites via DNS-over-HTTPS laadt, bewijst niets over het privé-resolverpad van het besturingssysteem. Een openbare secundaire resolver is ook geen autoriteit voor een interne zone.

Noteer het resolveradres, de /32-route en de DNS-instelling van de client samen in de servernotities. De helft van die configuratie, alleen hersteld, reproduceert de oorspronkelijke fout.

Bevestig ten slotte dat de tunnel de applicatiebestemming nog steeds routeert nadat DNS slaagt. Route, diensttoegang en authenticatie blijven onafhankelijk van naamresolutie, en een werkende opzoeking zegt niets over doorvoer. Als de privépagina traag is maar wel wordt opgelost, heeft de resolver zijn werk gedaan en is het probleem naar het pad verschoven.