Laboratório de Troubleshooting: Configure encryption over ExpressRoute
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de redes reporta que o túnel IPsec sobre ExpressRoute Private Peering foi configurado há dois dias e está com status Connected no portal do Azure. No entanto, aplicações on-premises não conseguem alcançar VMs na VNet Azure, e o time abre um chamado descrevendo o problema como "VPN funciona mas tráfego não passa".
O engenheiro responsável coleta as seguintes informações:
# Saída do comando Get-AzVirtualNetworkGatewayConnection no lado Azure
ConnectionStatus : Connected
EgressBytesTransferred : 0
IngressBytesTransferred : 0
RoutingWeight : 10
SharedKey : (configurado)
# Verificação de rota no dispositivo on-premises
Destination Gateway Flags Metric Interface
10.10.0.0/16 192.168.1.1 UG 100 eth0
172.16.0.0/12 0.0.0.0 U 0 lo
O circuito ExpressRoute está Provisioned e o peering BGP está estabelecido com prefixos sendo anunciados em ambas as direções. O time também informa que realizou uma troca do cabo de uplink do switch de distribuição ontem, mas a conectividade com outros serviços Azure via ExpressRoute (sem IPsec) voltou a funcionar normalmente após a troca.
Qual é a causa raiz do problema?
A) A troca do cabo de uplink causou uma interrupção no BGP que ainda não se recuperou completamente, impedindo o tráfego de fluir pelo túnel.
B) A política de IKE/IPsec (algoritmos, DH group ou lifetime) está incompatível entre o dispositivo on-premises e o Azure VPN Gateway, resultando em um túnel conectado sem tráfego.
C) A rota para a VNet Azure no dispositivo on-premises está apontando para o gateway errado, fazendo com que o tráfego destinado à VNet não entre no túnel IPsec.
D) O SharedKey foi configurado incorretamente; quando há divergência de chave pré-compartilhada, o Azure reporta o status Connected mas não encaminha tráfego.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o cipher suite MACsec configurado no dispositivo on-premises é GCM-AES-256, mas o lado Microsoft está provisionado com GCM-AES-128. A equipe precisa resolver o problema. O contexto operacional é o seguinte:
- O circuito ExpressRoute está em produção e carrega tráfego crítico de outras aplicações que não usam MACsec
- A janela de manutenção programada é em 48 horas
- O engenheiro possui permissão para alterar configurações no dispositivo on-premises imediatamente
- Alterar o cipher suite no lado Microsoft exige abertura de chamado no provedor de conectividade e leva entre 24 e 72 horas
- O time de segurança confirma que
GCM-AES-128atende à política corporativa vigente
Qual é a ação correta a tomar neste momento?
A) Abrir chamado no provedor para alterar o cipher suite Microsoft para GCM-AES-256, pois algoritmos mais fortes devem ser priorizados, e aguardar a janela de manutenção.
B) Alterar o cipher suite no dispositivo on-premises para GCM-AES-128 imediatamente, sem aguardar a janela de manutenção, pois a mudança é no equipamento local e o impacto se limita ao enlace MACsec ainda não operacional.
C) Desabilitar o MACsec temporariamente no dispositivo on-premises e aguardar a janela de manutenção para reabilitar com o cipher suite correto, pois qualquer alteração em produção exige janela formal.
D) Escalar para o time de segurança a necessidade de revisar a política corporativa e autorizar GCM-AES-256 no lado Microsoft antes de qualquer alteração.
Cenário 3 — Causa Raiz
Um arquiteto configurou IPsec sobre ExpressRoute em um ambiente com o seguinte diagrama de conectividade:
On-premises (10.0.0.0/8)
|
[VPN Device - IKEv2]
|
[ExpressRoute Circuit - Private Peering]
|
[VPN Gateway - active-active - VpnGw2]
|
VNet: 172.16.0.0/16
Após a configuração, o tráfego flui normalmente. Dois dias depois, o time de operações habilita o ExpressRoute Global Reach para conectar esse circuito a um segundo circuito ExpressRoute de outra filial. Imediatamente após a ativação, o time reporta que as VMs na VNet Azure passaram a ser alcançáveis a partir da segunda filial sem passar pelo túnel IPsec, e o tráfego aparece nos logs sem criptografia.
O time de segurança reporta a falha como crítica. Qual é a causa raiz?
A) O ExpressRoute Global Reach criou um caminho de roteamento direto entre os dois circuitos que contorna o VPN Gateway, fazendo o tráfego da segunda filial alcançar a VNet sem passar pelo túnel IPsec.
B) A ativação do Global Reach reiniciou o VPN Gateway no modo active-active, e durante o reinício o tráfego foi encaminhado sem criptografia pela rota ExpressRoute nativa.
C) O VPN Gateway no SKU VpnGw2 não suporta múltiplos circuitos ExpressRoute simultaneamente, e o segundo circuito foi tratado como conexão direta sem política IPsec.
D) O BGP do segundo circuito anunciou rotas com AS Path mais curto para a VNet, fazendo o VPN Gateway preferir o caminho não criptografado na tabela de roteamento.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O túnel IPsec sobre ExpressRoute foi configurado ontem. O status no portal é Connected, mas aplicações on-premises não alcançam as VMs na VNet Azure. O ExpressRoute em si funciona normalmente para outros recursos."
Os passos de investigação disponíveis são:
- Verificar se as rotas para a VNet estão sendo aprendidas via BGP no dispositivo on-premises e apontam para o IP do VPN Gateway como next-hop
- Confirmar que o status do túnel IPsec é Connected e verificar os contadores de bytes transferidos (EgressBytes e IngressBytes)
- Comparar os parâmetros IKE/IPsec configurados no dispositivo on-premises com a política configurada no Azure VPN Gateway
- Verificar a conectividade básica do circuito ExpressRoute e confirmar que o peering BGP está estabelecido
- Executar um traceroute de on-premises para o IP de uma VM na VNet e observar onde o tráfego para
Qual é a sequência correta de diagnóstico?
A) 4 → 2 → 1 → 5 → 3
B) 2 → 4 → 3 → 1 → 5
C) 1 → 3 → 4 → 2 → 5
D) 4 → 1 → 2 → 3 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está na tabela de rotas do dispositivo on-premises: a rota para 10.10.0.0/16 (a VNet Azure) aponta para 192.168.1.1, que é o gateway padrão da rede local, e não para o endpoint do túnel IPsec. Para que o tráfego entre no túnel, a rota de destino deve ter como next-hop o IP do túnel IPsec ou da interface de VPN, não o gateway de LAN. Com essa configuração, os pacotes destinados à VNet saem pela interface errada e nunca chegam ao VPN Gateway Azure.
A informação sobre a troca do cabo de uplink é a informação irrelevante incluída propositalmente. O fato de que o BGP está estabelecido e outros serviços funcionam via ExpressRoute confirma que a infraestrutura de transporte está saudável; a troca do cabo não tem relação com o roteamento do túnel IPsec.
A alternativa B é um distrator plausível porque incompatibilidade de política IKE gera exatamente o sintoma de túnel Connected com zero bytes. Porém, o enunciado informa que o túnel foi configurado há dois dias e tem status Connected; se a política estivesse errada desde o início, o túnel nunca teria chegado ao estado Connected. A alternativa D está incorreta porque divergência de SharedKey impede o túnel de chegar ao estado Connected. O distrator mais perigoso seria escolher a alternativa A, pois levaria o engenheiro a investigar o BGP e o circuito quando o problema está na tabela de rotas local.
Gabarito — Cenário 2
Resposta: B
As restrições do cenário definem o espaço de decisão: o MACsec ainda não está operacional (portanto não há impacto em tráfego existente ao alterar o enlace), o time de segurança confirmou que GCM-AES-128 é aceitável, e o engenheiro tem permissão imediata para agir no dispositivo on-premises. Alterar o cipher suite no equipamento local para GCM-AES-128 resolve o problema sem afetar nenhum tráfego em produção, pois o enlace MACsec com cipher errado simplesmente não está operando.
A alternativa A ignora duas restrições críticas: prioriza um algoritmo mais forte quando a política corporativa já aceita o mais fraco, e aciona um processo de 24 a 72 horas junto ao provedor quando a solução pode ser aplicada imediatamente no lado on-premises. A alternativa C seria correta se a alteração no dispositivo on-premises carregasse risco real de impacto em produção, mas como o MACsec não está ativo, não há tráfego a proteger. A alternativa D desvia o problema para uma revisão de política quando a decisão já foi tomada pelo time de segurança. O distrator mais perigoso é C, pois a prudência de "aguardar janela" é válida em muitos contextos, mas aqui representa paralisia desnecessária.
Gabarito — Cenário 3
Resposta: A
O ExpressRoute Global Reach conecta dois circuitos ExpressRoute diretamente na rede backbone da Microsoft, criando um caminho de roteamento entre as duas redes on-premises que não passa pela VNet Azure nem pelo VPN Gateway. Quando a segunda filial envia tráfego para a VNet (172.16.0.0/16), o Global Reach não está envolvido nesse caminho; mas quando a VNet tenta alcançar a segunda filial, o roteamento pode tomar o caminho direto via Global Reach, contornando o VPN Gateway e portanto bypassando o IPsec.
Mais criticamente, tráfego originado da segunda filial que eventualmente precisa alcançar a VNet pode encontrar um caminho via Global Reach para o primeiro circuito e então para a VNet sem passar pelo túnel IPsec configurado. O Global Reach não herda políticas de segurança do VPN Gateway; é uma conexão de roteamento independente.
A alternativa B é incorreta porque o Global Reach não reinicia o VPN Gateway. A alternativa C está errada; o VpnGw2 suporta múltiplos circuitos e a limitação descrita não existe. A alternativa D é um distrator técnico plausível, mas AS Path mais curto via BGP não explica o bypass do VPN Gateway; o problema é arquitetural, não de preferência de rota. O distrator mais perigoso é D, pois levaria o engenheiro a investigar tabelas BGP quando a causa é a própria topologia introduzida pelo Global Reach.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 4 → 2 → 1 → 5 → 3, que segue a lógica de diagnóstico progressivo do mais simples ao mais específico.
O passo 4 valida a fundação: se o ExpressRoute e o BGP não estiverem saudáveis, nada mais funciona e os demais passos são irrelevantes. O passo 2 verifica o estado do túnel e, principalmente, os contadores de bytes; zeros em ambos os sentidos confirmam que o problema é de encaminhamento, não de estabelecimento do túnel. O passo 1 investiga o roteamento on-premises para determinar se o tráfego sequer está sendo direcionado ao túnel. O passo 5 confirma empiricamente onde o tráfego para, corroborando ou refutando a hipótese de roteamento. O passo 3 é deixado por último porque a análise de parâmetros IKE/IPsec é a investigação mais profunda e demorada; ela só é necessária se os passos anteriores não revelarem a causa.
A alternativa B começa pelo túnel antes de validar a infraestrutura subjacente, o que pode levar a conclusões falsas. A alternativa C começa por roteamento antes de confirmar que o túnel existe, invertendo a ordem lógica. A alternativa D é a mais próxima da correta, mas inverte a ordem de 1 e 2, indo para roteamento antes de confirmar o estado do túnel e dos contadores, o que perde a informação diagnóstica dos bytes transferidos antes de investigar rotas.
Árvore de Troubleshooting: Configure encryption over ExpressRoute
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma geral e siga as ramificações respondendo cada pergunta com base no que você consegue observar no ambiente. Cada resposta elimina um conjunto de hipóteses e direciona para a próxima verificação. Quando um nó vermelho é alcançado, a causa está identificada e a ação corretiva deve ser aplicada antes de retornar ao início para confirmar a resolução.