Laboratório de Troubleshooting: Associate an ASG to a network interface
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador de rede relata que uma máquina virtual chamada vm-app-prod-01 parou de receber tráfego na porta 8080 após uma reorganização de ambientes realizada na semana anterior. A VM está em execução, o agente está respondendo a pings internos e o Network Security Group associado à subnet contém uma regra de entrada explícita permitindo TCP 8080 de qualquer origem com prioridade 300.
Durante a investigação, o administrador confirma que a NIC da VM foi removida do ASG asg-app-tier e adicionada ao ASG asg-web-tier durante a reorganização. O ASG asg-web-tier possui apenas regras que permitem tráfego nas portas 80 e 443. Não há NSG associado diretamente à NIC da VM.
Informação adicional: a VM foi redimensionada de Standard_B2s para Standard_D2s_v3 no mesmo período e a conta de armazenamento de diagnóstico foi desanexada temporariamente.
Qual é a causa raiz do bloqueio de tráfego na porta 8080?
A) O redimensionamento da VM causou a dissociação automática do NSG da subnet, removendo as regras de permissão.
B) A NIC está associada ao ASG asg-web-tier, cujas regras de NSG não cobrem a porta 8080, e a regra da subnet não referencia o ASG correto para esse tráfego.
C) A desanexação da conta de armazenamento de diagnóstico interrompeu o fluxo de logs do NSG, fazendo o tráfego parecer bloqueado sem estar.
D) A regra de entrada na subnet com prioridade 300 está sendo sobreposta por uma regra de negação implícita no ASG asg-web-tier com prioridade inferior.
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que tráfego lateral entre VMs da camada de banco de dados e VMs da camada de aplicação está ocorrendo em portas não autorizadas. A causa foi confirmada: as NICs das VMs de banco de dados foram associadas tanto ao ASG asg-db-tier quanto ao ASG asg-app-tier por engano durante um script de provisionamento automatizado.
O ambiente está em produção ativa. A janela de manutenção começa em 4 horas. As regras de NSG que usam asg-app-tier como origem ou destino estão sendo auditadas, mas a auditoria ainda não foi concluída. Modificar as regras de NSG fora da janela requer aprovação do comitê de mudanças.
Qual é a ação correta a tomar agora, antes da janela de manutenção?
A) Remover imediatamente as NICs das VMs de banco de dados do ASG asg-app-tier via Portal do Azure, sem aguardar a janela.
B) Aguardar a conclusão da auditoria das regras de NSG e, dentro da janela de manutenção, remover as NICs do ASG incorreto após validar o impacto.
C) Criar um NSG temporário com regras de negação explícita e associá-lo diretamente às NICs das VMs de banco de dados até a janela de manutenção.
D) Excluir o ASG asg-app-tier imediatamente para eliminar o vetor de risco, recriando-o durante a janela com as associações corretas.
Cenário 3 — Causa Raiz
Uma VM chamada vm-worker-03 faz parte de um conjunto de workers que processam filas internas. Todas as VMs do conjunto foram provisionadas com o mesmo template e devem ter comportamento idêntico de rede. As demais VMs do conjunto processam normalmente, mas vm-worker-03 não consegue iniciar conexões de saída para o endpoint interno 10.10.5.20:5432.
O administrador verifica o NSG associado à subnet e encontra a seguinte regra de saída:
Nome: Allow-DB-Outbound
Direção: Outbound
Prioridade: 200
Protocolo: TCP
Porta de destino: 5432
Destino: asg-db-tier
Origem: asg-worker-tier
Ação: Allow
O administrador também confirma que 10.10.5.20 é a NIC de uma VM de banco de dados corretamente associada ao asg-db-tier. O NSG da subnet das VMs worker não possui regras de negação explícita para porta 5432. A VM vm-worker-03 foi provisionada manualmente após as demais, usando o mesmo template, e está no mesmo Resource Group e subnet.
Informação adicional: a VM passou por uma atualização de sistema operacional há dois dias e seu disco de dados foi expandido ontem.
Qual é a causa raiz do problema de conectividade de vm-worker-03?
A) A atualização do sistema operacional redefiniu as configurações de firewall local, bloqueando saída na porta 5432.
B) A expansão do disco de dados causou uma reinicialização que dissociou a NIC do NSG da subnet.
C) A NIC de vm-worker-03 não foi associada ao ASG asg-worker-tier, portanto a regra de saída que usa esse ASG como origem não se aplica a ela.
D) A regra Allow-DB-Outbound com prioridade 200 está sendo substituída por uma regra padrão de negação de saída com prioridade 100 que bloqueia tráfego para endereços privados.
Cenário 4 — Sequência de Diagnóstico
Uma VM em produção parou de receber tráfego na porta 443 após uma alteração de configuração de rede. O administrador suspeita que o problema está relacionado à associação de ASG na NIC da VM, mas não tem certeza.
Os passos de investigação disponíveis são:
- Verificar se a NIC da VM está associada ao ASG referenciado como destino nas regras de NSG que permitem porta 443
- Usar a ferramenta IP flow verify no Network Watcher para confirmar se o tráfego na porta 443 está sendo bloqueado e por qual regra
- Revisar o histórico de alterações recentes via Azure Activity Log para identificar qual operação foi realizada na NIC ou no ASG
- Confirmar que a VM está em execução e que a NIC está no estado conectado (attached) à VM
- Verificar se o NSG correto está associado à subnet ou à NIC e se contém regras que referenciam o ASG como destino para porta 443
Qual é a sequência correta de investigação?
A) 3 -> 1 -> 5 -> 2 -> 4
B) 4 -> 2 -> 5 -> 1 -> 3
C) 2 -> 3 -> 4 -> 5 -> 1
D) 4 -> 3 -> 5 -> 1 -> 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A causa raiz é a troca de ASG da NIC. Quando a NIC saiu do asg-app-tier e entrou no asg-web-tier, ela passou a ser avaliada pelas regras de NSG que referenciam esse novo ASG. O NSG da subnet possui uma regra que permite porta 8080, mas essa regra não referencia o asg-web-tier como destino, e sim o asg-app-tier (implicitamente, dado o contexto da reorganização). Como não há NSG na NIC e a regra da subnet é genérica para qualquer origem, o fluxo passa a depender de qual ASG está associado à NIC para que as regras baseadas em ASG se apliquem corretamente.
A informação irrelevante é a desanexação da conta de armazenamento de diagnóstico e o redimensionamento da VM. Nenhuma dessas operações afeta a associação de ASG nem as regras de NSG. O redimensionamento pode causar brevidade de indisponibilidade, mas não altera configurações de rede.
O distrator mais perigoso é a alternativa A, pois atribui o problema ao redimensionamento da VM. Essa hipótese levaria o administrador a recriar a VM desnecessariamente, sem corrigir a associação de ASG, mantendo o problema intacto.
Gabarito — Cenário 2
Resposta: B
O cenário apresenta duas restrições críticas: a auditoria ainda não foi concluída e alterações de NSG fora da janela requerem aprovação. A remoção do ASG incorreto das NICs (alternativa A) seria a ação técnica correta, mas a alternativa B é a única que respeita simultaneamente as restrições do ambiente: aguardar a auditoria para entender o impacto completo e executar a correção dentro da janela aprovada.
A alternativa A ignora a dependência da auditoria. Remover o ASG sem saber quais regras de NSG o referenciam pode quebrar conectividade legítima de outras VMs que dependem da associação atual.
A alternativa C cria um NSG temporário na NIC, o que tecnicamente funcionaria para bloquear tráfego indesejado, mas também é uma modificação de NSG que requer aprovação do comitê, tornando-a igualmente inválida fora da janela.
A alternativa D é o distrator mais perigoso: excluir o ASG afetaria imediatamente todas as regras de NSG que o referenciam em todo o ambiente, podendo causar interrupção generalizada de tráfego legítimo em produção.
Gabarito — Cenário 3
Resposta: C
A regra Allow-DB-Outbound usa asg-worker-tier explicitamente como origem. Isso significa que ela se aplica somente às NICs que estão associadas a esse ASG. Como vm-worker-03 foi provisionada manualmente após as demais, é altamente provável que a associação ao asg-worker-tier tenha sido omitida durante o provisionamento manual. Sem essa associação, a NIC da VM não é reconhecida como origem válida pela regra, e o tráfego de saída para 5432 não é permitido.
As informações sobre atualização de sistema operacional e expansão de disco são irrelevantes e foram incluídas deliberadamente para desviar o foco. Nenhuma dessas operações remove a associação de uma NIC a um ASG.
A alternativa A representa o erro clássico de confundir a camada de SO com a camada de rede do Azure. O firewall local não seria consistente com o comportamento das demais VMs, que foram atualizadas pelo mesmo template.
A alternativa D é tecnicamente incorreta: as regras padrão de saída do Azure permitem tráfego para VNets e internet, e a regra de negação padrão tem prioridade 65500, não 100.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 4 -> 2 -> 5 -> 1 -> 3
- Passo 4 primeiro: confirmar que a VM está em execução e a NIC está conectada é o pré-requisito básico. Qualquer diagnóstico de rede pressupõe que o recurso está operacional.
- Passo 2 em seguida: o IP flow verify entrega a resposta objetiva sobre bloqueio e identifica qual regra está atuando. Isso delimita o escopo antes de investigar configurações.
- Passo 5 depois: com a regra problemática identificada, é possível verificar se o NSG está corretamente associado e se a regra em questão referencia um ASG.
- Passo 1 após: sabendo qual regra e qual ASG estão envolvidos, verifica-se se a NIC da VM está de fato associada ao ASG esperado.
- Passo 3 por último: o Activity Log confirma o que mudou e quando, sendo útil para documentação e para evitar recorrência, não para diagnóstico inicial.
A alternativa A começa pelo Activity Log, o que é um erro comum: o log descreve o que aconteceu, mas não confirma se o tráfego está realmente bloqueado nem qual regra é responsável. Começar por ele atrasa o diagnóstico.
A alternativa C começa pelo IP flow verify sem antes confirmar que a VM está ativa, o que pode gerar resultados inconclusivos ou enganosos se a VM estiver em estado de falha.
Árvore de Troubleshooting: Associate an ASG to a network interface
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul: pergunta diagnóstica objetiva com resposta sim ou não
- Vermelho: causa identificada, origem confirmada do problema
- Verde: ação recomendada ou resolução a executar
- Laranja: validação ou verificação intermediária antes de prosseguir
Como percorrer a árvore diante de um problema real: comece pelo nó raiz, que representa o sintoma observado. A cada nó azul, responda à pergunta com base no que é verificável diretamente no ambiente, seja via Portal do Azure, CLI ou Network Watcher. Siga o ramo correspondente à sua resposta. Ao chegar em um nó vermelho, a causa está identificada. Ao chegar em um nó laranja, execute a validação antes de avançar. Ao chegar em um nó verde, execute a ação descrita e retorne ao nó de validação para confirmar a resolução.