Il DNS privato di Pritunl non funziona? Aggiungete una rotta stretta per il resolver

I nomi privati si risolvono per tutti sulla rete aziendale e scadono per tutti sulla VPN. Il resolver risponde al gateway, la rotta verso di esso esiste, e la query continua a non ricevere mai risposta. Ciò che manca non è un altro resolver pubblico né una rotta più ampia: è un indirizzo di origine a cui il server DNS privato accetta di rispondere.

Confermate che il resolver rifiuta il vostro pool di client

Iniziate dimostrando che il guasto riguarda l’origine, non la raggiungibilità. Da un client connesso, interrogate direttamente il resolver privato e osservate se la richiesta scade o torna come rifiuto. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 che scade mentre la stessa query dal gateway riesce indica una politica di accesso sul resolver. Una risposta SERVFAIL indica tutt’altro, di solito la zona o il forwarder a monte.

Annotate l’indirizzo del client prima del test. ip -4 addr show tun0 sul client, o il lease mostrato nella console, vi dice quale pool vede il resolver.

Poi confermate che il percorso esista. Una rotta che manda l’indirizzo del resolver nel tunnel è un prerequisito, non la soluzione; se i pacchetti non arrivano mai, la politica di origine non viene mai consultata. Verificatelo con ip route get 10.40.0.53 sul client.

Aggiungete una rotta host invece di tradurre tutto

La guida DNS privata di Pritunl descrive il rimedio stretto: una rotta /32 con NAT per l’indirizzo del resolver, con quell’indirizzo scelto come server DNS dei client. La rotta cambia l’origine che il resolver vede solo per il traffico DNS. Il traffico delle applicazioni mantiene il progetto che preserva l’origine scelto per esso.

Configuratela tramite il proprietario delle rotte supportato dal server, dopo aver esaminato le rotte esistenti per sovrapposizioni. Nell’esempio sopra la destinazione è 10.40.0.53/32 con NAT attivo, e il pool di client resta 10.90.0.0/24. Non traducete l’intera gamma privata per correggere un solo servizio, perché ogni politica a valle che si basa sull’indirizzo reale del client inizierà a vedere il gateway al suo posto. Confermate l’indirizzo che il resolver riceve davvero osservando il suo registro delle query durante una ricerca di prova. Una rotta host da sola non dimostra nulla sulla traduzione o sul permesso.

Il resolver deve ancora consentire l’origine tradotta su UDP e TCP, e le sue risposte devono poter tornare. Cambiare l’origine non può creare una zona o un record mancante.

Decidete se è il server o il client a inviare la query

Pritunl documenta anche una configurazione di proxy DNS legata a VPN Client DNS Mapping, in cui il server inoltra le query a monte per i client. In quel modello l’origine a monte appartiene al contesto di rete proprio del server, e un’eccezione lato client è la soluzione sbagliata.

Identificate quale modello è attivo prima di aggiungere qualcosa. Tre riparazioni sovrapposte, un proxy, una sostituzione del resolver sul client e uno script NAT manuale di solito significano che nessuno ha stabilito: quale componente dovrebbe inviare la query. Verificate anche il bootstrap: un resolver solo privato non può essere l’unico modo per trovare l’endpoint prima che il tunnel esista, e una modifica permanente del resolver non dovrebbe sopravvivere alla connessione.

Provate una ricerca privata, non una pagina web pubblica

Dopo aver applicato la modifica e riconnesso, ispezionate la configurazione effettiva del resolver del client, poi risolvete un nome che sapete esistere solo nella zona privata. dig intranet.example.net senza un server esplicito mostra cosa usa davvero il client. Seguitelo con una richiesta all’indirizzo restituito da quella ricerca, perché risoluzione e accesso al servizio sono passaggi separati. Un browser che carica siti pubblici tramite DNS-over-HTTPS non dimostra nulla sul percorso del resolver privato del sistema operativo. Anche un resolver secondario pubblico non è un’autorità per una zona interna.

Annotate l’indirizzo del resolver, la rotta /32 e l’impostazione DNS del client insieme nelle note del server. Metà di quella configurazione ripristinata da sola riproduce il guasto originale.

Infine, confermate che il tunnel instradi ancora la destinazione dell’applicazione dopo il successo del DNS. Rotta, accesso al servizio e autenticazione restano indipendenti dalla risoluzione dei nomi, e una ricerca funzionante non dice nulla sul throughput. Se la pagina privata è lenta ma si risolve, il resolver ha fatto il suo lavoro e il problema si è spostato sul percorso.