DNS empès per OpenVPN ignorat: quin component l’aplica

El registre mostra l’opció que el servidor ha empès, el túnel està actiu i els noms interns continuen fallant. Una consulta directa al resolutor respon, així que el servidor està bé, però cada aplicació continua preguntant al router local. El que arriba al client és una oferta, no un canvi al resolutor, i el component que posseeix la resolució de noms difereix a Linux, Windows i macOS. Un cop separeu l’opció del seu propietari, quatre falles cobreixen gairebé tots els informes: cap hook, dos hooks en competència, DNS dividit funcionant tal com es va dissenyar, o un nom curt que necessita un sufix i no un servidor.

Una opció empesa és una oferta, no una instal·lació

Al servidor, dues directrius descriuen la intenció, no l’efecte:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

El client no rep un resolutor configurat. Rep variables d’entorn, foreign_option_1 i següents, una per cada línia empesa, i alguna cosa local les ha de llegir i reescriure l’estat del resolutor del sistema operatiu. A Linux, per defecte no ho fa res, i per això un servidor correcte i un client connectat encara poden resoldre a través de la LAN.

Hi ha tres etapes entre els dos extrems: el push ha de viatjar, el client l’ha d’exposar i un hook l’ha d’aplicar. Llegiu l’etapa intermèdia al registre del client i l’última a l’estat del resolutor, mai al revés, perquè una línia de registre només demostra les dues primeres.

Confirmeu que el push ha arribat i trobeu el propietari

Comenceu anomenant el llançador: una ordre openvpn nua, una instància de systemd, NetworkManager o un client de proveïdor. Això decideix on pot viure un hook. En un amfitrió amb systemd-resolved, resolvectl status llista cada enllaç amb els servidors DNS i els dominis de cerca que realment utilitza, i l’enllaç del túnel no sempre es diu tun0.

Si l’adreça empesa apareix al registre però no a cap enllaç, falta la integració. Si apareix a l’enllaç i les consultes encara surten per una altra banda, el problema és quines consultes seleccionen aquest enllaç. NetworkManager amb dns=dnsmasq a /etc/NetworkManager/NetworkManager.conf executa un reenviador local que implementa DNS dividit a propòsit: els noms dins del domini VPN van al resolutor VPN i tota la resta conserva el camí anterior. Aquest comportament sembla una falla quan esperàveu que tot el trànsit es mogués; reviseu la configuració per connexió amb nmcli connection show "My VPN", on ipv4.dns i ipv4.dns-search contenen els valors darrere del que informa el dispositiu, abans de qualificar-lo de trencat. Si realment totes les consultes han d’arribar al resolutor VPN, traieu dns=dnsmasq de NetworkManager.conf i reinicieu NetworkManager, cosa que retorna la resolució a la configuració de la connexió; en cas contrari, manteniu el DNS dividit i corregiu la llista de dominis empesos.

Linux: passeu les opcions al resolutor

Els paquets de les distribucions inclouen un hook per a això, i cal permetre que el client l’executi. Un muntatge típic en un amfitrió sense systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Amb systemd-resolved, l’script antic de resolv.conf pot no canviar res que importi, perquè el resolutor stub manté estat per enllaç. update-systemd-resolved documenta una forma de hook que utilitza up-restart i down-pre, cosa que importa quan una interfície sobreviu a un sol intent de connexió. Triïs el que triïs, un component ha de posseir l’estat. Afegir un hook no relacionat al costat de NetworkManager dona dos escriptors al mateix enllaç, i llavors el resultat depèn de l’ordre i no de la vostra configuració.

També hi ha el cas en què NetworkManager va ignorar del tot l’opció empesa fins que l’adreça del servidor es va introduir a la configuració IPv4 de la connexió, i després l’estat del resolutor va mostrar que s’utilitzava. Val la pena provar-ho abans de reescriure scripts, perquè trasllada el problema d’un hook de shell al perfil de connexió que ja porta el túnel.

Windows i macOS n’apliquen parts diferents

