Por que fallan os nomes DNS privados nos clientes VPN e onde revisar

Abres un portátil nunha habitación de hotel, arrincas o cliente, escribes o nome do servidor de ficheiros interno e non recibes nada. O túnel di conectado, e un ping a un enderezo dentro da mesma subrede segue respondendo, así que o transporte está ben. Só falla o nome, e ese oco reduce o problema a dous sitios: a que resolutor preguntou o cliente e se a resposta que obtivo pode volver polo túnel. Acerta un e omite o outro, e o fallo simplemente se despraza.

Antes de editar calquera perfil, confirma que fai o cliente co nome. En Linux, resolvectl query files.corp.example mostra que enlace e que resolutor produciron a resposta. En Windows, Resolve-DnsName files.corp.example mostra o servidor que respondeu e o enderezo que devolveu.

Le a resposta antes de cambiar nada

Se o nome volve como NXDOMAIN nuns milisegundos, a consulta nunca chegou á túa zona e respondeu algún resolutor público ou do hotel. Se volve despois dunha pausa longa, algo está a descartar o porto UDP 53 polo camiño e o cliente acabou recorrendo a outro. Se responde co enderezo correcto pero a conexión segue atascada, a consulta está ben e o teu problema é o encamiñamento ou o propio servizo.

Esa división en tres aforra unha hora de conxecturas. Tamén che di se debes tocar a VPN: un nome que se resolve no enderezo privado correcto xa demostrou o camiño do resolutor, así que o traballo que queda está no camiño dos datos.

Reparte o resolutor desde dentro do túnel

Os clientes divídense en dous grupos. A un pódeselle indicar un resolutor desde o servidor durante o establecemento da conexión; o outro garda o axuste nun ficheiro local que ningunha pasarela pode cambiar en remoto.

OpenVPN está no primeiro grupo. No servidor, push "dhcp-option DNS 10.8.0.53" e push "dhcp-option DOMAIN corp.example" baixan polo canal de control, pero só se a configuración do cliente aínda ten pull activado. Un cliente editado a man que leve pull-filter ignore "dhcp-option" non os verá nunca, e esa soa liña explica un número sorprendente de casos de «o servidor empurra pero o meu portátil opina outra cousa».

WireGuard está no segundo grupo, porque o protocolo non ten ningunha negociación de opcións. O resolutor e o dominio de busca van no bloque [Interface] do propio cliente como DNS = 10.8.0.53, corp.example. wg-quick aplícao mediante resolvconf ou systemd-resolved, e en Windows o cliente oficial instala regras NRPT que só existen mentres o túnel está levantado: Get-DnsClientNrptPolicy enuméraas, o que o converte nunha forma rápida de ver se o cliente chegou a aplicar o teu ficheiro.

IPsec/IKEv2 queda no medio. O complemento attr de strongSwan pode devolver un servidor DNS sacado dun grupo, e un cliente Windows normalmente acéptao, pero un perfil que fixa o seu propio servidor de nomes gaña ao que ofreza a pasarela. Nun cliente Linux o paso manual equivalente é resolvectl dns wg0 10.8.0.53 seguido de resolvectl domain wg0 '~corp.example'; ambos desaparecen canda a interface, que é xusto o que queres para un axuste delimitado ao túnel.

Delimita o sufixo en vez de tragar cada consulta

Apuntar toda a lista de resolutores do cliente ao teu servidor interno é fácil e case sempre erróneo. Entón cada nome público resolve desde a saída do teu centro de datos, as CDN devolven enderezos afastados e unha caída do resolutor lévaa por diante a navegación do usuario.

Envía cara a dentro só o sufixo privado. En systemd-resolved, un dominio que comeza por ~ é só de encamiñamento, así que ~corp.example significa que as consultas baixo ese sufixo van aos servidores dese enlace mentres todo o demais segue usando a rede física. Windows fai o mesmo con regras NRPT delimitadas a un espazo de nomes, e macOS cun ficheiro de resolutor suplementario baixo /etc/resolver/.

Os nomes de multidifusión merecen a súa propia resposta. Os nomes .local son locais ao enlace por deseño (RFC 6762) e unha interface tun punto a punto non transporta ese grupo de multidifusión, así que engadir un resolutor público non os publica e preguntar por eles a un resolutor interno de unidifusión devolve NXDOMAIN. Un reflector como avahi en modo reflector pode unir dous segmentos, pero iso é unha decisión do lado do servidor que ningún cliente pode pedir. Se unha impresora ou un NAS ten que ser accesible por nome, dálle un rexistro A na túa zona.

Demostra que a resposta pode volver

Unha resposta correcta que apunta a un enderezo inalcanzable parece exactamente un problema de resolutor ata que comprobas a ruta. Pregúntalle ao núcleo a onde iría a resposta: ip route get 10.20.5.20 nomea a interface e, máis útil, o enderezo de orixe que usaría.

Vixía o enderezo do resolutor. Un cliente con DNS = 10.8.0.53 xunto a AllowedIPs = 10.20.0.0/16 envía as súas consultas pola NIC física, onde morren en silencio, porque o resolutor non está dentro de ningún prefixo que o túnel reivindique. Esa discordancia é o fallo de causa única máis común en toda esta área, e resulta invisible a non ser que compares o axuste de DNS cos prefixos permitidos liña por liña.

Os rangos solapados causan o fallo contrario. A resposta é correcta, a ruta existe e apunta ao host equivocado, porque 192.168.0.0/24 na casa é máis específica que a ruta do túnel ao mesmo rango. Renumera un lado ou empurra unha ruta máis estreita, e despois confirma a devasa e o camiño de volta do host do servizo; as notas de strongSwan sobre o reenvío cobren a parte sysctl desa ruta.

Os certificados son unha comprobación de identidade á parte que a xente lle achaca ao DNS. Se o navegador informa dun desaxuste de nome en vez dun erro de resolución, a consulta xa funcionou e o que hai que arranxar é o SAN do certificado. Proba HTTPS contra o nome, nunca contra a IP espida.

Volta probar desde o cliente, non desde a pasarela

Proba dentro da aplicación da que se queixa o usuario, porque unha consulta na liña de ordes non demostra que o navegador siga o mesmo camiño. O DNS seguro de Chrome e network.trr.mode de Firefox poden saltar o resolutor do sistema por completo, e cando o fan, un nome privado falla ou se filtra a un resolutor público. Comparar resolvectl query cun dig @10.8.0.53 files.corp.example executado a man diche cal das dúas cousas ocorreu.

Despois desconecta e volve conectar antes de dalo por arranxado. Os axustes aplicados a man a unha interface desaparecen coa interface, e un perfil que só parecía correcto por unha edición local esquecida fallará no seguinte arranque.

Unha lista curta para a seguinte máquina: o nome resolve polo resolutor do túnel, o sufixo está delimitado en vez de ser global, o enderezo do resolutor cae dentro dos prefixos permitidos, o host da resposta responde no porto do servizo e o certificado cobre o nome que escribiu o usuario.