Laboratório de Troubleshooting: Azure Network Adapter
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador configurou o Azure Network Adapter em um servidor on-premises com Windows Server 2022 usando o Windows Admin Center. O processo foi concluído sem erros aparentes e o WAC exibiu a mensagem de sucesso. No entanto, ao tentar acessar uma VM na VNet 172.16.0.0/16 a partir do servidor, todas as tentativas de ping e conexão TCP falham.
O administrador verifica o estado da interface virtual no servidor:
Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*Azure*" }
Name InterfaceDescription Status
---- -------------------- ------
Azure Network Adapter Microsoft Azure VPN Adapter Up
Get-NetIPAddress -InterfaceAlias "Azure Network Adapter"
IPAddress : 192.168.200.5
PrefixLength : 32
AddressFamily : IPv4
O administrador também confirma que o VPN Gateway foi provisionado no Azure e que o status da conexão P2S no portal aparece como Connected. O servidor on-premises possui Windows Defender Firewall ativo com o perfil de domínio aplicado. A VNet de destino não possui Network Security Groups associados às subnets.
Qual é a causa raiz da falha de conectividade?
A) O Windows Defender Firewall está bloqueando o tráfego de saída para a faixa 172.16.0.0/16 no servidor on-premises
B) O pool de endereços P2S configurado no VPN Gateway está em conflito com a faixa de endereços da VNet
C) As rotas para a faixa 172.16.0.0/16 não foram adicionadas à tabela de roteamento do servidor on-premises
D) O VPN Gateway foi provisionado no SKU Basic, que não suporta conexões P2S via Azure Network Adapter
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que um servidor on-premises com Azure Network Adapter instalado perdeu conectividade com a VNet do Azure após uma janela de manutenção realizada na última madrugada. A causa foi confirmada: o certificado raiz utilizado para autenticação P2S expirou e precisa ser renovado. O servidor impactado hospeda um serviço de sincronização de arquivos que opera continuamente e não pode ser reiniciado durante o horário comercial. São 09h15 de uma segunda-feira. A renovação do certificado exige reinicialização do serviço de VPN no servidor.
A equipe possui acesso administrativo completo ao servidor e ao portal do Azure. Não há janela de manutenção programada antes de sexta-feira.
Qual é a ação correta a tomar neste momento?
A) Renovar o certificado imediatamente e reiniciar o serviço de VPN, pois a conectividade com o Azure já está interrompida e o impacto atual é maior do que o impacto da reinicialização
B) Aguardar a janela de manutenção de sexta-feira para executar a renovação do certificado e a reinicialização do serviço com impacto controlado
C) Remover e reinstalar o Azure Network Adapter via WAC, pois esse processo substitui o certificado automaticamente sem exigir reinicialização manual
D) Subir uma nova conexão P2S em paralelo com um certificado válido e redirecionar o tráfego antes de encerrar a conexão expirada
Cenário 3 — Causa Raiz
Um engenheiro recebe um chamado relatando que o Azure Network Adapter parou de funcionar em um servidor on-premises após uma atualização do Windows Admin Center. O servidor roda Windows Server 2019 e estava operacional há três meses sem incidentes. O engenheiro coleta as seguintes informações:
Evento no Event Viewer (Sistema):
Fonte: RasMan
ID: 20227
Descrição: The user CONTOSO\svc-network connected to the VPN.
The tunnel type was: IKEv2.
Authentication method: Certificate.
Status: Failed.
Reason: The certificate chain processed but terminated
in a root certificate which is not trusted by
the trust provider.
O engenheiro verifica que o certificado do cliente ainda está presente no repositório Certificates (Local Computer) > Personal e que a data de expiração é em 18 meses. A conta de serviço CONTOSO\svc-network tem permissões de administrador local no servidor. O WAC foi atualizado da versão 2211 para a versão 2306 durante a janela de manutenção anterior.
Qual é a causa raiz da falha de autenticação?
A) A conta de serviço CONTOSO\svc-network perdeu permissões de acesso ao repositório de certificados após a atualização do WAC
B) O certificado raiz correspondente foi removido do repositório Trusted Root Certification Authorities no servidor local
C) A atualização do WAC alterou o método de autenticação de Certificate para Microsoft Entra ID, invalidando o certificado existente
D) O certificado do cliente está instalado no contexto do usuário em vez do contexto da máquina, impedindo a autenticação pelo serviço RasMan
Cenário 4 — Impacto Colateral
Um administrador detectou que o VPN Gateway utilizado pelo Azure Network Adapter estava provisionado no SKU VpnGw1, com capacidade para até 250 conexões P2S simultâneas. Para reduzir custos, o administrador fez o downgrade do gateway para o SKU Basic, pois havia apenas 3 servidores on-premises conectados via Azure Network Adapter no momento. A operação foi concluída com sucesso no portal do Azure.
Nos dias seguintes, os três servidores continuam conectados e funcionando normalmente.
Qual consequência secundária essa ação pode causar em um momento futuro?
A) Os servidores existentes serão desconectados automaticamente após 30 dias, pois o SKU Basic não mantém conexões P2S provisionadas por gateways de SKU superior
B) Não será possível usar autenticação baseada em certificado para novas conexões P2S, pois o SKU Basic suporta apenas autenticação via Microsoft Entra ID
C) O throughput agregado de todas as conexões P2S ficará limitado ao teto do SKU Basic, podendo causar degradação de desempenho com o crescimento do número de servidores
D) O Azure Network Adapter perderá suporte a roteamento de tráfego para subnets adicionadas à VNet após o downgrade, exigindo reconfiguração manual em cada servidor
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está na saída do Get-NetIPAddress: a interface virtual recebeu um endereço IP do pool P2S (192.168.200.5), o que confirma que o túnel foi estabelecido com sucesso. O status Connected no portal corrobora isso. Se o túnel está ativo mas o tráfego para 172.16.0.0/16 não chega, a causa está no roteamento local do servidor, não na conectividade do túnel em si.
O Azure Network Adapter instala rotas para os prefixos da VNet no momento da configuração, mas essas rotas podem não estar presentes se houver falha silenciosa nessa etapa ou se tiverem sido removidas posteriormente. O comando route print no servidor revelaria a ausência da rota para 172.16.0.0/16.
A alternativa A é o distrator mais perigoso: o Firewall é frequentemente culpado em cenários de conectividade, mas ele não seria capaz de bloquear o tráfego se o próprio roteamento não soubesse para onde enviar os pacotes. A alternativa B seria identificada no momento da configuração, não após uma conexão bem-sucedida. A alternativa D é irrelevante porque o SKU do gateway não impede a exibição do status Connected.
Gabarito — Cenário 2
Resposta: A
A restrição crítica que determina a resposta correta é esta: a conectividade com o Azure já está interrompida. O serviço de sincronização de arquivos já está sem acesso à VNet desde a madrugada. Aguardar até sexta-feira (alternativa B) significa aceitar dias adicionais de interrupção para proteger um serviço que já está degradado. O princípio correto aqui é que o impacto de reiniciar o serviço de VPN é temporário e imediato, enquanto a perda de conectividade já é um fato consumado e crescente.
A alternativa C representa um equívoco técnico: remover e reinstalar o Azure Network Adapter não substitui automaticamente um certificado expirado; o processo geraria um novo ciclo de provisionamento, mas não resolveria o problema de certificação de forma mais segura do que a renovação direta. A alternativa D descreve uma operação válida em cenários de migração com zero downtime, mas é desnecessariamente complexa quando o túnel original já está inoperante.
Gabarito — Cenário 3
Resposta: B
O evento 20227 do RasMan é explícito: a cadeia de certificados foi processada, mas terminou em uma raiz não confiável. Isso indica que o certificado do cliente existe e é válido (confirmado pela data de expiração em 18 meses), mas o servidor não consegue validar a cadeia porque o certificado raiz não está no repositório de âncoras de confiança. A causa mais provável é que o certificado raiz foi inadvertidamente removido do repositório Trusted Root Certification Authorities durante ou após a atualização do WAC.
A informação sobre a atualização do WAC da versão 2211 para 2306 é propositalmente irrelevante: ela estabelece uma correlação temporal que induz o leitor a buscar uma causa relacionada ao WAC em si, mas o WAC não gerencia o repositório de certificados raiz do sistema operacional. A alternativa D representa um equívoco clássico: o certificado está em Local Computer > Personal, que é exatamente onde o RasMan espera encontrá-lo para autenticação de máquina.
O distrator mais perigoso é a alternativa A: focar nas permissões da conta de serviço após uma atualização parece razoável, mas a mensagem de erro descreve falha na validação da cadeia, não falha de acesso ao repositório.
Gabarito — Cenário 4
Resposta: C
O impacto colateral real é a limitação de throughput. O SKU Basic de VPN Gateway possui um teto de throughput agregado significativamente inferior ao VpnGw1. Com apenas 3 servidores conectados no momento, esse limite não é percebido. No entanto, à medida que mais servidores forem adicionados via Azure Network Adapter ou que o volume de dados transferido aumentar, o teto do SKU Basic se tornará um gargalo de desempenho.
A alternativa A é falsa: conexões P2S existentes não são desconectadas automaticamente por downgrade de SKU; elas continuam operacionais até que sejam encerradas ativamente. A alternativa B representa um equívoco importante: o SKU Basic suporta autenticação por certificado para P2S; a limitação real do Basic é a ausência de suporte a BGP e protocolos mais avançados, não o método de autenticação. A alternativa D não corresponde a nenhum comportamento documentado do VPN Gateway.
Árvore de Troubleshooting: Azure Network Adapter
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado. A cada nó de pergunta, responda com base no que você pode verificar diretamente no servidor ou no portal do Azure antes de avançar para o próximo nível. Nós de validação intermediária indicam pontos onde uma verificação específica é necessária antes de confirmar a hipótese. Ao atingir um nó vermelho, a causa está identificada; ao atingir um nó verde sem causa, a ação descrita resolve ou isola o problema. Nunca pule níveis: a sequência de perguntas existe para evitar ações corretivas aplicadas à causa errada.