El DNS privat de Pritunl falla? Afegiu una ruta estreta per al resolutor

Els noms privats es resolen per a tothom a la xarxa corporativa i caduquen per a tothom a la VPN. El resolutor respon a la passarel·la, la ruta cap a ell existeix, i la consulta encara no rep mai cap resposta. El que falta no és un altre resolutor públic ni una ruta més àmplia: és una adreça d’origen a la qual el servidor DNS privat estigui disposat a respondre.

Confirmeu que el resolutor rebutja el vostre pool de clients

Comenceu demostrant que la fallada és d’origen, no d’abastabilitat. Des d’un client connectat, consulteu el resolutor privat directament i observeu si la petició caduca o torna com un rebuig. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 caducant mentre la mateixa consulta des de la passarel·la té èxit apunta a una política d’accés al resolutor. Una resposta SERVFAIL apunta a un lloc completament diferent, normalment a la zona o al reenviador superior.

Anoteu l’adreça del client abans de provar. ip -4 addr show tun0 al client, o la concessió mostrada a la consola, us diu quin pool veu el resolutor.

Després confirmeu que el camí existeix. Una ruta que envia l’adreça del resolutor al túnel és un requisit previ, no la solució; si els paquets no arriben mai, la política d’origen no es consulta. Comproveu-ho amb ip route get 10.40.0.53 al client.

Afegiu una ruta d’amfitrió en lloc de traduir-ho tot

La guia de DNS privat de Pritunl descriu el remei estret: una ruta /32 amb NAT activat per a l’adreça del resolutor, amb aquesta adreça seleccionada com a servidor DNS dels clients. La ruta canvia l’origen que veu el resolutor només per al trànsit DNS. El trànsit d’aplicacions conserva el disseny que preserva l’origen que hi heu triat.

Configureu-la a través del propietari de rutes admès del servidor, després de revisar les rutes existents per si hi ha solapaments. A l’exemple anterior la destinació és 10.40.0.53/32 amb NAT activat, i el pool de clients continua sent 10.90.0.0/24. No traduïu tot l’interval privat per arreglar un servei, perquè cada política posterior que depèn de l’adreça real del client començarà a veure la passarel·la en el seu lloc. Confirmeu l’adreça que el resolutor rep realment observant el seu registre de consultes durant una prova. Una ruta d’amfitrió sola no demostra res sobre la traducció ni el permís.

El resolutor encara ha de permetre l’origen traduït a UDP i TCP, i les seves respostes han de poder tornar. Canviar l’origen no pot crear una zona ni un registre que falti.

Decidiu si el servidor o el client envia la consulta

Pritunl també documenta un arranjament de proxy DNS lligat a VPN Client DNS Mapping, on el servidor reenvia consultes superiors pels clients. En aquest model, l’origen superior pertany al context de xarxa propi del servidor, i una excepció al costat del client és la solució equivocada.

Identifiqueu quin model és actiu abans d’afegir res. Tres reparacions superposades, un proxy, una substitució del resolutor al client i un script de NAT manual, normalment volen dir que ningú ha establert: quin component ha d’enviar la consulta. Comproveu també l’arrencada: un resolutor només privat no pot ser l’única manera de trobar el punt final abans que existeixi el túnel, i una modificació permanent del resolutor no hauria de sobreviure a la connexió.

Proveu una consulta privada, no una pàgina web pública

Després d’aplicar el canvi i tornar-vos a connectar, reviseu la configuració efectiva del resolutor del client, i després resoleu un nom que sabeu que només existeix a la zona privada. dig intranet.example.net sense servidor explícit mostra què fa servir realment el client. Seguiu-ho amb una petició a l’adreça que va retornar aquella consulta, perquè la resolució i l’accés al servei són passos separats. Un navegador que carrega llocs públics per DNS-over-HTTPS no demostra res sobre el camí del resolutor privat del sistema operatiu. Un resolutor secundari públic tampoc no és una autoritat per a una zona interna.

Anoteu l’adreça del resolutor, la ruta /32 i la configuració DNS del client juntes a les notes del servidor. La meitat d’aquesta configuració restaurada sola reprodueix la fallada original.

Finalment, confirmeu que el túnel encara encamina la destinació de l’aplicació després que el DNS tingui èxit. La ruta, l’accés al servei i l’autenticació continuen sent independents de la resolució de noms, i una consulta que funciona no diu res sobre el rendiment. Si la pàgina privada és lenta però es resol, el resolutor ha fet la seva feina i el problema s’ha mogut al camí.