Nomes internos fallan na VPN mentres os sitios públicos resolven ben

Un usuario informa de que o nome de host da intranet non se resolve pola VPN. Un segundo informe, desde o mesmo portátil, di que unha proba de fuga aínda mostra consultas respondidas polo resolutor local. Semellan un só problema e son dous, con evidencias distintas, e a reparación habitual do primeiro empeora o segundo. Sepáraos antes de tocar ningún axuste.

Dous síntomas que non son unha soa avaría

Non resolver un nome interno significa que a pregunta foi a un lugar que non ten resposta para ela. Que as consultas saian do túnel significa que a pregunta foi ao lugar equivocado aínda cando a resposta estaba dispoñible. Son fallos opostos: un é unha resposta ausente, o outro un destino de máis.

A trampa é que engadir o resolutor da oficina en todas partes corrixe o primeiro e garante o segundo. Engadir un resolutor público en todas partes fai o contrario.

Anota as dúas observacións cunha marca de tempo e despois percorre as catro comprobacións de abaixo en orde.

Que resolutor de adaptador recibe a pregunta

En Windows, o cliente DNS escolle servidores segundo a orde de vinculación dos adaptadores, e o adaptador do túnel non é automaticamente o primeiro. Abre a configuración avanzada do adaptador, move a conexión de acceso remoto por riba do adaptador físico e despois reconecta para que o cambio se aplique a unha sesión nova.

A orde de vinculación só é a primeira metade. O cliente tamén ten que saber que nomes pertencen a ese adaptador, e iso é unha cuestión de sufixo, non de orde.

Pon o ipconfig /all da máquina que funciona xunto ao do portátil, ambos tomados co túnel activo. A máquina que funciona amosará un sufixo DNS específico da conexión no seu adaptador de oficina, e o portátil pode non amosar ningún no túnel. Esa diferenza explica toda unha clase de informes nos que o servidor está xusto aí e o nome segue fallando, porque sen sufixo o nome curto nunca se completa na zona que serve o resolutor da oficina.

Un nome curto necesita un sufixo antes de necesitar unha ruta

Escribir un nome de host non cualificado pídelle ao resolutor que adiviñe un dominio. A suposición vén da lista de sufixos ligada á conexión, e se esa lista está baleira a consulta sae como unha única etiqueta que ningunha zona privada vai recoñecer.

Copia o sufixo da máquina que funciona nas propiedades IPv4 do adaptador VPN, na lapela DNS, e despois reconecta. En Linux o equivalente é o dominio de busca na ligazón do túnel, que systemd-resolved expón por ligazón e non globalmente.

Mantén os dous axustes separados nas túas notas. Un sufixo cambia o que se pregunta; o enderezo do resolutor cambia a quen se lle pregunta. Corrixir un mentres o outro está mal produce un resultado que parece aleatorio.

Pregunta ao resolutor directamente e despois polo nome

Unha consulta directa ao resolutor da oficina separa un problema de nome dun problema de camiño, porque evita por completo a selección de resolutor do cliente.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

O primeiro comando pide un nome totalmente cualificado a un servidor concreto. Se responde, o resolutor e a ruta cara a el están ben e a avaría está na selección ou no sufixo. Se expira, o enderezo é incorrecto ou inalcanzable e o problema é o encamiñamento, non o DNS. O segundo comando mostra que pasa co nome curto, e o terceiro imprime a configuración do resolutor por ligazón nunha máquina systemd.

Vixía as respostas comodín, que algunhas redes devolven para nomes descoñecidos. Unha resposta plausible non proba que respondese o servidor pretendido, así que compara o enderezo devolto co que o servizo interno usa realmente. Se o enderezo pertence a unha páxina de aparcamento ou a un proxy, o resolutor respondeu pero a resposta nunca foi a túa. Esa distinción aforra unha hora de perseguir un túnel que funcionaba todo o tempo.

En Linux, un cliente VPN que reescribe /etc/resolv.conf substitúe por completo os resolutores locais. vpnc expón DNSUpdate no para evitalo, e systemd-resolved pode encamiñar só os dominios listados á ligazón do túnel. Ambos enfoques manteñen os nomes públicos no resolutor local e envían os nomes internos á oficina.

As fugas son unha regra, non unha caixa de verificación

A resolución de nomes é un intercambio UDP ao porto 53, así que un túnel que leva tráfico web pero non UDP deixa a consulta no camiño físico. Demóstrao capturando na tarxeta física mentres se resolve un nome público. Unha consulta visible en claro nesa interface significa que o túnel non a leva.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Se a consulta aparece en claro nesa interface, o túnel non a leva. A reparación é unha regra que permite o porto 53 só cara ao resolutor que empurrou o VPN e descarta os demais destinos, máis unha configuración de cliente que non descarte silenciosamente a opción empurrada.

Esa última parte importa máis do que parece. Inicia OpenVPN con route-nopull e a opción DNS empurrada desaparece xunto coas rutas, a menos que se amplíe o filtro de extracción para conservala. Un cliente que ignora dhcp-option DNS seguirá usando o que tiña antes. Calquera cambio no servidor necesita unha sesión nova para facerse efectivo, porque a lista de resolutores entrégase cando o túnel sobe e unha sesión vella segue amosando o estado anterior.

Anota que avaría observaches realmente antes de pechar o ticket. Unha resposta interna ausente e unha consulta que escapa do túnel piden reparacións distintas, e un cambio de sufixo que corrixe a primeira pode empeorar discretamente a segunda. Quen retome o ticket despois confiará na etiqueta, así que fai que a etiqueta sexa exacta.