Erro “did not resolve” no RRAS: como corrigir falha de DNS no servidor de VPN no Windows Server 2019

De um dia para o outro, os clientes passaram a ver “The remote connection was not made because the name of the remote access server did not resolve.” No Windows Server 2019 com RRAS, isso quase sempre é uma falha de DNS para o FQDN do servidor de VPN. Veja como diagnosticar e corrigir de forma rápida e definitiva.

Índice

Visão geral e sintomas

Quando o cliente tenta ligar o túnel e recebe a mensagem “did not resolve”, o problema acontece antes de qualquer autenticação ou abertura de portas do VPN. O sistema simplesmente não consegue transformar o nome do servidor (por exemplo, vpn.empresa.com) num endereço IP público válido. É por isso que, localmente, o servidor pode responder e, externamente, falhar: dentro da rede, o DNS interno resolve; fora dela, a resolução depende do DNS público.

No cenário típico, o RRAS está numa VM que também é Controlador de Domínio (DC). Nada impede essa combinação, mas ela aumenta o risco de confundir DNS interno e DNS público, sobretudo em ambientes com split-horizon (mesmo nome interno e externo apontando para IPs diferentes).

Entendendo o que o erro realmente significa

O cliente de VPN primeiro consulta o DNS para o FQDN do servidor. Se o DNS público devolver NXDOMAIN (registro inexistente), IP errado, resposta assinada quebrada (DNSSEC) ou qualquer outra anomalia, o Windows aborta com “did not resolve”. Esse erro aparece antes de validar certificado, negociar TLS (SSTP) ou IKE/IPsec. Portanto, insistir em “reiniciar o RRAS” ou “abrir a porta 443” não ajuda enquanto o nome não resolver corretamente na internet.

Confirmar FQDN e DNS público

O primeiro passo é garantir que o nome usado pelos clientes é o certo e que resolve para o IP público correto. Valide de um local fora da rede corporativa (hotspot do telemóvel, por exemplo).

Comandos rápidos para validação

nslookup vpn.empresa.com 1.1.1.1
nslookup vpn.empresa.com 8.8.8.8

No PowerShell (Windows 10/11):

Resolve-DnsName vpn.empresa.com -Server 1.1.1.1
Resolve-DnsName vpn.empresa.com -Server 8.8.8.8

Interprete os resultados:

Resultado	Interpretação	Ação imediata
`NXDOMAIN`	Registro não existe na zona pública	Criar registro A (ou CNAME) no DNS do registrar/provedor
IP diferente do IP público	Apontamento incorreto	Ajustar o registro para o IP correto
Resolve internamente, falha externamente	Split-horizon sem equivalente público	Replicar o registro na zona pública ou usar nome distinto
Resolve, mas intermitente	TTL alto ou NS inconsistentes	Reduzir TTL (ex.: 300 s) e corrigir autoridade

Boas práticas no DNS público

Mantenha um registro A para vpn.empresa.com apontando para o IP público atual do firewall/roteador que faz o encaminhamento para o RRAS.
Se optar por CNAME, certifique-se de que o alvo resolve para um A válido. Evite CNAME direto no ápice da zona (empresa.com), pois muitos DNS não suportam; use um ALIAS do provedor, se disponível.
Se usa DDNS, valide o agente de atualização e credenciais. Uma senha alterada ou serviço parado explica “parou do nada”.
Reduza temporariamente o TTL para 300 segundos ao corrigir o apontamento, para acelerar a propagação.

Verificar autoridade e saúde do domínio

Mesmo com o registro correto, problemas na autoridade do domínio derrubam a resolução globalmente. Verifique:

Checagem	Porquê importa	Como verificar
Servidores de nomes (NS) corretos	Se o domínio aponta para NS que não hospedam a zona, clientes externos recebem falhas	`nslookup -type=ns empresa.com 1.1.1.1`
Domínio ativo e renovado	Expiração do domínio interrompe a delegação	Conferir no painel do registrador
DNSSEC consistente (se habilitado)	Assinatura quebrada faz resolvedores recusarem respostas	Desabilitar temporariamente ou corrigir rotação de chaves
Zona pública fora do DC	Evita exposição indevida e confusão com a zona interna do AD	Preferir DNS gerenciado no provedor

Mitigação rápida com arquivo hosts

Se o IP público está correto, mas a propagação do DNS vai levar algumas horas, faça uma mitigação controlada para manter a operação dos usuários prioritários. No Windows, edite o arquivo C:\Windows\System32\drivers\etc\hosts com privilegios administrativos e adicione:

203.0.113.10    vpn.empresa.com

Vantagens desta abordagem:

Preserva o FQDN no perfil do VPN, condição necessária para que o nome do certificado bata com o destino (SSTP/IKEv2).
Evita alterar o perfil para o IP cru, o que falharia na validação de certificado e não é sustentável.

Lembre-se de remover os mapeamentos do hosts depois que o DNS público estiver correto. Esse é um bypass temporário, não uma solução definitiva.

Validação de portas e encaminhamento após corrigir o FQDN

