O nome de host da LAN falla por VPN: sufixo, mDNS ou zona?

Xunto ao dispositivo, a impresora responde a un nome curto e o servidor de ficheiros responde a un alcume. A través do túnel, ambos os nomes caducan mentres os seus enderezos seguen funcionando. A ruta fai o seu traballo; o camiño de nomes que facía funcionar eses nomes curtos nunca cruzou o túnel. Tres mecanismos producen ese comportamento e cada un necesita unha corrección distinta.

Comece por identificar de que mecanismo depende o nome.

Tres tipos de nome que se comportan de forma distinta

Un nome dunha soa etiqueta como fileserver adoita depender dun sufixo de busca DNS que engade o resolutor. Ese sufixo chega a miúdo coa concesión DHCP local, así que un cliente remoto que obtén direccionamento da VPN non ten motivo para coñecelo. Engadir unha ruta non entrega o sufixo. O nome curto simplemente deixa de existir como nome, aínda que o enderezo que hai detrás sexa accesible.

Un nome que remata en .local normalmente resólvese mediante DNS multicast na ligazón local, como describe a RFC 6762. O multicast non atravesa un túnel encamiñado agás que algo o ponte ou faga de proxy a propósito, así que o nome deixa de resolverse no momento en que sae do segmento.

Un nome de empresa totalmente cualificado pertence a unha zona interna servida polos resolutores da organización. Ese funciona en remoto cando a VPN empuxa eses resolutores e o cliente está configurado para usalos. E localhost é de uso especial segundo a RFC 6761: refírese á máquina que ten diante, nunca a un servizo remoto.

Lea o resolutor antes de cambiar a ruta

Pregunte que servidor de nomes respondeu e que sufixo se engadiu. A mesma consulta a través de resolutores distintos dá respostas distintas, e esa diferenza é a evidencia que necesita.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Se a consulta totalmente cualificada se resolve pero a curta non, o fallo está no sufixo, non no servidor. Se ningunha se resolve e o enderezo funciona, o cliente non está usando o resolutor interno en absoluto. Compare a lista de resolutores co que a VPN debería empuxar, porque un cliente que conserva o seu resolutor local para cada consulta nunca verá a zona interna.

Traia o nome correcto ao cliente

Pida ao administrador o nome de acceso remoto documentado, completo, e úseo no perfil en lugar de adiviñar sufixos. Se o despregamento admite DNS dividido, configure o dominio interno para que o resolvan os servidores internos mentres todo o demais conserva o resolutor local. Empuxe o dominio de busca a través da configuración da VPN onde o cliente o admita.

Verifique o resultado no cliente en lugar de na pasarela. Un axuste aplicado no servidor que nunca chega ao cliente non cambia nada.

Manteña intacta a identidade do certificado

Unha proba baseada no enderezo que ignora o erro do certificado só demostra que o socket se abriu. O certificado do servizo emítese para un nome, e o cliente seguirá rexeitando a discrepancia con razón. Se o certificado só enumera o nome interno, use ese nome e arranxe a resolución, ou obteña un certificado que cubra o enderezo que pretende usar.

Anote o nome, o resolutor e o sufixo que produciron unha conexión correcta. Ese rexistro aforra á seguinte persoa repetir a solución provisional baseada no enderezo que oculta o problema real.