As questões de rede mais difíceis do AZ-104 são assim: "A VM1 não consegue se conectar à VM2. Qual é a causa e o que você deve usar para confirmá-la?". O guia oficial de habilidades lista separadamente "solucionar problemas de conectividade de rede" e "avaliar as regras de segurança efetivas nos NSGs", e o domínio de monitoramento acrescenta "usar o Azure Network Watcher e o Connection Monitor". Um erro em qualquer ponto, seja um NSG, uma rota, um emparelhamento ou o DNS, produz o mesmo sintoma ("não conecta"), então sem uma ordem fixa de verificações você fica dando voltas entre as opções.
Este artigo apresenta uma ordem de cinco etapas que reduz um problema de conectividade de fora para dentro, junto com a ferramenta do Network Watcher para cada etapa. Ele explica a ordem em que os NSGs são avaliados na sub-rede e na NIC, as regras de seleção de rota e o próximo salto, por que o emparelhamento não é transitivo e como funciona o trânsito de gateway, e os vínculos e o registro automático das zonas DNS privadas. Os conceitos básicos de NSG, UDR e emparelhamento estão em VNet, NSG, DNS e Load Balancer Explicados para Iniciantes.
---
Reduza um Problema de Conectividade em Cinco Etapas
Quando uma encomenda não chega, você verifica em ordem: o endereço está certo? a rota de entrega está certa? a segurança do prédio barrou? as redes de entrega regionais estão conectadas? o destinatário está em casa? Verificar um problema de conectividade entre VMs na mesma ordem encontra a causa rapidamente.
!Cinco etapas que reduzem um problema de conectividade de uma VM de fora para dentro
| Etapa | Pergunta | Ferramentas para verificar | |------|------|------| | 1. Resolução de nomes | O nome resolve para o IP certo? | nslookup, o vínculo de rede virtual da zona DNS privada | | 2. Rotas | O pacote vai para o próximo salto certo? | Próximo salto, as rotas efetivas da NIC | | 3. Regras de segurança | Algum NSG permite? | Verificação de fluxo de IP, diagnóstico de NSG, regras de segurança efetivas | | 4. Topologia | As VNets, e a rede local, estão conectadas? | Status do emparelhamento, solução de problemas de VPN, solução de problemas de conexão | | 5. Dentro da VM | O aplicativo está escutando e o firewall do SO permite? | Solução de problemas de conexão, captura de pacotes, diagnóstico dentro da VM |
Dica para o exame: Se a questão diz "descobrir qual regra bloqueia o tráfego", a resposta é a verificação de fluxo de IP; "descobrir para onde o tráfego é roteado" é o Próximo salto; "testar uma vez a conexão entre uma VM e um destino e ver latência e saltos" é a solução de problemas de conexão; "monitorar continuamente ao longo do tempo" é o Connection Monitor.
---
As Ferramentas do Network Watcher de Relance
O Network Watcher é um conjunto de ferramentas para diagnosticar recursos de rede IaaS como VMs, VNets, balanceadores de carga e gateways de aplicativo. Lembre também que ele não foi feito para monitorar serviços PaaS.
| Ferramenta | O que faz | O que o resultado informa | |------|------|------| | Verificação de fluxo de IP (IP flow verify) | Verifica se um pacote de 5 tuplas específico é permitido, do ponto de vista de uma VM | Permitido/negado + o nome da regra que decidiu | | Diagnóstico de NSG | Verifica o tráfego de um IP, prefixo ou marca de serviço em uma VM, conjunto de dimensionamento ou gateway de aplicativo | Permitido/negado + a regra; pode adicionar uma regra de prioridade mais alta | | Próximo salto (Next hop) | Verifica a rota até um IP de destino específico | Tipo de próximo salto, endereço IP, ID da tabela de rotas | | Regras de segurança efetivas | Mostra as regras realmente aplicadas a uma NIC | O NSG da NIC, o NSG da sub-rede e a soma dos dois | | Solução de problemas de conexão | Testa uma vez a conexão de uma VM (e outros) para uma VM, FQDN, URI ou IP | Alcance, latência, saltos, problemas detectados | | Connection Monitor | Monitora continuamente as conexões entre pontos de extremidade do Azure e híbridos | Latência e perda ao longo do tempo, alertas | | Captura de pacotes | Captura remotamente o tráfego de uma VM ou conjunto de dimensionamento | Análise no nível de pacote | | Solução de problemas de VPN | Diagnostica gateways de rede virtual e suas conexões | Integridade e logs do gateway e da conexão | | Logs de fluxo | Registra informações do tráfego IP no armazenamento, visualizadas com a análise de tráfego | Registros de fluxos permitidos e negados | | Topologia | Visualiza as relações dos recursos de rede entre assinaturas e regiões | Entender a configuração |
Para logs de fluxo, use de agora em diante os logs de fluxo de rede virtual. Não é mais possível criar novos logs de fluxo de NSG, e eles serão desativados em 30 de setembro de 2027.
---
As Regras de NSG São Avaliadas Duas Vezes, em Ordem Fixa
Se um prédio tem um segurança na portaria (o NSG da sub-rede) e uma fechadura na porta do escritório (o NSG da NIC), você precisa passar pelos dois. O Azure avalia os dois em ordem diferente conforme a direção.
| Direção | Ordem de avaliação | Resultado | |------|------|------| | Entrada | NSG da sub-rede → NSG da NIC | Se a sub-rede negar, o NSG da NIC não é avaliado | | Saída | NSG da NIC → NSG da sub-rede | Se a NIC negar, o NSG da sub-rede não é avaliado | | Entre VMs da mesma sub-rede | A mesma ordem acima | O NSG da sub-rede vale mesmo dentro da mesma sub-rede |
Dentro de cada NSG, as regras são avaliadas do menor número de prioridade (100–4096) para cima, e a avaliação para na primeira regra que corresponder. Os NSGs têm estado, então o tráfego de resposta de uma conexão permitida volta sem precisar de outra regra. Quando você não criou regras, estas regras padrão se aplicam.
| Direção | Regra padrão (prioridade) | Significado | |------|------|------| | Entrada | AllowVNetInBound (65000) | Permite tráfego de dentro da VNet e de VNets emparelhadas | | Entrada | AllowAzureLoadBalancerInBound (65001) | Permite as investigações de integridade do balanceador de carga | | Entrada | DenyAllInBound (65500) | Nega todo o resto | | Saída | AllowVnetOutBound (65000) | Permite tráfego que vai para a VNet | | Saída | AllowInternetOutBound (65001) | Permite tráfego que vai para a internet | | Saída | DenyAllOutBound (65500) | Nega todo o resto |
Verificando com uma Questão de Tabela
O NSG da sub-rede tem a regra "prioridade 200, permitir TCP 3389", e o NSG da NIC da VM1 tem a regra "prioridade 100, negar todo o tráfego da internet". Uma tentativa de RDP da internet para a VM1 passa pelo NSG da sub-rede, mas é negada pelo NSG da NIC. As regras de segurança efetivas mostram juntas as regras dos dois NSGs, e a verificação de fluxo de IP retorna o nome da regra de negação do NSG da NIC.
Dica para o exame: Ao escolher a correção, verifique em qual NSG a regra entra e com qual prioridade. Para vencer a regra de negação de prioridade 100 do NSG da NIC, é preciso adicionar uma regra de permissão com número menor que 100 nesse mesmo NSG da NIC. Por menor que seja o número usado no NSG da sub-rede, a negação do NSG da NIC não muda.
---
Rotas: Para Onde Vai o Pacote?
Mesmo quando um NSG permite o tráfego, um pacote enviado para o lugar errado nunca conecta. O Azure cria automaticamente rotas do sistema para cada sub-rede, e rotas definidas pelo usuário (UDRs) e rotas BGP podem substituí-las.
Existem duas regras de seleção de rota. Primeiro, o Azure escolhe a rota cujo prefixo corresponde de forma mais específica ao IP de destino (correspondência de prefixo mais longo). Se existirem 10.0.0.0/16 e 10.0.0.0/24, o tráfego para 10.0.0.5 segue a rota /24. Se os prefixos forem idênticos, a prioridade é rota definida pelo usuário → rota BGP → rota do sistema.
| Tipo de próximo salto | Significado | O que lembrar | |------|------|------| | Rede virtual | Entregue diretamente dentro do espaço de endereços da VNet | Rota do sistema | | Internet | Enviado para a internet | O padrão da rota do sistema 0.0.0.0/0 | | Solução de virtualização | Enviado ao IP privado de uma NVA, como um firewall | O encaminhamento de IP precisa estar habilitado na NIC dessa NVA | | Gateway de rede virtual | Enviado a um gateway de VPN ou ExpressRoute | Tráfego com destino à rede local | | Nenhum | O tráfego é descartado | Para bloquear um intervalo de propósito |
Dica para o exame: Se "uma UDR envia 0.0.0.0/0 para uma NVA e todo o tráfego da internet para", suspeite da configuração de encaminhamento de IP da NIC da NVA ou do roteamento dentro da NVA. A ferramenta Próximo salto mostra o tipo de próximo salto como "Solução de virtualização" junto com o ID da tabela de rotas aplicada.
---
Emparelhamento e Gateways: Problemas de Topologia
Mesmo com NSGs e rotas corretos, as VNets não se comunicam sem uma conexão entre elas. A pegadinha mais comum é que o emparelhamento não é transitivo. Se a VNet A está emparelhada com a B e a B com a C, A e C continuam sem poder se comunicar diretamente.
| Solução | Como funciona | |------|------| | Emparelhar A e C diretamente | O mais simples, mas o número de emparelhamentos cresce rápido conforme as VNets aumentam | | Passar por uma NVA ou Azure Firewall no hub | Uma UDR nas sub-redes spoke define o firewall do hub como próximo salto; permitir o tráfego encaminhado no emparelhamento | | Compartilhar o gateway do hub | Com o trânsito de gateway, os spokes usam o gateway de VPN ou ExpressRoute do hub |
O trânsito de gateway consiste em ativar "Permitir trânsito de gateway" no emparelhamento do lado do hub e "Usar gateways remotos" no lado do spoke. No portal atual eles aparecem como "Permitir que o gateway ou o servidor de rota desta rede virtual encaminhe tráfego" e "Usar o gateway ou o servidor de rota da rede virtual remota". Uma VNet que usa um gateway remoto não pode ter um gateway próprio.
Os espaços de endereços de duas VNets emparelhadas não podem se sobrepor Um status de emparelhamento "Iniciado" significa que o emparelhamento do outro lado a