O nome de host da LAN falha pela VPN: sufixo, mDNS ou zona?

Ao lado do dispositivo, a impressora responde a um nome curto e o servidor de arquivos responde a um apelido. Pelo túnel, ambos os nomes expiram enquanto os seus endereços continuam a funcionar. A rota faz o seu trabalho; o caminho de nomes que fazia esses nomes curtos funcionarem nunca atravessou o túnel. Três mecanismos produzem esse comportamento, e cada um exige uma correção diferente.

Comece por identificar de que mecanismo depende o nome.

Três tipos de nome que se comportam de forma diferente

Um nome de uma só etiqueta como fileserver normalmente depende de um sufixo de pesquisa DNS que o resolvedor acrescenta. Esse sufixo chega muitas vezes com a concessão DHCP local, pelo que um cliente remoto que obtém endereçamento da VPN não tem razão para o conhecer. Acrescentar uma rota não entrega o sufixo. O nome curto simplesmente deixa de existir como nome, embora o endereço por trás dele seja acessível.

Um nome que termina em .local é normalmente resolvido por DNS multicast na ligação local, como descreve a RFC 6762. O multicast não atravessa um túnel encaminhado a menos que algo o faça de ponte ou proxy deliberadamente, pelo que o nome deixa de ser resolvido no momento em que sai do segmento.

Um nome de empresa totalmente qualificado pertence a uma zona interna servida pelos resolvedores da organização. Esse funciona remotamente quando a VPN envia esses resolvedores e o cliente está configurado para os usar. E localhost é de uso especial segundo a RFC 6761: refere-se à máquina à sua frente, nunca a um serviço remoto.

Leia o resolvedor antes de mudar a rota

Pergunte que servidor de nomes respondeu e que sufixo foi acrescentado. A mesma consulta através de resolvedores diferentes dá respostas diferentes, e essa diferença é a prova de que precisa.

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 qualificada é resolvida mas a curta não, a falha está no sufixo, não no servidor. Se nenhuma é resolvida e o endereço funciona, o cliente não está a usar o resolvedor interno de todo. Compare a lista de resolvedores com o que a VPN devia enviar, porque um cliente que mantém o seu resolvedor local para cada consulta nunca verá a zona interna.

Traga o nome correto ao cliente

Peça ao administrador o nome de acesso remoto documentado, completo, e use-o no perfil em vez de adivinhar sufixos. Se a implementação suportar DNS dividido, configure o domínio interno para ser resolvido pelos servidores internos enquanto tudo o resto mantém o resolvedor local. Envie o domínio de pesquisa através da configuração da VPN onde o cliente o suportar.

Verifique o resultado no cliente e não no gateway. Uma definição aplicada no servidor que nunca chega ao cliente não muda nada.

Mantenha intacta a identidade do certificado

Um teste baseado no endereço que ignora o erro do certificado prova apenas que o socket foi aberto. O certificado do serviço é emitido para um nome, e o cliente continuará a recusar a discrepância com razão. Se o certificado lista apenas o nome interno, use esse nome e corrija a resolução, ou obtenha um certificado que cubra o endereço que pretende usar.

Registe o nome, o resolvedor e o sufixo que produziram uma ligação bem-sucedida. Esse registo poupa a pessoa seguinte de repetir a solução alternativa baseada no endereço que esconde o problema real.