OpenVPN envía DNS, pero o teu resolutor pode que nunca o vexa

O rexistro do cliente mostra o servidor DNS enviado, o túnel está conectado e un nome interno segue sen resolverse. Nada está roto no envío. A opción chegou e o resolutor do sistema operativo nunca a usou, porque na maioría de clientes Unix OpenVPN entrega o valor e deixa a aplicación á plataforma.

O síntoma: o rexistro mostra DNS e os nomes seguen fallando

OpenVPN dhcp-option transporta información de DNS e de dominio, e o cliente rexistra o que recibiu. Nalgunhas implementacións o cliente aplica eses axustes internamente; noutras expórtaos para que os consuma un script de integración ou un servizo de rede. A liña do rexistro describe só a primeira metade da historia. A segunda metade ocorre nun lugar que o cliente non controla. É alí onde adoita vivir o fallo.

Por iso un túnel conectado e un nome interno que falla conviven tan a miúdo. O valor está presente, o consumidor falta ou está mal configurado, e o resolutor segue usando en silencio o servidor público que usaba antes da conexión.

Recibir non é aplicar

Un cliente pode rexistrar un valor DNS enviado mentres o resolutor do sistema segue sendo propiedade doutro servizo. Un navegador tamén pode ter a súa propia política de DNS cifrado que evite por completo o resolutor do sistema, o que produce a memorable situación na que unha aplicación resolve nomes internos e outra non.

Comproba a integración admitida da implementación en lugar de supor que todos os clientes Unix reescriben o mesmo ficheiro. Esa suposición é a razón pola que a xente edita unha configuración de resolutor que nada le.

Atopa o propietario do resolutor en cada plataforma

En Windows, a táboa de directivas de resolución de nomes pode dirixir sufixos concretos a servidores concretos, e o cliente VPN pode instalar regras alí. Comproba a directiva, non só a lista DNS do adaptador. En Linux, NetworkManager ou systemd-resolved poden ser donos da configuración, e cal dos dous o sexa determina que conservará unha reconexión.

Le o estado efectivo coa ferramenta que de verdade responde consultas: resolvectl query internal.example.net nun host con systemd-resolved, ou o equivalente da plataforma. Despois compara esa resposta co servidor DNS que o rexistro do cliente di que enviou.

Evita executar varios servizos que sobrescriban a configuración do resolutor sen coordinación. Dous propietarios producen un resultado que parece intermitente, e cada reconexión parece arranxalo ou rompelo ao azar.

Scripts e foreign_option

OpenVPN exporta as opcións enviadas aos scripts mediante variables chamadas foreign_option_N, e un script pode traducilas en ordes de resolutor. Ese arranxo é unha integración admitida, non un comportamento automático, e debe instalarse e invocarse no cliente.

Se dependes dun script, rexistra a súa execución e o seu estado de saída. Un script que se executa pero falla en silencio deixa o mesmo síntoma que non ter script, e é máis difícil de notar porque a configuración parece completa. Comproba a saída do script, non o ficheiro do script. Un ficheiro que existe non é un script que se executou.

Proba o nome, non o rexistro

Consulta un nome de host só interno desde o cliente despois de conectar, logo consulta un nome público e despois comproba que servidor respondeu. Nunha configuración que funciona, as dúas respostas veñen de lugares distintos e ambas deberían coincidir co deseño.

Se o nome se resolve pero o servizo falla, pasa a o enrutamento e o acceso de aplicacións en lugar de cambiar o DNS outra vez. O manual de OpenVPN documenta dhcp-option e a contorna de scripts; úsao para confirmar que se espera que aplique o teu cliente antes de editar outro ficheiro de resolutor.