Quando o nome resolver corretamente, confirme o port forward e o estado das portas/protocolos exigidos pelos tipos de VPN que você oferece:

Protocolo	Portas	Observações
SSTP	TCP 443	Encaminhamento para o RRAS; certificado TLS válido é obrigatório
IKEv2	UDP 500 e UDP 4500	NAT-T via UDP 4500; requer certificado de máquina confiável
L2TP/IPsec	UDP 1701, UDP 500, UDP 4500	Inclui IPsec; cuidado com double NAT
PPTP	TCP 1723 + GRE 47	Obsoleto e inseguro; evite em produção

Testes externos úteis

# Testar reachability da porta do SSTP
Test-NetConnection vpn.empresa.com -Port 443

Testar reachability do IP público

Test-NetConnection 203.0.113.10 -Port 443

Medir rota até o IP público (não testa porta)

tracert 203.0.113.10

Se o teste ao FQDN falha e ao IP público passa, há indício de cache de DNS no cliente/ISP. Um ipconfig /flushdns no cliente ajuda o lado do Windows, mas não força provedores a descartarem cache; por isso a recomendação de TTL baixo durante a correção.

Certificados TLS e IPsec

Em muitas reconstruções de servidor ou renovações, o certificado é o próximo gargalo após restaurar o DNS. Verifique:

O certificado usado pelo SSTP tem CN ou SAN correspondente ao vpn.empresa.com e está em Local Computer > Personal.
Os clientes confiam na cadeia (AC raiz/intermediária). Em ambientes AD, a raiz pode estar nas Políticas; fora do domínio, distribua via MDM ou pacote.
Para IKEv2, o servidor precisa de certificado de máquina com propósitos compatíveis. Evite certificados de usuário no servidor.
Valide expiração. Um certificado expirado pode se manifestar como erro de TLS no cliente SSTP, mas se o nome não resolver, você nem chega a ver esse erro.

Comandos para inspecionar certificados

# Listar certificados de computador (PowerShell)
Get-ChildItem -Path Cert:\LocalMachine\My | Select-Object Subject, NotAfter, EnhancedKeyUsageList

Verificar vínculo HTTP SSL (útil para SSTP quando há conflito de binding)

netsh http show sslcert

Logs e diagnóstico no Windows

Se, após corrigir DNS e portas, ainda houver falhas, os logs ajudam a fechar o diagnóstico:

Event Viewer:
- System – erros de rede, TCP, certificados
- RemoteAccess – eventos do RRAS
- RasClient – mensagens lado cliente (nos PCs afetados)
- IKEExt – diagnóstico de IKEv2/IPsec, se aplicável
Captura de pacotes com filtros: # DNS udp.port == 53 SSTP tcp.port == 443 IKE/IPsec udp.port == 500 or udp.port == 4500 L2TP udp.port == 1701

Considerações de firewall e UTM

Verifique no equipamento de borda:

Port forward ativo para o IP interno do RRAS.
Hairpin NAT habilitado se colaboradores dentro da rede precisarem acessar o FQDN público para testes.
ALG ou IPS não bloqueando SSTP ou IKEv2. Muitos UTM têm “IPsec helper” que interfere quando mal configurado.
Atenção ao double NAT: se há dois roteadores em cascata, encaminhe as portas no primeiro para o segundo, e deste para o RRAS.

Prevenção e governança

Depois de restaurar o serviço, enderece a causa-raiz e reduza a probabilidade de repetição:

Monitoramento do registro A do VPN: alerte se o registro sumir, se o IP público mudar ou se a resposta virar NXDOMAIN.
Monitoramento de domínio e DNSSEC: notificações de expiração do domínio e de rotação das chaves DNSSEC.
Certificados: automatize a renovação via ACME quando possível; acompanhe validade e cadeia.
Runbook documentado: quem atualiza o DNS, onde fica a zona pública, TTL padrão, portas que devem permanecer abertas, certificado aplicado e testes externos recomendados.
Separação clara entre DNS interno e público: evite hospedar zona pública no DC ou misturar vistas internas/externas sem necessidade.

Cenários especiais e armadilhas comuns

Servidor RRAS também é DC: não há bloqueio técnico, porém evite expor serviços públicos adicionais nessa VM. Separe funções quando possível.
Split-horizon DNS: se vpn.empresa.com resolve para IP privado internamente e IP público externamente, garanta que a zona pública esteja correta e independente da interna.
Troca de registrador ou de NS: alterações de delegação levam tempo; reduza TTLs com antecedência e planeje janelas.
“Não houve mudança”: quase sempre houve – DDNS parou, domínio expirou, o IP público foi trocado pelo ISP, ou alguém limpou registros no DNS gerenciado.

Checklist prático de recuperação

Use esta lista rápida quando o alerta chegar:

