APRENDER. PRATICAR. EVOLUIR.Descrever o fluxo antes de alterar regras
Num incidente, “a rede falha” não identifica uma hipótese testável. Regista a VM cliente, origem e destino, portas, protocolo, direção e hora. No exemplo, 10.20.1.7:51024 inicia TCP para 10.30.2.9:443. A resposta inverte esses pares; não é uma nova tentativa equivalente à original. Guarda a resolução DNS efetivamente usada e distingue ligação existente de nova. Uma alteração de configuração, um resultado de uma ferramenta e uma transação da aplicação são evidências diferentes. O objetivo é explicar qual camada já foi confirmada e qual falta observar, conservando o contexto que permite repetir o teste.
Comparar regras no âmbito correto
A prioridade ordena regras de um NSG. Não reúne regras de NIC e subnet numa única lista. Para uma ligação outbound, a NIC é avaliada antes da subnet quando ambos têm NSG; no sentido inbound, a ordem é a inversa. No fixture, Allow 200 na NIC e Deny 300 na subnet deixam o fluxo bloqueado na subnet. O menor número da NIC não anula esse segundo controlo. Antes de criar mais regras, identifica a primeira correspondente em cada âmbito e verifica o tuplo usado. Mantém o ajuste limitado à origem, destino e serviço aprovados. Uma regra mais ampla pode esconder a causa e alterar fluxos que não pertencem ao incidente.
Sessões existentes e políticas admin
Remover uma permissão NSG para novas ligações pode deixar uma sessão estabelecida funcional. Um pedido de retirada de acesso deve distinguir impedir novas sessões de terminar as existentes. Regista a evidência, executa a terminação dirigida pelo procedimento aprovado e comprova ambos os resultados. Se existirem security admin rules, identifica a ação exata: Allow continua para NSGs; Always allow evita essa avaliação para o fluxo correspondente; Deny termina-a com bloqueio. Nenhuma dessas decisões comprova o listener, TLS ou aplicação. Os modelos desta aula tratam estas diferenças em fixtures explícitos; não implementam o motor de autorização Azure nem expiração real de sessões.
Prefixo antes de origem, com exceções explícitas
No exemplo de rotas normais, 10.40.8.19 pertence tanto a 10.40.0.0/16 como a 10.40.8.0/24. O /24 é mais específico e prevalece, mesmo vindo de BGP e existindo UDR /16. Com prefixos iguais, a ordem normal é UDR, BGP e sistema. Esta regra didática não deve ser aplicada cegamente às exceções documentadas: rotas preferidas de rede/peering e rotas de service endpoints exigem leitura própria. As de service endpoint não são substituídas por uma default route para NVA. Compara sempre a rota efetiva do destino concreto com a intenção da mudança, em vez de usar a presença de uma UDR como prova de inspeção.
Uma rota para a NVA não prova trânsito
Uma rota pode entregar tráfego a uma appliance que não está preparada para o encaminhar. Confirma os requisitos da NIC, do sistema ou produto da NVA, as políticas e o retorno. No caso fictício, SYN passa por NVA-A, mas SYN-ACK regressa por NVA-B e é descartado porque o estado de sessão não está lá. A solução depende de um desenho de retorno e disponibilidade compatível com o produto. Um timeout maior não repara o descarte demonstrado. Não assumes que partilha de estado existe nem que qualquer mudança de rota é segura: verifica suporte, capacidade, dependências e possibilidade de rollback antes de executar.
Escolher a próxima observação
IP flow verify ajuda a verificar regras de segurança e admin para um pacote descrito. Allow reduz uma hipótese de filtragem, mas não comprova uma transação. Connection troubleshoot acrescenta evidência de conectividade, portas e percurso conforme o teste. Se a porta não aceita ligações, compara listener real, bind address, firewall guest e logs de arranque. Se TCP é acessível mas TLS falha, trata o contrato de nome e certificado. A documentação atual apresenta uma experiência agentless em preview; não a assumes obrigatória ou geralmente disponível em todos os contextos. Escolhe o modo suportado pelo ambiente e regista o âmbito do resultado.
Exercício de mudança com requisito de inspeção
Um batch deve passar pela NVA-A, mas a rota /24 observada aponta para gateway-B. Produz um registo com destino, prefixos correspondentes, rota selecionada e requisito não cumprido. Propõe uma correção delimitada ou adiamento, identifica quem aprova e define critérios de rollback. O ensaio posterior deve confirmar ida, retorno, observação na appliance e resultado do batch sem duplicados. A tarefa não pede executar Azure: pede construir uma decisão tecnicamente justificada e uma sequência de validação que RUN possa repetir num laboratório autorizado antes da produção.
Resumo: provar o caminho e o resultado
Uma análise completa mantém separados tuplo, regras, estado de sessão, rota, forwarding e aplicação. Para cada conclusão, associa a observação e o seu limite. Uma sessão antiga não testa novas regras; uma UDR não prova next hop efetivo; um Allow não prova listener; TCP não prova TLS nem negócio. O handover deve incluir hipóteses descartadas, alterações aprovadas, critérios de recuperação e sinais de regressão. Os modelos locais apenas verificam estas regras explícitas e aritmética IPv4. Não enviam tráfego nem simulam integralmente Azure, BGP, appliances, políticas ou mecanismos de convergência.
CLIENT 10.20.1.7:51024 -> SERVER 10.30.2.9:443 TCP
NIC NSG: priority=200 action=Allow matches=true
SUBNET NSG: priority=300 action=Deny matches=true
DESTINATION 10.40.8.19
UDR 10.40.0.0/16 -> NVA-A
BGP 10.40.8.0/24 -> gateway-B
SCOPE ordinary routes only; preferred-route exceptions excludedFixture: destino 10.40.8.19; UDR 10.40.0.0/16 → NVA-A; BGP 10.40.8.0/24 → gateway-B. Sem exceções, /24 é escolhido. A inspeção pedida continua por comprovar.
Armadilhas comuns
Comparar prioridades entre NSGs como uma lista única; testar apenas sessões antigas; aplicar longest prefix a exceções; confundir Allow com disponibilidade.
Tópicos relacionados: Diagnóstico de produção · Mudanças e recuperação · Evidência operacional
Explica o resultado com o fluxo concreto e confirma a recuperação pela operação afetada.
Referência: Azure routing and UDRs · AZ-104; skills measured 2026-04-17