Clientes do Always On VPN a receber resolutores em ordem errada? Veja como diagnosticar e corrigir no Windows Server (RRAS/NPS) com pool estático de IPv4 e boas práticas de DNS para Active Directory.
Visão geral do problema
Após reinstalar o servidor VPN (Windows Server 2019) e publicar o Always On VPN com autenticação pelo NPS, alguns administradores notam que os clientes remotos passam a receber duas entradas de DNS com a ordem invertida. Em vez de apontar primeiro para o DNS interno (Controlador de Domínio), o sistema lista primeiro o DNS do gateway/roteador que encaminha para resolutores públicos. Exemplo real:
192.168.1.1 ← DNS do gateway (externo)
192.168.1.200 ← DNS interno (Controlador de Domínio/AD)
Como consequência, a resolução de nomes de hosts internos (como fileserver.corp.local) falha ou fica lenta, levando utilizadores a recorrer a endereços IP e quebrando experiências dependentes de DNS (GPO, localização de Controladores de Domínio via registos SRV, etc.).
Como o Windows escolhe servidores DNS (resumo prático)
- O cliente tenta o DNS primário do adaptador associado ao destino. Se não responder atempadamente, falha para o secundário.
- Em ambientes multi‑interface (Ethernet, Wi‑Fi, VPN), a seleção considera métricas de interface e rotas. Ainda assim, manter o DNS interno como primeiro da VPN é a forma mais confiável de garantir a resolução de nomes do AD.
- Quando o primário é um DNS externo, consultas aos sufixos internos podem demorar (time‑outs) e, em certos cenários, nem chegam ao DNS do AD.
Indícios no cliente
- FQDNs internos não resolvem (
Host not found) ou resolvem apenas após vários segundos. - Políticas de Grupo não aplicam durante a sessão VPN.
nslookupaponta para o DNS externo como servidor padrão.
ipconfig /all
Get-DnsClientServerAddress -InterfaceAlias "Nome da VPN"
Resolve-DnsName dc01.corp.local
Causa raiz: atribuição por DHCP herdando a ordem errada de DNS
No RRAS, quando a atribuição de IPv4 dos clientes VPN está definida para Dinâmico (DHCP), o servidor delega ao DHCP a entrega de endereço e parâmetros. O problema é que, na maioria dos escopos de LAN, a opção de DNS costuma listar o router (com DNS público) como primeira entrada, por ser adequada a estações internas — mas é um desajuste para clientes VPN que precisam priorizar o DNS do AD.
Ao trocar a atribuição para Pool estático, o próprio RRAS passa a alocar os endereços aos clientes e, por padrão, “empresta” a sua própria configuração de DNS — que, em servidores de domínio, deve apontar para o DNS do AD em primeiro lugar. Este simples ajuste devolve a ordem correta aos clientes.
DHCP vs. Pool estático (comparativo)
| Modo de atribuição (RRAS) | Quem decide os DNS entregues | Ordem típica recebida | Risco para AOVPN |
|---|---|---|---|
| Dinâmico (DHCP) | Opções do escopo DHCP da LAN | DNS do router → DNS do AD | Alta probabilidade de resolução interna falhar/atrasar |
| Pool estático | RRAS usa os DNS configurados no próprio servidor | DNS do AD → (opcional) secundários | Baixo — alinha com as necessidades do domínio |
Soluções testadas na prática
| Caminho proposto | Resultado | Observações |
|---|---|---|
| Alterar manualmente o DNS no adaptador VPN (Painel de Controlo → Rede → Alterar definições do adaptador) | Funciona enquanto permanecer manual | Não resolve a obtenção automática correta; difícil de gerir em escala |
Limpar cache DNS (ipconfig /flushdns) | Sem efeito na ordem | Apenas remove entradas antigas; não altera servidores configurados |
| Mudar a atribuição de IPv4 no RRAS de DHCP para Pool estático e reservar esse intervalo no DHCP | Solução definitiva: clientes passam a receber o DNS interno como primário | É a abordagem recomendada para Always On VPN em Windows Server |
Solução recomendada passo a passo (RRAS com Pool estático)
Antes de começar
- Confirme que o servidor RRAS usa apenas DNS do AD no(s) NIC(s) internos (ex.: 192.168.1.200).
- Defina um intervalo exclusivo para clientes VPN (fora de escopos LAN existentes), por exemplo,
192.168.10.200-219.
Configurar o Pool estático no RRAS (GUI)
- Abrir Routing and Remote Access (RRAS).
- Botão direito no nome do servidor → Propriedades → separador IPv4.
- Em Client address assignment, selecionar Static address pool e clicar Add.
- Introduzir o intervalo (ex.:
192.168.10.200a192.168.10.219). - Aplicar e reiniciar o serviço RRAS se solicitado.
Reservar/excluir o intervalo no DHCP
Abra a consola DHCP e crie uma exclusão ou reserva que impeça a atribuição desses endereços a máquinas da LAN. Isso evita conflitos ARP e eventos de duplicação de IP.
Definições complementares
- (Opcional) Ative Broadcast name resolution apenas se necessitar de compatibilidade com nomes NetBIOS legados. Esta opção não controla DNS e não altera a ordem de resolutores.
- Garanta que o RRAS consegue consultar o DNS do AD (teste com
nslookupno próprio servidor).
Validação no cliente
Depois de estabelecer a VPN, verifique se o DNS do AD aparece em primeiro no adaptador da VPN:
Get-DnsClientServerAddress -InterfaceAlias "Nome da VPN"
Teste também a resolução de nomes internos e observe o servidor que respondeu:
Resolve-DnsName fileserver.corp.local -Type A -Server 192.168.1.200
Resolve-DnsName ldap.tcp.dc._msdcs.corp.local -Type SRV
Saída esperada: o primeiro servidor listado deve ser o DNS interno; as consultas a FQDNs internos retornam com latência baixa (<50 ms em geral) e sem time‑outs.
Boas práticas de DNS para Always On VPN
- DNS interno primeiro (ou único) na conexão VPN. Evite DNS públicos como primários em máquinas unidas ao domínio.
- Encaminhe para a internet via forwarders no seu DNS interno. Assim, o cliente continua a usar o DNS do AD para tudo e o servidor encaminha apenas aquilo que não é interno.
- Configure sufixos de pesquisa do domínio (DNS Suffix) no perfil da VPN, de modo que nomes curtos (
fileserver) sejam resolvidos comofileserver.corp.local. - (Opcional) Em ambientes multi‑interface, considere desativar a “Smart Multi‑Homed Name Resolution” por Política de Grupo, para reforçar a ordem de DNS por interface.
- Mantenha a higiene do AD DNS: zonas integradas no AD, registos SRV e A/PTR consistentes, limpeza de stale records.
- Evite configurações manuais permanentes de DNS nos clientes: dificultam a gestão e mascaram problemas estruturais.
Alternativas quando o Pool estático não é viável
Existem cenários em que o uso de Pool estático pode não ser possível (por políticas de endereçamento, auditoria, ou integração com DHCP central). Nestes casos, avalie:
- Perfis AOVPN via MDM/Intune (ProfileXML): é possível declarar servidores DNS e sufixos específicos para a interface VPN, bem como regras de resolução por sufixo (NRPT). Útil para garantir que zonas internas são sempre consultadas no DNS do AD.
- GPO/Política de DNS: ajustar a ordem e o comportamento de resolução em clientes do domínio, mitigando concorrência com outros adaptadores.
- Ajustes de roteamento/métrica: assegurar que a interface VPN tem métrica adequada para destinos internos, reduzindo ambiguidades de caminho.
Nota: mesmo com estas alternativas, manter o DNS do AD como preferido para a interface VPN continua a ser a melhor prática.
Erros comuns e como evitá‑los
- Usar o DNS do router como primário por conveniência: quebra a descoberta de DCs (
ldap.tcp) e autenticação Kerberos nas sessões remotas. - Escopo DHCP partilhado com a LAN para clientes VPN: gera conflitos e mistura políticas indevidas.
- Esquecer de reservar/excluir o intervalo do Pool estático no DHCP: causa IPs duplicados quando a LAN está ocupada.
- NIC do RRAS com DNS público: os clientes herdarão a ordem errada mesmo com Pool estático.
Checklist rápido de correção
- No RRAS, mude Client address assignment para Static address pool e adicione o intervalo exclusivo.
- No DHCP, crie exclusão/reserva para o mesmo intervalo.
- No servidor, verifique que o(s) NIC(s) usam apenas o DNS do AD como preferido.
- No cliente, confirme com
Get-DnsClientServerAddressque o DNS interno aparece em primeiro. - Teste
Resolve-DnsNamepara FQDNs internos e verifique latência e servidor respondente.
Exemplo completo de validação no cliente
# 1) Confirmar servidores DNS por interface
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize
2) Confirmar rotas para a rede interna (por exemplo, 192.168.0.0/16)
Get-NetRoute -DestinationPrefix 192.168.0.0/16 | Sort-Object RouteMetric | Format-Table -AutoSize
3) Resolver FQDN interno e mostrar o servidor que respondeu
Resolve-DnsName app01.corp.local -Type A -Server 192.168.1.200
4) Resolver registos SRV do AD
Resolve-DnsName \ldap.\tcp.dc.\_msdcs.corp.local -Type SRV
5) Limpar caches para novos testes (opcional)
ipconfig /flushdns </code></pre>
<h2>Perguntas frequentes</h2>
<p><strong>Preciso de DNS externo como secundário?</strong><br>
Na maioria dos ambientes com AD, <strong>não</strong>. O DNS interno pode encaminhar (via forwarders ou root hints) as consultas externas. Se optar por um externo, posicione‑o <em>apenas</em> depois de todos os DNS internos.</p>
<p><strong>Isto interfere com <em>split tunneling</em>?</strong><br>
Não. O mecanismo de túnel de tráfego é independente da lista de resolutores. Contudo, o <em>split DNS</em> depende de os nomes internos consultarem primeiro o DNS do AD.</p>
<p><strong>Posso forçar por GPO que o Windows respeite estritamente a ordem dos DNS?</strong><br>
Sim, desativando a resolução multi‑interface “inteligente” por política. Ainda assim, a correção estrutural é entregar a ordem correta pelo próprio perfil VPN (ou pelo RRAS).</p>
<h2>Conclusão</h2>
<p>Ao transformar a atribuição de IPv4 do RRAS de <strong>Dinâmico (DHCP)</strong> para <strong>Pool estático</strong>, os clientes Always On VPN passam a receber o <strong>DNS interno do AD como primário</strong>, estabilizando a resolução de nomes, a aplicação de GPO e o acesso aos serviços corporativos. Combine isso com a exclusão do intervalo no DHCP e a validação no cliente para uma correção robusta e reproduzível.</p>
<h2>Resumo em uma frase</h2>
<p>O problema de resolução de nomes foi causado pela prioridade errada de servidores DNS entregue pelo DHCP; ao mudar o RAS para pool IPv4 estático (e reservar esse intervalo no DHCP), o DNS interno passou a ser o primeiro da lista e a resolução voltou a funcionar corretamente.</p>
<h2>Apêndice: passos rápidos com <em>capturas</em> textuais</h2>
<ol>
<li><strong>RRAS → Propriedades → IPv4</strong> → selecione <strong>Static address pool</strong> → <em>Add</em> → informe <code>192.168.10.200-219</code>.</li>
<li><strong>DHCP</strong> → no escopo da LAN, adicione <strong>Exclusão</strong> para <code>192.168.10.200-219</code>.</li>
<li><strong>NIC do Servidor</strong> → DNS Preferido: <code>192.168.1.200</code>; DNS Alternativo: (opcional) <code>192.168.1.201</code> (outro DC/DNS interno).</li>
<li><strong>Cliente</strong> → confirme:
<pre><code>Get-DnsClientServerAddress -InterfaceAlias "VPN"
nslookup dc01.corp.local
Resumo visual do fluxo (simplificado)
+----------------------+
Internet DNS <--| Router / Gateway |--> Internet
+----------+-----------+
|
| (NÃO deve ser DNS primário da VPN)
|
+--------------------+--------------------+
| Rede Interna (AD) |
| |
+------+------+ +-------+-------+
| RRAS/VPN | | DNS do AD |
| (Pool estát.)|-------------------------| (192.168.1.200)
+-------+------+ +---------------+
|
| (Clientes VPN herdam DNS do RRAS: AD 1º)
v
+------+--------------------------+
| Cliente Always On VPN |
| DNS: 192.168.1.200, 192.168.1.1 (opcional) |
+---------------------------------+
Dicas de SEO e manutenção
- Inclua palavras‑chave no título: Always On VPN, DNS, Windows Server 2019, RRAS, NPS, Active Directory.
- Use subtítulos com intenção: “Causa raiz”, “Solução definitiva”, “Validação no cliente”.
- Mantenha o conteúdo atualizado quando migrar de 2019 para 2022/2025; o princípio continua idêntico.