Comprovar o FQDN utilizado pelos clientes (perfil do VPN, GPO, MDM).
Executar nslookup/Resolve-DnsName em resolutores públicos e validar o IP.
Corrigir o registro A/CNAME no DNS público e reduzir TTL para 300 s.
Aplicar mitigação temporária com hosts para usuários críticos, se necessário.
Confirmar port forward/NAT para 443, 500, 4500, 1701 conforme os protocolos em uso.
Validar certificados: nome, cadeia de confiança e validade.
Reexecutar testes externos com Test-NetConnection e validar conectividade completa.
Fechar com monitorias e documentação do runbook.

Exemplos de comandos úteis

Inclua estes comandos no seu runbook para acelerar futuros diagnósticos.

# Resolver nome do VPN em resolutores públicos
nslookup vpn.empresa.com 1.1.1.1
nslookup vpn.empresa.com 8.8.8.8

PowerShell – resolução de nome detalhada

Resolve-DnsName vpn.empresa.com -Server 1.1.1.1 -DnsOnly -NoHostsFile

Limpar cache DNS do cliente (não afeta DNS público)

ipconfig /flushdns

Testar porta do SSTP no FQDN e no IP público

Test-NetConnection vpn.empresa.com -Port 443
Test-NetConnection 203.0.113.10 -Port 443

Eventos de RRAS e RasClient

Get-WinEvent -LogName RemoteAccess -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Auto
Get-WinEvent -LogName System -MaxEvents 50 | Where-Object {$\_.ProviderName -eq "RasClient"} | Format-Table TimeCreated, Id, Message -Auto

Listar certificados de máquina relevantes

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotBefore, NotAfter, Thumbprint

Conferir regras do firewall local (Windows Defender Firewall)

netsh advfirewall firewall show rule name=all | findstr /I "SSTP IKEv2 L2TP 443 500 4500 1701"

Visualizar rotas (útil quando o RRAS é também gateway)

route print

Perguntas frequentes

“Ipconfig /flushdns” resolve esse erro? Ajuda apenas a limpar o cache local do Windows. Se o problema está no DNS público (e geralmente está), o erro continuará até que o registro correto exista e se propague nos resolutores externos.

Posso apontar o perfil de VPN direto para o IP? Não é recomendável. Em SSTP e IKEv2, a validação de certificado exige que o nome do servidor no perfil combine com o CN/SAN do certificado. Usar o IP pode causar falhas de confiança.

Funciona internamente mas não fora. Por quê? O DNS interno do AD provavelmente tem um registro para vpn.empresa.com, mas a zona pública não. Clientes externos consultam a internet, não o DNS interno.

O que pode ter mudado “sozinho”? Agente de DDNS parou, domínio expirou, troca de nameserver no registrador, erro humano apagou o registro, IP público rotacionou pelo ISP, ou falha em DNSSEC após rotação de chaves.

Conclusão

O erro “The remote connection was not made because the name of the remote access server did not resolve.” é um alarme de DNS público, não de RRAS. Ataque a causa na ordem certa: garanta que o FQDN resolve para o IP público correto, valide autoridade da zona, mitigue com hosts enquanto propaga, confirme portas/NAT, verifique certificados e feche com monitoria e runbook. Seguindo esta abordagem, a recuperação é rápida e a reincidência tende a zero.

Modelo de runbook para seu time

Copie, adapte e mantenha este trecho no seu repositório interno.

Título: Recuperação de RRAS por falha de resolução de nome

Critério de início:

- Clientes reportam "did not resolve" ao conectar ao VPN.

Passos:

1. Validar FQDN e DNS público

   - nslookup/Resolve-DnsName em 1.1.1.1 e 8.8.8.8
   - Corrigir registro A/CNAME; TTL = 300 s temporariamente

2. Mitigar clientes críticos

   - Mapear FQDN para IP público em hosts
   - Remover após propagação

3. Validar portas/NAT

   - SSTP 443/TCP; IKEv2 500/4500/UDP; L2TP 1701/UDP + 500/4500
   - Test-NetConnection contra FQDN e IP

4. Certificados

   - CN/SAN = FQDN; cadeia confiável; datas válidas

5. Logs e verificação

   - Event Viewer: RemoteAccess, RasClient, System
   - Captura: dns, tcp.port == 443, udp 500/4500/1701

6. Fechamento e prevenção

   - Monitorias para registro A, domínio e certificado
   - Atualizar documentação e responsabilidades

Observação:

- "ipconfig /flushdns" ajuda no cliente, não corrige DNS público.

Resumo executivo para gestores

Interrupções de VPN RRAS com erro de “did not resolve” decorrem de falhas de DNS público. O plano de ação é: corrigir registro e autoridade do DNS, mitigar com hosts, validar portas e certificados, e implementar monitorias e governança de DNS/certificados. Com isso, o MTTR cai de horas para minutos e o risco de recorrência despenca.

Dica final: se você controla o provisionamento do perfil de VPN via GPO ou MDM, padronize o FQDN e promova testes automatizados diários de resolução e reachability. Pequenas verificações proativas evitam grandes quedas.

Observação importante: comandos como ipconfig /flushdns e ipconfig /registerdns são úteis no cliente e no DNS interno, mas não consertam problemas no DNS público/autoritativo do domínio — onde, na imensa maioria dos casos, está a causa do “did not resolve”.