Laboratório de Troubleshooting: Implement VNet Peering
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que duas VMs em VNets diferentes não conseguem se comunicar, apesar de o peering aparecer como Connected em ambos os lados no portal Azure. As VNets envolvidas são:
| Atributo | VNet-Alpha | VNet-Beta |
|---|---|---|
| Região | East US | East US |
| Espaço de endereçamento | 10.10.0.0/16 | 10.20.0.0/16 |
| Subscription | Sub-Prod | Sub-Prod |
| Status do peering | Connected | Connected |
A VM de origem (vm-alpha-01, IP 10.10.1.4) tenta alcançar a VM de destino (vm-beta-01, IP 10.20.1.4) via ICMP. O teste falha consistentemente. A equipe informa que o NSG associado à subnet de destino foi revisado e não possui regras de negação para ICMP. A equipe também menciona que a VM de destino foi migrada para uma subnet diferente dentro da VNet-Beta há três dias, sem alterações no peering.
O engenheiro executa o seguinte comando na VM de origem:
traceroute 10.20.1.4
traceroute to 10.20.1.4 (10.20.1.4), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
Em seguida, verifica as rotas efetivas na NIC de vm-alpha-01:
Prefixo de endereço Próximo salto Tipo de próximo salto
10.10.0.0/16 - VnetLocal
10.20.0.0/16 - VNetPeering
0.0.0.0/0 - Internet
Qual é a causa raiz da falha de comunicação?
A) O peering entre VNet-Alpha e VNet-Beta está em estado inconsistente no plano de dados, apesar de exibir Connected no plano de controle, e precisa ser recriado.
B) O NSG associado à NIC da VM de destino possui uma regra implícita bloqueando ICMP que não foi verificada pela equipe, diferente do NSG da subnet.
C) A rota para 10.20.0.0/16 está corretamente presente, mas um NSG associado à NIC de vm-alpha-01 bloqueia o tráfego de saída antes que ele saia da VM de origem.
D) O espaço de endereçamento das VNets está sobrepostos de forma não detectada pelo portal, o que causa o descarte silencioso de pacotes no plano de dados.
Cenário 2 — Decisão de Ação
A causa de uma falha de conectividade em um ambiente hub-and-spoke foi identificada: o peering entre VNet-Hub e VNet-Spoke-Finance tem a opção Use remote gateways habilitada no lado do Spoke, mas a opção Allow gateway transit não está habilitada no lado do Hub.
O ambiente possui as seguintes restrições:
- O VPN Gateway na VNet-Hub está em uso ativo por outras 6 VNets spoke em produção
- A janela de manutenção programada começa em 4 horas
- A equipe de rede possui permissão Network Contributor nas VNets Hub e Spoke-Finance
- A equipe de segurança precisa ser notificada antes de qualquer alteração que afete o gateway
Qual é a ação correta a tomar neste momento?
A) Desabilitar Use remote gateways no lado do Spoke-Finance, recriar o peering do zero em ambos os lados e habilitar ambas as opções simultaneamente durante a janela de manutenção.
B) Habilitar imediatamente Allow gateway transit no lado do Hub, pois a alteração é não disruptiva para os outros spokes já conectados e não requer janela de manutenção.
C) Notificar a equipe de segurança, aguardar a janela de manutenção e habilitar Allow gateway transit no lado do Hub dentro da janela aprovada.
D) Criar um novo VPN Gateway diretamente na VNet-Spoke-Finance para eliminar a dependência do Hub e resolver o problema sem necessidade de alteração no peering existente.
Cenário 3 — Causa Raiz
Um engenheiro tenta criar um peering entre VNet-Prod e VNet-Analytics, ambas em regiões diferentes e em subscriptions distintas dentro do mesmo tenant do Microsoft Entra ID. Ao tentar criar o peering pelo portal Azure, o engenheiro recebe a seguinte mensagem de erro:
Error: AuthorizationFailed
Message: "The client 'eng-user@contoso.com' with object id '...' does not have
authorization to perform action
'Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write'
over scope '/subscriptions/sub-analytics-id/resourceGroups/rg-analytics/
providers/Microsoft.Network/virtualNetworks/VNet-Analytics'
or the scope is invalid."
O engenheiro verifica suas permissões e encontra o seguinte:
Subscription: sub-prod
Role: Network Contributor (escopo: /subscriptions/sub-prod)
Subscription: sub-analytics
Role: Reader (escopo: /subscriptions/sub-analytics)
A equipe informa adicionalmente que o peering do lado de VNet-Prod já foi criado com sucesso pelo mesmo engenheiro ontem, e que ambas as VNets têm espaços de endereçamento não sobrepostos. O time de analytics relatou que nenhuma alteração foi feita nas VNets nas últimas 72 horas.
Qual é a causa raiz do erro observado?
A) O peering entre subscriptions diferentes requer que o engenheiro possua a função Owner em pelo menos uma das subscriptions, e a função Network Contributor não é suficiente.
B) O engenheiro não possui a permissão Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write sobre a VNet-Analytics, pois sua função na subscription de analytics é apenas Reader.
C) O erro ocorre porque o peering do lado de VNet-Prod foi criado sem que o lado de VNet-Analytics existisse simultaneamente, e o Azure invalida o primeiro lado após 24 horas sem confirmação.
D) O peering entre regiões diferentes em subscriptions distintas exige que ambas as VNets estejam no mesmo grupo de recursos para que as permissões cruzadas sejam resolvidas corretamente.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: recursos na VNet-Spoke-Dev não conseguem acessar a rede on-premises via VPN Gateway localizado na VNet-Hub, embora outros spokes estejam funcionando normalmente. O peering entre Hub e Spoke-Dev exibe status Connected em ambos os lados.
Os passos de investigação disponíveis são:
[P] Verificar as rotas efetivas na NIC de uma VM dentro de VNet-Spoke-Dev
[Q] Verificar se Allow gateway transit esta habilitado no peering do lado do Hub
[R] Confirmar se Use remote gateways esta habilitado no peering do lado do Spoke-Dev
[S] Confirmar que o VPN Gateway na VNet-Hub esta em estado Running
[T] Comparar as configuracoes de peering do Spoke-Dev com as de um spoke que funciona
Qual sequência de investigação representa o raciocínio diagnóstico mais eficiente?
A) S, Q, R, T, P
B) P, S, Q, R, T
C) T, Q, R, P, S
D) Q, R, S, P, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na distinção entre o NSG da subnet e o NSG da NIC. A equipe verificou o NSG associado à subnet de destino e não encontrou bloqueios, mas não verificou o NSG associado diretamente à NIC da VM de destino. No Azure, NSGs podem ser associados tanto a subnets quanto a NICs individualmente, e ambos são processados de forma independente. Um NSG na NIC pode bloquear tráfego que já passou pelo NSG da subnet.
A informação sobre a migração da VM para outra subnet há três dias é propositalmente irrelevante: as rotas efetivas confirmam que 10.20.0.0/16 está acessível via VNetPeering, o que descarta qualquer problema de roteamento decorrente da mudança de subnet. O peering está funcionando no plano de controle e de dados para o prefixo correto.
A alternativa A representa o erro de diagnóstico de recorrer à ação mais drástica (recriar o peering) sem esgotamento das hipóteses menos invasivas. A alternativa D é impossível dado que os espaços de endereçamento são visivelmente não sobrepostos (10.10.x.x e 10.20.x.x). A alternativa C não é sustentada pelas rotas efetivas: se um NSG de saída na NIC de origem bloqueasse o tráfego, as rotas efetivas ainda apareceriam, mas o bloqueio ocorreria antes da transmissão, o que tornaria o traceroute igualmente inconclusivo. Porém, o cenário específico aponta para o destino, onde dois níveis de NSG existem e apenas um foi verificado.
O distrator mais perigoso é A: agir recriando o peering interromperia a conectividade para ambas as VNets durante o processo, causando impacto desnecessário em produção.
Gabarito — Cenário 2
Resposta: C
A causa já está identificada e a correção técnica é simples: habilitar Allow gateway transit no lado do Hub. No entanto, o cenário estabelece duas restrições críticas que tornam a ação imediata (alternativa B) incorreta:
- A equipe de segurança precisa ser notificada antes de qualquer alteração que afete o gateway.
- Existe uma janela de manutenção programada em 4 horas.
Embora habilitar Allow gateway transit seja tecnicamente não disruptivo para os spokes já conectados, ignorar o processo de notificação à equipe de segurança viola uma restrição explícita do cenário. Em ambientes regulados ou com processos de change management, executar alterações fora do processo aprovado é um erro operacional independentemente do impacto técnico.
A alternativa A adiciona complexidade desnecessária: recriar o peering do zero envolveria indisponibilidade temporária e não é exigido pela causa identificada. A alternativa D resolve o problema por um caminho tecnicamente válido, mas desproporcional: criar um segundo VPN Gateway tem custo elevado, tempo de provisionamento significativo e contradiz o design hub-and-spoke adotado. O distrator mais perigoso é B: a ação é tecnicamente correta, mas executada ignorando o processo de governança definido no enunciado.
Gabarito — Cenário 3
Resposta: B
A mensagem de erro é direta e autoexplicativa: AuthorizationFailed com a ação virtualNetworkPeerings/write sobre o escopo da subscription de analytics. A tabela de permissões confirma que o engenheiro possui apenas a função Reader na subscription sub-analytics, que não concede permissão de escrita sobre recursos de rede.
A criação de um peering entre subscriptions exige que o responsável tenha permissão de escrita sobre a VNet em cada lado do peering. O lado de VNet-Prod foi criado com sucesso porque o engenheiro possui Network Contributor nessa subscription. O lado de VNet-Analytics falha porque Reader não inclui a ação de escrita necessária.
A informação sobre as 72 horas sem alterações e os espaços de endereçamento não sobrepostos são propositalmente irrelevantes: nenhum desses fatores influencia o erro de autorização. A alternativa A representa um erro de escalada de requisito: Owner não é necessário, apenas a ação de escrita sobre a VNet específica. A alternativa C descreve um comportamento que não existe no Azure: peerings criados com sucesso em um lado não expiram nem são invalidados automaticamente. O distrator mais perigoso é A: levaria o engenheiro a solicitar permissões excessivas desnecessariamente, violando o princípio de menor privilégio.
Gabarito — Cenário 4
Resposta: A
A sequência correta é S, Q, R, T, P, e o raciocínio segue a lógica de eliminação progressiva do mais simples para o mais específico:
S primeiro: confirmar que o VPN Gateway está operacional elimina a hipótese de falha de infraestrutura compartilhada antes de investigar configurações do peering específico.
Q segundo: verificar Allow gateway transit no Hub identifica se a permissão de trânsito está concedida pelo lado que possui o gateway.
R terceiro: verificar Use remote gateways no Spoke-Dev confirma se o spoke está configurado para usar o gateway remoto.
T quarto: comparar com um spoke funcional é um passo de validação por contraste, útil após confirmar que as opções individuais estão ou não configuradas, revelando discrepâncias sutis de configuração.
P por último: verificar rotas efetivas é o passo de confirmação final, que valida se o plano de dados reflete as configurações do plano de controle corretamente.
A alternativa B (P, S, Q, R, T) começa pelas rotas efetivas, o que mostraria o sintoma mas não orientaria a investigação antes de verificar a infraestrutura base. A alternativa C começa pela comparação, que é útil mas pressupõe que o engenheiro já sabe o que comparar. A alternativa D inverte a ordem lógica ao investigar configurações do peering antes de confirmar que o gateway está disponível.
Árvore de Troubleshooting: Implement VNet Peering
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| 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 de falha de conectividade. Responda cada pergunta com base no que você observa no ambiente: status do portal, rotas efetivas na NIC, regras de NSG ativas, configurações de peering em ambos os lados. Siga o caminho que corresponde ao que você vê, sem pular etapas de validação. Cada nó laranja representa um ponto onde você coleta evidência antes de decidir o próximo passo. Os nós vermelhos confirmam a causa e os nós verdes indicam a ação corretiva a executar.