Pular para o conteúdo principal

Laboratório Técnico: Diagnose and Resolve Virtual Network Gateway Connectivity Issues

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de rede configurou uma conexão VPN Gateway do tipo Site-to-Site entre a rede on-premises e uma VNet do Azure. A conexão aparece com status "Connected" no portal, mas o tráfego não flui entre as redes. O time já confirmou que as rotas estão corretas e que os NSGs não bloqueiam o tráfego.

Qual é a causa mais provável do problema?

A) O SKU do VPN Gateway não suporta conexões Site-to-Site
B) O shared key (PSK) configurado no gateway do Azure não corresponde ao configurado no dispositivo on-premises
C) O BGP não foi habilitado na conexão, impedindo a troca de rotas
D) A gateway subnet foi configurada com prefixo /29, que é insuficiente para o serviço

Questão 2 — Cenário Técnico​

Um engenheiro está diagnosticando uma conexão ExpressRoute que apresenta latência elevada e perda de pacotes intermitente. O circuito está provisionado e o status do peering privado aparece como "Provisioned". O comando abaixo foi executado no gateway:

Get-AzVirtualNetworkGatewayBGPPeerStatus `
  -VirtualNetworkGatewayName "gw-prod" `
  -ResourceGroupName "rg-network"

O resultado mostra o peer com estado "Idle" em vez de "Connected".

Qual é a causa mais provável desse comportamento?

A) O circuito ExpressRoute foi provisionado em um tier Local, que não suporta BGP
B) O ASN configurado no gateway do Azure conflita com o ASN do provedor de conectividade
C) A sessão BGP entre o gateway e o Microsoft Edge Router (MSEE) não foi estabelecida, indicando problema na camada de peering
D) O gateway está usando SKU Standard, que não suporta ExpressRoute

Questão 3 — Verdadeiro ou Falso​

Um VPN Gateway configurado com Active-Active e BGP habilitado garante failover automático sem interrupção de tráfego (zero downtime) em caso de falha de uma das instâncias do gateway, pois as duas instâncias mantêm sessões BGP independentes com o dispositivo on-premises.

Essa afirmação é verdadeira ou falsa?

Questão 4 — Cenário Técnico​

Uma organização possui a seguinte topologia:

On-premises
    |
    | VPN Site-to-Site
    |
Hub VNet (10.0.0.0/16)
    |
    | VNet Peering
    |
Spoke VNet (10.1.0.0/16)

Usuários on-premises conseguem acessar recursos no Hub VNet, mas não conseguem acessar recursos no Spoke VNet. O VNet Peering entre Hub e Spoke está no estado "Connected".

Qual configuração está ausente ou incorreta?

A) A gateway subnet do Hub VNet precisa ser expandida para incluir o prefixo do Spoke VNet
B) O peering do Hub para o Spoke precisa ter "Allow gateway transit" habilitado, e o peering do Spoke para o Hub precisa ter "Use remote gateways" habilitado
C) Uma rota estática apontando para 10.1.0.0/16 precisa ser adicionada diretamente no dispositivo VPN on-premises
D) O BGP precisa ser habilitado no VPN Gateway para propagar automaticamente as rotas do Spoke VNet

Questão 5 — Múltipla Escolha​

Ao usar o Network Watcher VPN Diagnostics para solucionar uma conexão Site-to-Site com falha, o log retorna o seguinte erro:

IKE authentication credentials are unacceptable

Quais dos seguintes itens devem ser verificados prioritariamente com base nessa mensagem?

A) A largura de banda contratada no SKU do gateway e a contagem de túneis ativos
B) O tráfego de retorno e se o NSG da gateway subnet está bloqueando UDP 500
C) O Pre-Shared Key, os parâmetros de IKE Phase 1 (encryption, integrity, DH group) e os certificados, se autenticação por certificado for usada
D) A sobreposição de prefixos de endereço entre a VNet do Azure e a rede on-premises

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Explicar:

  • O status "Connected" no portal indica que o túnel IKE foi estabelecido com sucesso na camada de controle, mas isso não garante fluxo de dados. O PSK é negociado durante o IKE Phase 1; se houver divergência, o túnel pode aparecer como conectado em um lado e com falha no outro, dependendo da implementação do dispositivo. Nesse cenário, a inconsistência do PSK é a causa clássica de "connected sem tráfego".
  • As alternativas A e D são descartáveis no contexto: o SKU mínimo (Basic) suporta Site-to-Site, e /29 é o prefixo mínimo aceito para gateway subnet (6 IPs utilizáveis, suficiente). BGP (alternativa C) é opcional para Site-to-Site e sua ausência não impede o fluxo de tráfego quando rotas estáticas estão corretas, como o enunciado confirma.
  • Escolher C levaria a investigar uma funcionalidade que não é pré-requisito, atrasando o diagnóstico real.