El client de Windows sí que defineix els servidors DNS de l’adaptador VPN, però Windows encara tria la interfície per mètrica i encara necessita un sufix per expandir un nom curt. Confirmeu l’estat de l’adaptador i no el perfil:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Si falta l’adreça, definiu-la amb Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, després afegiu el sufix a les propietats IPv4 de l’adaptador perquè fileserver esdevingui fileserver.corp.example. Un valor SearchList d’abast global sota Tcpip\Parameters fa el mateix. On el nom llarg es resol i el nom curt no, el resolutor ja és correcte i la culpa és de la llista de cerca. Les correccions, en ordre: empeneu un DOMAIN perquè el client aprengui el sufix, afegiu aquest sufix a la llista de cerca de l’adaptador o de la connexió, i com a mesura temporal fixeu el nom a hosts, o LMHOSTS a Windows; la navegació NetBIOS no travessa un router, així que la difusió que troba un nom curt a la LAN de l’oficina mai no arriba a un client de túnel.

block-outside-dns block-outside-dns és un comportament del client de Windows, no una línia de perfil portable, i copiar-lo a un perfil de Linux o macOS no el reprodueix allà. Si els noms públics funcionen i els interns fallen a Windows, compareu l’ordre d’adaptadors a Configuració avançada amb ipconfig /all. A macOS l’ordre de resolutors per servei pertany al sistema, així que feu servir scutil --dns per veure quin resolutor es consulta per a quin domini, i tracteu qualsevol correcció de perfil reportada com a dependent del client i no general.

Una màquina virtual al mateix portàtil no n’hereta res. Doneu al convidat la seva pròpia entrada de resolutor per al domini intern, o deixeu que el NAT de l’hipervisor reenviï les seves consultes a través de l’amfitrió, cosa que només és correcta mentre el túnel de l’amfitrió està actiu.

L’historial és la tercera causa. Servidors DNS o ajustos de sufix d’un perfil anterior poden sobreviure a reconnexions, així que quan l’adaptador sembla correcte i les cerques encara fallen, compareu l’adaptador viu amb Get-VpnConnection i esborreu o sobreescriviu l’entrada obsoleta abans de tocar el servidor.

Demostreu on ha anat la consulta

Una captura durant una cerca resol la discussió: tcpdump -ni eth0 port 53 mostra consultes a la interfície física, cosa que vol dir que surten fora del túnel i que el resolutor no es va canviar mai. dig @10.8.0.1 name.corp.example després separa els dos casos restants. Si la consulta directa respon, el resolutor funciona i el client no l’utilitza; si expira, el resolutor és inabastable pel túnel i cap canvi local no ajudarà.

Si el resolutor que encara s’utilitza és el que va repartir el proveïdor, el túnel xifra el trànsit mentre els noms continuen visibles per a aquest proveïdor. És una qüestió de fuita i no de funcionament, i la mateixa captura la respon: una consulta a la interfície física va a algú fora del túnel.

L’abast inclou el tallafoc de l’amfitrió VPN, que ha de permetre UDP i TCP 53 des del pool. Un port bloquejat sembla exactament un push trencat, i també un resolutor que només respon des de dins de la xarxa del túnel. Repetiu la captura després de desconnectar i reconnectar un cop, perquè els ajustos que apareixen a la primera connexió i desapareixen a la segona són una falla del cicle de vida del hook, no una opció absent.

Mantingueu un sol propietari i verifiqueu en ordre

Un script que reescriu el DNS de l’adaptador a partir d’un estat de túnel suposat duplica configuració que el perfil ja porta, i falla en silenci el primer cop que la suposició és errònia. Preferiu la configuració DNS pròpia de la connexió o un sol hook documentat, i anoteu quin heu triat perquè la persona següent no n’afegeixi un segon.

Tanqueu el bucle amb quatre comprovacions: l’adreça empesa present a l’enllaç del túnel, el nom intern resolent-se com a nom plenament qualificat, el mateix nom resolent-se sense el sufix, i totes dues encara certes després d’una reconnexió. Una captura us diu quina de les quatre ha fallat. El manual d’OpenVPN 2.6 llista dhcp-option i les directrius d’script amb les seves notes de plataforma.