A VPN aparece como conectada, mas o sistema interno não abre pelo nome. O usuário consegue acessar outros serviços, a internet funciona e a primeira tentativa de suporte costuma ser reconectar o túnel. Quando isso não resolve, começa uma sequência de mudanças que pode esconder a causa original.
Se o DNS não resolve na VPN, investigue qual servidor recebe a consulta, se ele é alcançável pelo caminho autorizado e se conhece o nome solicitado. Uma sessão estabelecida confirma uma etapa da conexão, mas não valida a resolução de nomes nem o funcionamento da aplicação.
O nosso guia sobre DNS_PROBE_FINISHED_NXDOMAIN explica o erro geral.
Neste artigo, focamos em explicar um cenário onde um recurso corporativo deixa de ser encontrado durante o acesso remoto.
Leia e descubra.
Comece resgistrando exatamente o que funciona
Peça o nome completo utilizado, o horário da falha e a mensagem apresentada.
Confirme se o sistema funciona no escritório e se outros usuários da mesma VPN apresentam o problema. Esse recorte ajuda a distinguir uma falha do dispositivo de uma condição compartilhada.
Evite usar apenas “a VPN não funciona” como descrição. Registre se a autenticação termina, se um nome interno responde e se a aplicação abre. Uma dessas etapas pode funcionar enquanto outra falha.
Compare o nome completo com o nome curto
Um usuário pode abrir “financeiro” dentro do escritório porque o computador acrescenta um sufixo de pesquisa. Fora dele, esse comportamento pode ser diferente. Testar o nome completo aprovado para o serviço ajuda a investigar essa dependência.
Se o nome completo resolve e o curto não, verifique os sufixos e a política de resolução do cliente.
Não altere o nome do sistema ou o endereçamento apenas para contornar o sintoma. Confirme também se o endereço usado corresponde à documentação atual.
Identifique os resolvedores e as políticas do cliente
No Windows, a configuração da VPN pode determinar servidores e regras de resolução por espaço de nomes. A documentação da Microsoft descreve a NRPT como um mecanismo usado pelo cliente para orientar consultas conforme o nome.
O comportamento depende do perfil e do cliente de VPN adotados.
Por isso, uma única listagem de interfaces não explica necessariamente todo o caminho. A equipe deve conhecer a tecnologia utilizada e consultar a configuração correspondente. O objetivo é saber qual resolvedor deveria receber a consulta interna e qual caminho é realmente usado.
Compare consultas sem modificar a configuração
Em um Windows com o módulo DnsClient disponível, um técnico autorizado pode consultar o nome pelo comportamento padrão e comparar o resultado com uma consulta direta ao resolvedor interno aprovado.
Exemplo ilustrativo no PowerShell, que você pode adaptar ao ambiente:
Resolve-DnsName -Name sistema.corp.example.com -DnsOnly
Resolve-DnsName -Name sistema.corp.example.com -Server 10.20.0.10 -DnsOnly
O nome e o IP são exemplos, não recursos para consultar. Substitua ambos pelos valores internos autorizados e registre resposta, erro e horário. O parâmetro de servidor direciona aquela consulta; ele não altera a configuração de DNS do computador.
Se a consulta explícita responde e a padrão falha, investigue a seleção do resolvedor e as regras aplicadas. Se ambas falham, ainda é preciso distinguir ausência do nome, indisponibilidade do DNS e impossibilidade de alcançá-lo.
O teste direto pode não reproduzir todas as decisões do navegador ou do cliente de VPN.
Verifique rotas e permissões até o DNS interno
O cliente precisa alcançar o servidor de nomes pelo caminho planejado. Confira rotas, redes sobrepostas e regras que autorizam o serviço de DNS necessário. A ausência de resposta a ping, isoladamente, não comprova que o DNS esteja indisponível.
Um caso possível é a rede de casa usar a mesma faixa de endereços de um recurso corporativo. Outro é o túnel permitir a aplicação, mas não a comunicação com o resolvedor. Cada hipótese precisa de evidência antes da alteração.
Conduza os testes pelos meios aprovados para a infraestrutura e evite liberar toda a rede remota para descobrir se o sistema abre. Uma regra ampla dificulta reconhecer qual permissão era necessária e pode permanecer ativa depois do diagnóstico.
Confira registros internos e políticas de filtragem
Se a consulta alcança o resolvedor esperado, verifique se o nome existe na zona correta e se há encaminhamento adequado para os espaços de nomes internos. Em ambientes com respostas diferentes dentro e fora da empresa, confirme qual visão deveria atender o usuário remoto.
Avalie também se uma política de filtragem produziu a restrição. A resposta pode variar conforme a implementação; nem todo bloqueio aparece como NXDOMAIN. Consulte os registros disponíveis para relacionar nome, origem, horário e regra.
Trocar o DNS corporativo por um serviço público não resolve, por si só, nomes privados e pode retirar consultas do caminho de controle previsto. Uma comparação com outro resolvedor só deve ocorrer quando pertinente e autorizada, preservando os requisitos internos.
Como interpretar os resultados do diagnóstico
O resultado precisa orientar a próxima verificação. Resposta negativa, ausência de resposta e nome resolvido com falha na aplicação representam situações diferentes. A tabela organiza hipóteses; nenhuma delas dispensa a confirmação nos registros do ambiente.
Exemplo: o portal financeiro abre no escritório. Na VPN, a consulta padrão falha, mas a consulta direta ao DNS interno retorna o IP correto. Nesse caso, alterar o registro do portal seria uma intervenção sem evidência. O próximo passo é comparar o perfil do dispositivo afetado com o perfil aprovado, localizar a diferença na seleção de DNS e corrigir essa configuração pelo mecanismo de gestão utilizado.
Após a correção, repita a consulta padrão e o acesso ao portal. A consulta direta ao servidor ter funcionado durante o diagnóstico não basta para encerrar: o caminho normal do usuário também precisa funcionar.
Separe resolução de nomes e acesso à aplicação
Depois que o nome responde com o endereço esperado, teste o serviço de negócio. Firewall, porta, certificado, autenticação ou a própria aplicação ainda podem impedir o uso.
Abrir um endereço IP diretamente no navegador também não é uma prova universal. Serviços com HTTPS e hospedagem por nome podem depender do nome solicitado para selecionar o destino e validar o certificado. Registre a etapa que passou e continue o diagnóstico na camada correspondente.
O que entregar ao encerrar o chamado
Anote o nome afetado, o perfil de VPN, o resolvedor esperado, o resultado observado e a mudança realizada. Confirme o uso da aplicação com o usuário e, quando aplicável, valide novamente após uma reconexão.
Se foi feita uma exceção temporária, defina revisão e responsável. Atualize o procedimento da equipe para que uma recorrência comece pelas evidências já conhecidas, sem repetir todas as tentativas.
Na comparação entre VPN site-to-site e acesso remoto, o propósito da conexão orienta o desenho. No diagnóstico, esse desenho ajuda a reconhecer onde a resolução deixou de seguir o caminho esperado.
O Edge Protect pode compor projetos de VPN e controle de rede. A avaliação deve considerar os fluxos internos, o cliente utilizado e os requisitos de cada ambiente.
Precisa revisar o acesso remoto dos seus clientes? Ative agora a Trial do Edge Protect e descubra como podemos te ajudar.
Perguntas frequentes
A VPN pode conectar e ainda ter erro de DNS?
Sim. A conexão do túnel e a resolução de nomes são etapas diferentes. O cliente precisa selecionar um DNS que conheça o nome interno e conseguir alcançá-lo pelo caminho autorizado.
Trocar para DNS público resolve o sistema interno?
Um resolvedor público normalmente não conhece zonas privadas da empresa. A correção deve preservar a resolução interna prevista no projeto.
Limpar o cache resolve qualquer erro de DNS na VPN?
Não. A limpeza pode ser pertinente quando há evidência de resposta antiga no cache, mas não corrige rota ausente, regra incorreta ou registro inexistente no DNS consultado.
Continue aprendendo sobre o tema: