VPN RRAS no Windows Server 2022: Windows 10 não entra no domínio por falha de DNS — guia de correção passo a passo

Cliente Windows conectado à VPN do RRAS no Windows Server 2022 consegue autenticar o túnel, mas falha ao ingressar no domínio e não resolve nomes internos. Este guia prático explica as causas e traz um passo a passo preciso para restaurar o DNS e concluir o ingresso.

Índice

Cenário e sintomas

O cenário típico é um computador‑cliente Windows (por exemplo, Windows 10) que estabelece uma sessão VPN ponto‑a‑ponto com o RRAS em um servidor Windows Server 2022, usando um pool de endereços estático. A conexão é bem‑sucedida, mas ao tentar ingressar no domínio surge a mensagem “Não foi possível contactar um Controlador de Domínio Active Directory”. Em paralelo, consultas nslookup a nomes internos falham enquanto o túnel está ativo.

Em um diagnóstico rápido, observa‑se que o adaptador PPP da VPN recebe um endereço IP válido porém com máscara /32 (255.255.255.255). Essa máscara é normal em conexões PPP. O ponto crítico está em como o cliente decide para onde enviar as consultas DNS e que rotas usar para alcançar os controladores de domínio.

Mapa rápido de sintomas e interpretações

Camada	Sintoma observado	Interpretação principal
DNS	Adaptador PPP recebe IP correto, máscara `/32` e falha para resolver nomes do domínio.	Falta de consulta ao(s) DNS interno(s) do AD. A máscara `/32` é normal; o problema é a seleção de servidores DNS e a rota até eles.
Encaminhamento no RRAS	Sem rotas estáticas definidas.	Ok em full tunnel com default gateway remoto. Em split tunnel, rotas específicas para as redes internas podem faltar.
Firewall e portas	Portas dos serviços de domínio aparentemente abertas.	Bloqueio não parece ser a causa imediata; ainda assim, convém confirmar que não há inspeção/filtragem quebrando DNS ou RPC dinâmico.
Credenciais	Conta com privilégios suficientes usada no ingresso.	Não é a causa.
Registos e logs	Event Viewer sem erros adicionais no momento do ingresso.	Fortemente indicativo de falha de DNS/roteamento antes do pedido atingir o AD.

Por que isso acontece

Para ingressar no domínio, o Windows precisa localizar um controlador de domínio por DNS, consultando registos SRV como ldap.tcp.dc._msdcs.seudominio.local. Se o cliente continuar consultando um DNS público (do ISP) ou não tiver rota válida até o DNS do AD, a resolução falhará e o assistente de ingresso não conseguirá contactar um DC.

No Windows, a escolha do servidor DNS envolve:

Lista de servidores DNS por interface (ordem definida na própria interface).
Métrica da interface (interfaces com métrica menor são priorizadas).
Lista de sufixos de pesquisa DNS (para completar nomes curtos sem FQDN).

Conexões VPN PPP muitas vezes criam um adaptador com DNS interno correto, mas a interface de rede local (Wi‑Fi ou Ethernet) permanece com métrica mais baixa ou com DNS público em primeiro lugar. O resultado é que, mesmo pelo túnel, o cliente tenta resolver nomes internos contra um DNS externo que não conhece o AD. Além disso, em split tunneling, a ausência de rotas para as subnets internas impede que as consultas cheguem ao DNS do AD por IP.

Objetivo do plano de correção

Fazer com que, durante a VPN, o DNS interno do Active Directory seja o resolutor de primeira preferência e que o tráfego destinado às redes internas da empresa tenha rotas válidas através do RRAS. Uma vez que nslookup e Resolve-DnsName funcionem com o DNS certo, o ingresso no domínio tende a fluir sem fricções.

Correções recomendadas

Garantir que o servidor entregue DNS interno através do túnel

No servidor RRAS:

Abra o console RRAS.
Com o servidor selecionado, clique com o botão direito em Propriedades e aceda à aba IPv4.
Mantenha “Enable broadcast name resolution” marcado apenas se tiver legado NetBIOS (não resolve AD via DNS).
Em Client DNS, introduza os endereços dos controladores de domínio que atuam como DNS internos.
Se utilizar DHCP em vez de pool estático, configure um escopo dedicado para VPN que distribua os DNS do AD como opção 006 (e, se aplicável, o sufixo DNS com a opção 015).

Essa definição garante que, ao autoconfigurar o adaptador PPP, o cliente receba o DNS correto.

Verificar a precedência do DNS no cliente

Após conectar a VPN, confirme a pilha DNS e as métricas:

ipconfig /all

O DNS preferencial deve apontar para o servidor do AD. Se a ordem estiver errada, ajuste pelo stack IPv4 da interface VPN ou via política. Em PowerShell:

# Listar servidores DNS por interface
Get-DnsClientServerAddress | Sort-Object -Property InterfaceIndex | Format-Table InterfaceAlias, ServerAddresses

Opcional: definir métrica menor para a interface da VPN (prioridade)

Get-NetIPInterface | Sort-Object InterfaceMetric | Format-Table ifIndex, InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "SeuAdaptadorVPN" -InterfaceMetric 5

Dica: se o Windows atribuir automaticamente métricas, desmarque “Métrica automática” nas propriedades avançadas da interface e defina manualmente um valor menor para a VPN.

Testar resolução antes do ingresso

Não avance para o ingresso no domínio antes de comprovar que o DNS interno funciona:

nslookup dc1.seudominio.local
nslookup -type=SRV ldap.tcp.dc._msdcs.seudominio.local
Resolve-DnsName seudominio.local
ping dc1.seudominio.local

Se falhar, valide se as consultas alcançam o RRAS com um sniffer (Wireshark) ou com contadores de desempenho de DNS no servidor. Use também:

Test-NetConnection -ComputerName dc1.seudominio.local -Port 53
Test-NetConnection -ComputerName dc1.seudominio.local -Port 389
Test-NetConnection -ComputerName dc1.seudominio.local -Port 445

Definir rota adequada com gateway remoto ou túnel dividido

Há duas abordagens principais:

Gateway padrão na rede remota (full tunnel): mais simples e seguro. Todo o tráfego sai via RRAS.
Túnel dividido (split tunnel): só o tráfego corporativo vai para a VPN, exigindo rotas para cada rede interna.

Para a opção de full tunnel, no perfil de VPN do Windows:

Acesse as propriedades da conexão VPN → Rede → Protocolo IP versão 4 → Avançado.
Marque Usar gateway padrão na rede remota.

Em PowerShell (perfil criado pelo Windows):

Set-VpnConnection -Name "MinhaVPN" -SplitTunneling $false -PassThru

Para split tunneling, mantenha desmarcado o gateway remoto, mas adicione rotas persistentes para as redes do AD. Exemplo:

route print
route -p add 10.0.0.0 mask 255.255.240.0 &lt;gatewaydoRRAS&gt; if &lt;ifIndexdaVPN&gt;
route -p add 10.10.0.0 mask 255.255.0.0 &lt;gatewaydoRRAS&gt; if &lt;ifIndexdaVPN&gt;

Descubra o ifIndex com route print ou Get-NetIPInterface. Em ambientes geridos, prefira distribuir rotas pelo RRAS ou por política de acesso remoto, em vez de scripts locais.

Encaminhamento DNS no servidor

No serviço DNS do Active Directory, configure reenviadores para resolver nomes externos. Isso não impacta o ingresso, mas evita “time outs” quando o cliente tentar resolver nomes da internet via DNS interno.

Política de certificados e considerações de IPsec quando usar L2TP

Se o túnel for L2TP/IPsec:

Confirme que o certificado do servidor tem SAN correspondente ao nome usado pela conexão.
Garanta a passagem dos pacotes UDP 500 e 4500 e, quando envolver NAT, avalie a chave de registro a seguir no cliente:

reg add HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters ^
 /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f

Essa configuração é específica para cenários com NAT‑T e não substitui regras corretas de firewall.

Registo automático no DNS

No adaptador PPP, em IPv4 → Avançado → DNS, marque Registrar endereços desta conexão no DNS. Isso ajuda a atualizar automaticamente os registos A/PTR após o ingresso.

Sequência mínima de correção sugerida

Ajuste o DNS entregue pelo RRAS conforme descrito.
Reconecte a VPN e confirme que nslookup seudominio.local devolve o(s) IP(s) de controladores de domínio.
Tente juntar ao domínio; se falhar, ative temporariamente o default gateway na rede remota para descartar problema de roteamento.
Se funcionar, volte ao split tunnel e crie rotas estáticas apenas para as redes internas necessárias.

Validação completa após correção

Resolução DNS: Resolve-DnsName ldap.tcp.dc._msdcs.seudominio.local -Type SRV retorna registros do seu AD.
Localização de DC: nltest /dsgetdc:seudominio.local mostra um controlador adequado, site e status.
Conectividade: Test-NetConnection com portas 53, 88, 389, 445 e 135 tem sucesso.
Ingresso: use o assistente do sistema ou Add-Computer -DomainName seudominio.local -Credential DOMÍNIO\Conta e reinicie.

Boas práticas e armadilhas comuns

Máscara /32 em PPP é normal: o túnel é ponto a ponto. Foque no DNS e nas rotas.
Prioridade de interfaces: assegure que a interface VPN tenha métrica menor do que Wi‑Fi/Ethernet enquanto a sessão estiver ativa.
Sufixo DNS: configure o sufixo primário do computador e/ou a lista de pesquisa para incluir o FQDN do domínio. Evite depender de nomes curtos.
Serviços do AD: além de DNS, portas 88, 389, 445, 135 e a faixa RPC 49152‑65535 são requeridas. Não esqueça 123 para sincronização de tempo.
IPv6: se houver IPv6 no AD e no RRAS, forneça também DNS e rotas IPv6 para a VPN. Se não for usar, desative no perfil do túnel para reduzir ambiguidade.
Servidor multi‑homed: não deixe NICs externas registrarem no DNS interno. Em NICs externas, desmarque “Registrar endereços desta conexão no DNS”.
Sites do AD: inclua o pool de endereços da VPN como Subnet no “Sites and Services” e associe ao site correto para direcionamento de DC e políticas.

Checklist em sessenta segundos

RRAS fornece DNS do AD em Client DNS.
ipconfig /all mostra o DNS do AD como preferencial da interface VPN.
Resolve-DnsName dos registos SRV responde.
Rotas para redes internas existem (split) ou o gateway remoto está ativo (full).
Portas de domínio acessíveis e sem inspeção que quebre RPC/DNS.
Ingresso concluído e reinício efetuado.

Perguntas frequentes

Por que o nslookup falha apenas quando a VPN está ativa

Porque a interface VPN entrega um DNS interno, mas a precedência de interfaces ou a ordem de servidores ainda privilegia o DNS público. O Windows tenta resolver nomes do AD contra um resolutor que não conhece a zona interna.

A máscara `/32` é um problema

Não. Em PPP, cada ponta do túnel enxerga apenas o outro extremo. O roteamento é decidido por rotas do sistema e pela presença do gateway remoto ou rotas estáticas.

Preciso desativar o DNS público local para usar a VPN

Não é necessário desativar, mas é essencial que durante a VPN o DNS interno tenha prioridade. Isso se obtém com a métrica da interface VPN menor e com o servidor DNS interno na frente da lista.

Ingressar com nome curto do domínio é confiável

Prefira sempre o FQDN. Com sufixo DNS mal configurado, nomes curtos podem falhar. Use seudominio.local (ou seu FQDN real).

Como automatizar para todos os usuários

Distribua perfis de VPN e rotas por política de acesso remoto, MDM ou script de logon. Em ambientes modernos, o Always On VPN com políticas de dispositivo é a abordagem mais consistente.

Apêndice de comandos úteis

# Estado das interfaces e métricas
Get-NetIPInterface | Sort-Object InterfaceMetric | Format-Table ifIndex, InterfaceAlias, NlMtu, InterfaceMetric

Servidores DNS por interface

Get-DnsClientServerAddress | Format-Table InterfaceAlias, AddressFamily, ServerAddresses

Consulta de registos SRV críticos do AD

Resolve-DnsName ldap.tcp.dc._msdcs.seudominio.local -Type SRV
Resolve-DnsName kerberos.tcp.seudominio.local -Type SRV

Localização de um controlador de domínio

nltest /dsgetdc:seudominio.local

Testes de porta

Test-NetConnection -ComputerName dc1.seudominio.local -Port 53
Test-NetConnection -ComputerName dc1.seudominio.local -Port 88
Test-NetConnection -ComputerName dc1.seudominio.local -Port 389
Test-NetConnection -ComputerName dc1.seudominio.local -Port 445
Test-NetConnection -ComputerName dc1.seudominio.local -Port 135

Ingresso via PowerShell

Add-Computer -DomainName seudominio.local -Credential SEUDOMINIO\Administrador -Restart

Portas e serviços do Active Directory

Serviço	Porta e protocolo	Uso
DNS	53 TCP/UDP	Resolução de nomes, registos SRV do AD
Kerberos	88 TCP/UDP	Autenticação
LDAP	389 TCP/UDP	Consulta de diretório
LDAPS	636 TCP	LDAP sobre TLS
SMB	445 TCP	Netlogon, scripts, GPOs
RPC Endpoint Mapper	135 TCP	Negociação de portas RPC dinâmicas
RPC dinâmico	49152–65535 TCP	Serviços AD e Netlogon
Global Catalog	3268/3269 TCP	Pesquisa no catálogo global (com/sem TLS)
NTP	123 UDP	Sincronização de tempo para Kerberos
DFSR	5722 TCP	Replicação SYSVOL (quando aplicável)

Ajustes finos para estabilidade

Lista de sufixos de pesquisa: em clientes com múltiplos domínios, configure a lista de sufixos em Propriedades do TCP/IPv4 → Avançado → DNS ou via política (SuffixSearchList), garantindo que o sufixo do AD venha primeiro.
Evitar EDNS quebrado: alguns middleboxes lidam mal com DNS ampliado. Se observar quedas apenas em respostas grandes, ajuste o MTU da VPN ou corrija o firewall; evitar EDNS no servidor não é recomendável.
Telemetria: habilite logs de auditoria do DNS e contadores de desempenho para medir “DNS Queries/sec” provenientes de clientes VPN durante testes.
Endereços do servidor: se o RRAS for multi‑homed, fixe o DNS do AD para escutar na NIC interna e evite anúncios indevidos de IPs externos no DNS.

Modelo de runbook para equipes

Confirmar escopo: há sessão VPN? rasdial ou interface ativa no Centro de Rede.
Capturar estado: salvar ipconfig /all, route print e Get-DnsClientServerAddress.
Validar DNS interno: Resolve-DnsName dos registos SRV e nltest ao domínio.
Rotas: garantir gateway remoto ou rotas persistentes para redes do AD.
Repetir teste: ingresso com FQDN, reinício e verificação de GPO.
Encerrar: anexar evidências, registrar métricas e atualizar documentação de rede.

Fluxo de decisão resumido

Conectou VPN, mas o ingresso falha com erro de DC indisponível.
nslookup a nomes internos falha → problema de DNS.
Verifique se o cliente usa o DNS do AD → se não, corrija ordem/métrica.
Se usa, mas ainda falha → confirme rotas até o DNS e portas.
Se rotas/portas ok → verificar MTU, inspeção de firewall e SRV no DNS.

Conclusão

Em ambientes RRAS com pool estático, a maioria dos casos de “Não foi possível contactar um Controlador de Domínio Active Directory” durante o ingresso de máquinas remotas converge para dois pontos: o cliente não está consultando o DNS interno e/ou não há rota correta até as redes do AD. Ao garantir que o RRAS entregue os DNS certos, priorizar a interface VPN no cliente e escolher conscientemente entre full ou split tunnel com rotas apropriadas, o nslookup volta a responder, os registos SRV ficam acessíveis e o ingresso no domínio conclui sem erros.