DNS empuxado por OpenVPN ignorado: que compoñente o aplica

O rexistro mostra a opción que o servidor empuxou, o túnel está activo e os nomes internos seguen fallando. Unha consulta directa ao resolvedor responde, así que o servidor está ben, pero cada aplicación segue preguntando ao encamiñador local. O que chegou ao cliente é unha oferta, non un cambio no resolvedor, e o compoñente que posúe a resolución de nomes difire en Linux, Windows e macOS. Cando separa a opción do seu dono, catro fallos cobren case todos os informes: ningún hook, dous hooks en competencia, DNS dividido funcionando segundo o deseño, ou un nome curto que necesita un sufixo e non un servidor.

Unha opción empuxada é unha oferta, non unha instalación

No servidor, dúas directivas describen a intención, non o efecto:

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

O cliente non recibe un resolvedor configurado. Recibe variables de contorno, foreign_option_1 e seguintes, unha por cada liña empuxada, e algo local debe lelas e reescribir o estado do resolvedor do sistema operativo. En Linux nada o fai por defecto, por iso un servidor correcto e un cliente conectado poden seguir resolvendo pola LAN.

Entre os dous extremos hai tres etapas: o push debe viaxar, o cliente debe expolo e un hook debe aplicalo. Lea a etapa intermedia no rexistro do cliente e a última no estado do resolvedor, nunca ao revés, porque unha liña de rexistro só demostra as dúas primeiras.

Confirme que o push chegou e atope o dono

Comece nomeando o lanzador: un comando openvpn espido, unha instancia de systemd, NetworkManager ou un cliente do provedor. Iso decide onde pode vivir un hook. Nun host con systemd-resolved, resolvectl status enumera cada ligazón cos servidores DNS e os dominios de busca que realmente usa, e a ligazón do túnel non sempre se chama tun0.

Se o enderezo empuxado aparece no rexistro pero non en ningunha ligazón, falta a integración. Se aparece na ligazón e as consultas seguen saíndo por outro lado, o problema é que consultas seleccionan esa ligazón. NetworkManager dns=dnsmasq no ficheiro /etc/NetworkManager/NetworkManager.conf executa un reenviador local que implementa DNS dividido a propósito: os nomes dentro do dominio VPN van ao resolvedor VPN e todo o demais conserva a ruta anterior. Ese comportamento parece un fallo cando esperaba que se movese todo o tráfico; revise a configuración por conexión con nmcli connection show "My VPN", onde ipv4.dns e ipv4.dns-search garda os valores detrás do que informa o dispositivo, antes de chamalo roto. Se de verdade todas as consultas deben chegar ao resolvedor VPN, quite dns=dnsmasq de NetworkManager.conf e reinicie NetworkManager, o que devolve a resolución á configuración da conexión; doutro xeito, manteña o DNS dividido e corrixa a lista de dominios empuxados.

Linux: entregue as opcións ao resolvedor

Os paquetes das distribucións inclúen un hook para isto, e debe permitirse ao cliente executalo. Unha montaxe típica nun host sen systemd-resolved:

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

Con systemd-resolved, o script antigo de resolv.conf pode non cambiar nada importante, porque o resolvedor stub mantén estado por ligazón. update-systemd-resolved o axudante documenta unha forma de hook que usa up-restart e down-pre, o que importa cando unha interface sobrevive a un só intento de conexión. Escolla o que escolla, un compoñente debe posuír o estado. Engadir un hook alleo xunto a NetworkManager dá dous escritores á mesma ligazón, e entón o resultado depende da orde e non da súa configuración.

Tamén existe o caso en que NetworkManager ignorou por completo a opción empuxada ata que o enderezo do servidor se introduciu na configuración IPv4 da conexión, e despois o estado do resolvedor mostrou que estaba en uso. Paga a pena probalo antes de reescribir scripts, porque traslada o problema dun hook de shell ao perfil de conexión que xa leva o túnel.

Windows e macOS aplican partes distintas