Gabarito — Questão 2​

Resposta: C

Explicar:

  • O estado "Idle" no BGP peer status indica que a sessão TCP na porta 179 não foi estabelecida entre o gateway do Azure e o MSEE. Isso ocorre na camada de peering, não na camada de provisionamento do circuito. Um circuito com status "Provisioned" confirma apenas que o provedor completou a configuração física e lógica do link, mas não que o BGP está funcional.
  • A alternativa A é incorreta: o tier Local suporta BGP, a diferença está nas rotas anunciadas (apenas locais). A alternativa B é plausível, mas conflito de ASN geralmente impede o estabelecimento do peering desde o início, não causa estado "Idle" intermitente. A alternativa D é incorreta: o SKU Standard suporta ExpressRoute.
  • O próximo passo diagnóstico seria verificar configurações de peering IP, VLAN ID e ASN no portal do circuito ExpressRoute e junto ao provedor.

Gabarito — Questão 3​

Resposta: Falso

Explicar:

  • A configuração Active-Active com BGP melhora significativamente a resiliência, mas não garante zero downtime. Em caso de falha de uma instância, as sessões BGP estabelecidas por aquela instância precisam ser reestabelecidas pela instância sobrevivente. Esse processo de reconvergência do BGP introduz uma interrupção de alguns segundos a dezenas de segundos, dependendo dos timers configurados (hold time, keepalive).
  • O ponto não óbvio é que "Active-Active" descreve a topologia de encaminhamento de tráfego (ambas as instâncias processam dados simultaneamente), não a continuidade das sessões de controle. Para minimizar o downtime, é necessário que o dispositivo on-premises também suporte dois túneis independentes com as duas instâncias e que os timers BGP sejam otimizados.
  • Confundir "alta disponibilidade" com "zero downtime" é um equívoco comum ao projetar soluções de resiliência com VPN Gateway.

Gabarito — Questão 4​

Resposta: B

Explicar:

  • Em uma topologia Hub-and-Spoke, o VPN Gateway reside no Hub. Para que tráfego originado on-premises alcance o Spoke, o Azure precisa que duas configurações de peering estejam ativas em conjunto: "Allow gateway transit" no lado do Hub (permitindo que o gateway seja compartilhado com redes em peering) e "Use remote gateways" no lado do Spoke (instruindo o Spoke a usar o gateway remoto do Hub para rotear tráfego externo).
  • A alternativa A é incorreta: a gateway subnet não precisa conhecer prefixos dos Spokes; o roteamento é feito pelo plano de dados, não pelo dimensionamento da subnet. A alternativa C confunde responsabilidade de roteamento: o dispositivo on-premises não precisa de rotas estáticas manuais quando o gateway anuncia as rotas corretamente. A alternativa D é uma condição que melhora a propagação dinâmica, mas não resolve a ausência das flags de peering.
  • Esse é um dos erros de configuração mais frequentes em topologias Hub-and-Spoke no Azure.

Gabarito — Questão 5​

Resposta: C

Explicar:

  • A mensagem IKE authentication credentials are unacceptable é gerada durante o IKE Phase 1 e indica que as credenciais de autenticação apresentadas pelo peer foram rejeitadas. Isso abrange três cenários principais: PSK incorreto ou divergente, parâmetros criptográficos incompatíveis (algoritmo de criptografia, algoritmo de integridade ou grupo Diffie-Hellman), ou certificado inválido/expirado quando autenticação por certificado é usada.
  • A alternativa B (NSG bloqueando UDP 500) causaria falha na inicialização do IKE, mas o log de diagnóstico nem chegaria à fase de autenticação para gerar essa mensagem específica. A alternativa D (sobreposição de prefixos) causaria problemas de roteamento após o túnel estabelecido, não falha de autenticação. A alternativa A é irrelevante para esse tipo de erro.
  • Saber interpretar os códigos de erro do VPN Diagnostics é essencial para reduzir o tempo de resolução, pois cada mensagem aponta para uma camada específica do processo de negociação IKE.