Pritunls privata DNS misslyckas? Lägg till en smal resolver-rutt

Privata namn löses för alla på företagsnätet och löper ut för alla på VPN:en. Resolvern svarar gatewayen, rutten dit finns, och frågan får ändå aldrig något svar. Det som saknas är inte en annan offentlig resolver eller en bredare rutt: det är en källadress som den privata DNS-servern är villig att svara på.

Bekräfta att resolvern avvisar din klientpool

Börja med att bevisa att felet handlar om källan, inte om nåbarhet. Från en ansluten klient, fråga den privata resolvern direkt och se om begäran löper ut eller kommer tillbaka som en avvisning. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 som löper ut medan samma fråga från gatewayen lyckas pekar på en åtkomstpolicy på resolvern. Ett SERVFAIL-svar pekar någon helt annanstans, vanligtvis på zonen eller vidarebefordraren uppströms.

Notera klientens adress före testet. ip -4 addr show tun0 på klienten, eller lease som visas i konsolen, berättar vilken pool resolvern ser.

Bekräfta sedan att vägen överhuvudtaget finns. En rutt som skickar resolveradressen in i tunneln är en förutsättning, inte lösningen; om paketen aldrig kommer fram konsulteras aldrig källpolicyn. Kontrollera det med ip route get 10.40.0.53 på klienten.

Lägg till en värdrutt i stället för att översätta allt

Pritunls vägledning för privat DNS beskriver det smala medlet: en NAT-aktiverad /32-rutt för resolveradressen, med den adressen vald som klienternas DNS-server. Rutten ändrar källan resolvern ser endast för DNS-trafik. Applikationstrafik behåller den källbevarande design du valde för den.

Konfigurera den via serverns stödda ruttägare, efter att ha granskat befintliga rutter för överlappning. I exemplet ovan är destinationen 10.40.0.53/32 med NAT aktiverat, och klientpoolen förblir 10.90.0.0/24. Översätt inte hela det privata området för att fixa en tjänst, eftersom varje nedströms policy som förlitar sig på klientens verkliga adress börjar se gatewayen i stället. Bekräfta adressen resolvern faktiskt tar emot genom att titta på dess frågelogg under ett testuppslag. En värdrutt ensam bevisar ingenting om översättning eller tillstånd.

Resolvern måste fortfarande tillåta den översatta källan på UDP och TCP, och dess svar måste kunna komma tillbaka. Att ändra källan kan inte skapa en saknad zon eller post.

Bestäm om servern eller klienten skickar frågan

Pritunl dokumenterar också ett DNS-proxyarrangemang kopplat till VPN Client DNS Mapping, där servern vidarebefordrar uppströmsfrågor för klienter. I den modellen tillhör uppströmskällan serverns egen nätverkskontext, och ett undantag på klientsidan är fel lösning.

Identifiera vilken modell som är aktiv innan du lägger till något. Tre överlappande reparationer, en proxy, en överstyrning av resolvern på klienten och ett manuellt NAT-skript betyder vanligtvis att ingen har fastställt: vilken komponent som ska skicka frågan. Kontrollera även bootstrap: en enbart privat resolver kan inte vara det enda sättet att hitta slutpunkten innan tunneln finns, och en permanent resolverändring bör inte överleva anslutningen.

Testa ett privat uppslag, inte en offentlig webbsida

När du har tillämpat ändringen och återanslutit, granska klientens effektiva resolverkonfiguration och lös sedan upp ett namn du vet bara finns i den privata zonen. dig intranet.example.net utan en uttrycklig server visar vad klienten faktiskt använder. Följ upp med en begäran till adressen som det uppslaget returnerade, eftersom uppslagning och tjänståtkomst är separata steg. En webbläsare som laddar offentliga webbplatser via DNS-over-HTTPS bevisar ingenting om operativsystemets privata resolverväg. En offentlig sekundär resolver är inte heller auktoritet för en intern zon.

Skriv ned resolveradressen, /32-rutten och klientens DNS-inställning tillsammans i serverns anteckningar. Hälften av den konfigurationen återställd ensam återskapar det ursprungliga felet.

Bekräfta slutligen att tunneln fortfarande routar applikationens destination efter att DNS lyckas. Rutt, tjänståtkomst och autentisering förblir oberoende av namnmatchning, och ett fungerande uppslag säger ingenting om genomströmning. Om den privata sidan är långsam men löses upp gjorde resolvern sitt jobb och problemet flyttade till vägen.