OpenVPN envia DNS, però és possible que el resolutor no ho vegi mai

El registre del client mostra el servidor DNS enviat, el túnel està connectat i un nom intern continua sense resoldre’s. No hi ha res trencat en l’enviament. L’opció va arribar i el resolutor del sistema operatiu no la va fer servir mai, perquè en la majoria de clients Unix OpenVPN lliura el valor i deixa l’aplicació a la plataforma.

El símptoma: el registre mostra DNS i els noms continuen fallant

OpenVPN dhcp-option transporta DNS i informació de domini, i el client registra què ha rebut. En algunes implementacions el client aplica aquests paràmetres internament; en d’altres els exporta perquè els consumeixi un script d’integració o un servei de xarxa. La línia del registre descriu només la primera meitat de la història. La segona meitat passa en un lloc que el client no controla. És allà on sol viure la fallada.

Per això un túnel connectat i un nom intern que falla conviuen tan sovint. El valor hi és, el consumidor falta o està mal configurat, i el resolutor continua utilitzant en silenci el servidor públic que feia servir abans de la connexió.

Rebut no és aplicat

Un client pot registrar un valor DNS enviat mentre el resolutor del sistema continua sent propietat d’un altre servei. Un navegador també pot tenir la seva pròpia política de DNS xifrat que eviti del tot el resolutor del sistema, cosa que produeix la situació memorable en què una aplicació resol noms interns i una altra no.

Comproveu la integració compatible de la implementació en lloc de suposar que cada client Unix reescriu el mateix fitxer. Aquesta suposició és la raó per la qual la gent edita una configuració de resolutor que ningú no llegeix.

Trobeu el propietari del resolutor a cada plataforma

A Windows, la taula de política de resolució de noms pot dirigir sufixos concrets a servidors concrets, i el client VPN hi pot instal·lar regles. Comproveu la política, no només la llista DNS de l’adaptador. A Linux, NetworkManager o systemd-resolved poden ser propietaris de la configuració, i quin dels dos ho sigui determina què preservarà una reconnexió.

Llegiu l’estat efectiu amb l’eina que realment respon les consultes: resolvectl query internal.example.net en un amfitrió amb systemd-resolved, o l’equivalent de la plataforma. Després compareu aquesta resposta amb el servidor DNS que el registre del client diu que ha enviat.

Eviteu executar diversos serveis que sobreescriuen la configuració del resolutor sense coordinació. Dos propietaris produeixen un resultat que sembla intermitent, i cada reconnexió sembla arreglar-lo o trencar-lo a l’atzar.

Scripts i foreign_option

OpenVPN exporta les opcions enviades als scripts mitjançant variables anomenades foreign_option_N, i un script pot traduir-les en ordres de resolutor. Aquest arranjament és una integració compatible, no un comportament automàtic, i s’ha d’instal·lar i invocar al client.

Si depeneu d’un script, registreu-ne l’execució i l’estat de sortida. Un script que s’executa però falla en silenci deixa el mateix símptoma que cap script, i és més difícil de notar perquè la configuració sembla completa. Comproveu la sortida del script, no el fitxer del script. Un fitxer que existeix no és un script que s’hagi executat.

Proveu el nom, no el registre

Consulteu un nom d’amfitrió només intern des del client després de connectar-vos, després consulteu un nom públic i després comproveu quin servidor ha respost. En una configuració que funciona, les dues respostes vénen de llocs diferents i totes dues haurien de coincidir amb el disseny.

Si el nom es resol però el servei falla, passeu a l’encaminament i l’accés d’aplicacions en lloc de tornar a canviar el DNS. El manual d’OpenVPN documenta dhcp-option i l’entorn dels scripts; feu-lo servir per confirmar què s’espera que apliqui el vostre client abans d’editar un altre fitxer de resolutor.