Laboratório de Troubleshooting: Create and configure a virtual network gateway
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede recém-concluiu a implantação de um VPN Gateway com SKU VpnGw2 em modo Active-Active para uma conexão Site-to-Site com o datacenter on-premises. O dispositivo VPN on-premises é um appliance certificado pela Microsoft, com IKEv2 habilitado e chave pré-compartilhada configurada corretamente em ambos os lados.
Após a implantação, os dois túneis aparecem como Connected no portal do Azure. No entanto, máquinas virtuais na VNet não conseguem alcançar hosts on-premises por IP, e hosts on-premises não conseguem alcançar as VMs.
A equipe coleta as seguintes informações adicionais:
- O Local Network Gateway foi criado com o prefixo
10.10.0.0/16 - O espaço de endereços da VNet é
10.20.0.0/16 - As VMs estão na subnet
10.20.1.0/24 - Os hosts on-premises que precisam ser alcançados estão em
10.10.5.0/24 - O SKU
VpnGw2foi escolhido por requisito de throughput; o SKUVpnGw1foi descartado - O gateway foi provisionado há 40 minutos e o status de ambos os túneis é
Connectedhá 35 minutos - Não há Network Security Group associado à GatewaySubnet
Qual é a causa raiz da falha de conectividade?
A) O modo Active-Active requer que o dispositivo on-premises suporte BGP. Como a configuração usa roteamento estático, o tráfego não é encaminhado corretamente pelos dois túneis.
B) O prefixo configurado no Local Network Gateway não cobre os hosts on-premises de destino, impedindo que o gateway saiba para onde encaminhar o tráfego de retorno.
C) A ausência de um NSG na GatewaySubnet impede que o tráfego IPSec seja inspecionado, fazendo com que os pacotes sejam descartados silenciosamente.
D) O gateway ainda está em processo de convergência de rota. O tempo de 35 minutos de status Connected ainda não é suficiente para que as tabelas de roteamento se estabilizem com SKU VpnGw2.
Cenário 2 — Decisão de Ação
A causa de uma falha foi identificada: o Virtual Network Gateway de produção está operando com SKU VpnGw1, e o throughput agregado das conexões S2S atingiu consistentemente 95% do limite do SKU durante o horário comercial, causando perda de pacotes e latência elevada. A equipe precisa fazer upgrade para VpnGw2.
O contexto operacional é o seguinte:
- O gateway atende 3 conexões S2S ativas para filiais críticas
- Existe uma janela de manutenção programada para esta sexta-feira às 23h, com duração de 2 horas, aprovada pelo Change Advisory Board (CAB)
- O time de operações on-premises das filiais foi notificado e estará de prontidão durante a janela
- A equipe de rede Azure tem acesso completo ao portal e ao PowerShell
- Um engenheiro sugere executar o upgrade imediatamente para evitar mais degradação durante o dia
- O ambiente de homologação não possui gateway equivalente para testar o procedimento
Qual é a ação correta a tomar neste momento?
A) Executar o upgrade imediatamente via PowerShell para minimizar o impacto da degradação em curso, já que a causa está confirmada e o procedimento é documentado.
B) Aguardar a janela de manutenção aprovada e executar o upgrade na sexta-feira às 23h, seguindo o processo de change management estabelecido.
C) Criar um novo gateway com SKU VpnGw2 em paralelo, migrar as conexões e deletar o gateway antigo, tudo ainda hoje, para evitar interrupção planejada.
D) Abrir um chamado no suporte da Microsoft solicitando que o upgrade seja feito sem interrupção, já que o ambiente é produtivo e crítico.
Cenário 3 — Causa Raiz
Uma empresa usa Point-to-Site (P2S) com autenticação via certificado para acesso remoto de desenvolvedores. O ambiente funciona há seis meses sem incidentes. Na última semana, três desenvolvedores reportaram que não conseguem mais conectar o cliente VPN. Outros 14 desenvolvedores continuam conectando normalmente.
O output do cliente VPN nos computadores afetados é:
Connecting to VPN gateway...
Authentication failed: certificate validation error (code 0x80090326)
The certificate chain was issued by an authority that is not trusted.
Informações coletadas pela equipe:
- Os três desenvolvedores afetados receberam novos laptops corporativos na última semana
- O certificado raiz no gateway P2S não foi alterado recentemente
- Os outros 14 desenvolvedores usam máquinas mais antigas e continuam funcionando
- A configuração do gateway P2S não foi modificada nos últimos 30 dias
- O SKU do gateway é
VpnGw1, com capacidade disponível para novas conexões - Os certificados de cliente foram exportados do mesmo template usado pelos outros desenvolvedores
Qual é a causa raiz do problema?
A) O SKU VpnGw1 atingiu o limite de conexões P2S simultâneas, e as novas tentativas de conexão são rejeitadas com erro de certificado como mensagem genérica de falha.
B) O certificado raiz configurado no gateway expirou recentemente, mas como as sessões existentes usam cache de autenticação, apenas novas conexões são afetadas.
C) Os novos laptops não têm o certificado raiz da cadeia instalado no repositório de certificados confiáveis do sistema operacional, fazendo com que a validação da cadeia falhe no lado do cliente.
D) Os certificados de cliente foram exportados sem a chave privada, o que é detectado apenas no momento da conexão em máquinas onde o perfil VPN é importado pela primeira vez.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe um chamado: a conexão ExpressRoute entre o Azure e o datacenter on-premises está com status Not Connected no portal, após ter funcionado normalmente por meses. Nenhuma alteração foi realizada no lado do Azure nas últimas 48 horas.
Os passos de investigação disponíveis são:
- Verificar se o Virtual Network Gateway do tipo ExpressRoute está com status
Succeededno provisionamento - Contatar o provedor de conectividade para verificar se houve evento no circuito físico ou no peering BGP do lado deles
- Verificar o status do ExpressRoute Circuit no portal do Azure (campo
Provider statuseCircuit status) - Executar o comando
Get-AzVirtualNetworkGatewayConnectionpara verificar o estado da conexão lógica entre o gateway e o circuito - Revisar os logs de alterações no Azure Activity Log nas últimas 48 horas para confirmar se houve alguma modificação não registrada
Qual é a sequência correta de investigação?
A) 1 → 3 → 4 → 2 → 5
B) 5 → 1 → 3 → 2 → 4
C) 3 → 1 → 4 → 5 → 2
D) 5 → 3 → 1 → 4 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: A
A pista central está na combinação entre modo Active-Active e ausência de BGP. No modo Active-Active, o gateway cria dois túneis IPSec, cada um com um IP público distinto. Para que o tráfego seja balanceado e encaminhado corretamente entre os dois túneis, o dispositivo on-premises precisa suportar BGP. Com roteamento estático, o dispositivo on-premises não tem mecanismo para distribuir o tráfego entre os dois endpoints do gateway, e os pacotes de retorno podem ser enviados para o túnel errado ou descartados, mesmo com ambos os túneis aparecendo como Connected.
O status Connected dos túneis confirma que o plano de controle IPSec está funcional. Isso elimina problemas de chave pré-compartilhada ou de negociação IKE.
A informação sobre o SKU VpnGw2 e o tempo de provisionamento é irrelevante para o diagnóstico e foi incluída propositalmente. O SKU não influencia o comportamento de roteamento no modo Active-Active, e 35 minutos de conexão estabelecida é mais que suficiente para convergência.
A alternativa B seria válida em outro contexto, mas o prefixo 10.10.0.0/16 cobre o destino 10.10.5.0/24, portanto não é a causa. A alternativa C inverte a lógica: a ausência de NSG na GatewaySubnet é o estado recomendado, não um problema. A alternativa D não tem fundamento técnico.
O distrator mais perigoso é o B, pois induz o engenheiro a revisar o Local Network Gateway sem necessidade, perdendo tempo em produção.
Gabarito — Cenário 2
Resposta: B
A causa está identificada e a solução é conhecida, mas o contexto operacional impõe uma restrição crítica: existe uma janela de manutenção aprovada pelo CAB para sexta-feira, e o ambiente de produção atende filiais críticas. O upgrade de SKU causa interrupção de conectividade. Executar esse tipo de mudança fora de uma janela aprovada, sem coordenação com as equipes das filiais e sem validação prévia, viola o processo de change management e expõe a organização a um impacto não controlado.
A degradação em curso é real, mas não configura uma emergência que justifique contornar o processo estabelecido. A alternativa A representa a decisão tecnicamente correta aplicada no momento errado, ignorando a restrição de processo.
A alternativa C é tecnicamente impossível no modelo atual de Virtual Network Gateway: não é possível ter dois gateways do mesmo tipo na mesma VNet simultaneamente para fins de migração in-place. Isso eliminaria essa opção mesmo sem a restrição de processo.
A alternativa D não corresponde a nenhuma capacidade real do suporte Microsoft para este tipo de operação; upgrades de SKU sempre causam interrupção independentemente do canal de execução.
Agir com base na alternativa A seria o erro mais custoso: causaria interrupção imediata, não planejada, das 3 filiais, sem o suporte das equipes on-premises de prontidão.
Gabarito — Cenário 3
Resposta: C
A pista determinante é o padrão de afetados: apenas os desenvolvedores com laptops novos não conseguem conectar, enquanto os demais, com máquinas antigas, funcionam normalmente. O erro certificate chain was issued by an authority that is not trusted é específico: indica que o sistema operacional do cliente não reconhece a autoridade certificadora raiz, não que o certificado de cliente seja inválido.
Em novos laptops corporativos, o repositório de certificados confiáveis pode não ter sido populado com o certificado raiz interno da empresa, que é o mesmo usado para emitir os certificados de cliente P2S. Os laptops antigos já tinham esse certificado raiz instalado, possivelmente via Group Policy ou configuração manual anterior.
A informação sobre o SKU e capacidade disponível é irrelevante e foi incluída propositalmente. O erro de certificado não é uma mensagem genérica de rejeição por capacidade; o SKU VpnGw1 suporta até 250 conexões P2S simultâneas, e 17 conexões estão longe desse limite.
A alternativa B é plausível, mas contraditória com os fatos: se o certificado raiz no gateway tivesse expirado, nenhum cliente conseguiria conectar, não apenas os novos. A alternativa D seria detectada antes da conexão, durante a importação do perfil, e afetaria qualquer máquina nova independentemente do repositório de confiança.
O distrator mais perigoso é o D, pois pode levar a equipe a revogar e reemitir certificados desnecessariamente.
Gabarito — Cenário 4
Resposta: D
A sequência correta é 5 → 3 → 1 → 4 → 2, e o raciocínio segue a lógica de eliminação progressiva do mais simples para o mais complexo, começando pelo que pode ser verificado sem dependência externa.
O passo 5 (Activity Log) vem primeiro porque o enunciado afirma que nenhuma alteração foi feita no Azure. Confirmar ou refutar isso é o ponto de partida: se houver uma alteração registrada, o caminho de diagnóstico muda completamente.
O passo 3 (status do ExpressRoute Circuit) vem a seguir porque o circuito é o recurso de mais alto nível na cadeia. Se o Circuit status ou o Provider status indicar problema, a causa está no circuito ou no provedor, e os passos seguintes perdem relevância imediata.
O passo 1 (status do gateway) verifica se o recurso Azure está saudável antes de inspecionar a conexão lógica que depende dele.
O passo 4 (Get-AzVirtualNetworkGatewayConnection) inspeciona a camada lógica da conexão entre gateway e circuito, útil após confirmar que ambos os recursos subjacentes estão provisionados corretamente.
O passo 2 (contato com o provedor) vem por último porque depende de um agente externo e deve ser acionado somente após esgotar as verificações internas, evitando handoffs desnecessários que atrasam o diagnóstico.
A alternativa A erra ao iniciar pelo gateway antes de verificar o circuito e o Activity Log. A alternativa B começa pelo Activity Log corretamente, mas coloca o contato com o provedor antes da inspeção da conexão lógica. A alternativa C começa pelo circuito sem verificar o Activity Log, perdendo a etapa de confirmação de mudanças.
Árvore de Troubleshooting: Create and configure a virtual network gateway
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (navy) | Sintoma inicial, ponto de entrada |
| Azul (blue) | Pergunta diagnóstica, ponto de decisão |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação intermediária ou validação |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o tipo de falha observada (S2S, ExpressRoute, P2S ou degradação de performance) e siga as ramificações respondendo cada pergunta com base no que é verificável diretamente no portal, em comandos PowerShell ou nos logs. Cada bifurcação elimina uma classe de causa e direciona o diagnóstico para o nível seguinte. Os nós vermelhos indicam que a causa foi isolada; os verdes indicam a ação corretiva correspondente. Nunca pule uma etapa de verificação intermediária (laranja) antes de avançar para a ação corretiva.