O cliente de Windows si define os servidores DNS do adaptador VPN, pero Windows segue escollendo a interface por métrica e segue necesitando un sufixo para expandir un nome curto. Confirme o estado do adaptador e non o perfil:

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

Se falta o enderezo, defínao con Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, despois engada o sufixo ás propiedades IPv4 do adaptador para que fileserver se converta en fileserver.corp.example. Un valor SearchList de todo o equipo baixo Tcpip\Parameters fai o mesmo. Onde o nome longo resolve e o espido non, o resolvedor xa é correcto e a culpa é da lista de busca. As correccións, en orde: empuxe un DOMAIN para que o cliente aprenda o sufixo, engada ese sufixo á lista de busca do adaptador ou da conexión, e como medida temporal fixe o nome en hosts, ou LMHOSTS en Windows; a navegación NetBIOS non cruza un encamiñador, así que a difusión que atopa un nome curto na LAN da oficina nunca chega a un cliente de túnel.

block-outside-dns block-outside-dns é un comportamento do cliente de Windows, non unha liña de perfil portátil, e copialo a un perfil de Linux ou macOS non o reproduce alí. Se os nomes públicos funcionan e os internos fallan en Windows, compare a orde de adaptadores en Configuración avanzada con ipconfig /all. En macOS a orde de resolvedores por servizo pertence ao sistema, así que use scutil --dns para ver que resolvedor se consulta para que dominio, e trate calquera corrección de perfil reportada como dependente do cliente e non como xeral.

Unha máquina virtual no mesmo portátil non herda nada disto. Dea ao convidado a súa propia entrada de resolvedor para o dominio interno, ou deixe que o NAT do hipervisor reenvíe as súas consultas a través do host, o que só é correcto mentres o túnel do host está activo.

O historial é a terceira causa. Servidores DNS ou axustes de sufixo dun perfil anterior poden sobrevivir a reconexións, así que cando o adaptador parece correcto e as buscas seguen fallando, compare o adaptador vivo con Get-VpnConnection e borre ou sobrescriba a entrada obsoleta antes de tocar o servidor.

Demostre onde foi a consulta

Unha captura durante unha busca zanxa a discusión: tcpdump -ni eth0 port 53 mostra consultas na interface física, o que significa que saen fóra do túnel e que o resolvedor nunca se cambiou. dig @10.8.0.1 name.corp.example logo separa os dous casos restantes. Se a consulta directa responde, o resolvedor funciona e o cliente non o usa; se expira, o resolvedor é inalcanzable polo túnel e ningún cambio local axudará.

Se o resolvedor que aínda se usa é o que repartiu o provedor, o túnel cifra o tráfico mentres os nomes seguen visibles para ese provedor. É unha cuestión de fuga e non de funcionamento, e a mesma captura responde: unha consulta na interface física vai a alguén fóra do túnel.

A accesibilidade inclúe a devasa do host VPN, que debe permitir UDP e TCP 53 desde o grupo. Un porto bloqueado parece exactamente un push roto, e tamén un resolvedor que só responde desde dentro da rede do túnel. Repita a captura tras desconectar e reconectar unha vez, porque os axustes que aparecen na primeira conexión e desaparecen na segunda son un fallo do ciclo de vida do hook, non unha opción ausente.

Manteña un só dono e verifique en orde

Un script que reescribe o DNS do adaptador a partir dun estado de túnel suposto duplica configuración que o perfil xa leva, e falla en silencio a primeira vez que a suposición é errónea. Prefira a configuración DNS propia da conexión ou un só hook documentado, e anote cal escolleu para que a seguinte persoa non engada un segundo.

Pecha o bucle con catro comprobacións: o enderezo empuxado presente na ligazón do túnel, o nome interno resolvéndose como nome plenamente cualificado, o mesmo nome resolvéndose sen o sufixo, e ambas aínda certas tras unha reconexión. Unha captura dille cal das catro fallou. O manual de OpenVPN 2.6 enumera dhcp-option e as directivas de script coas súas notas de plataforma.