Laboratório de Troubleshooting: Configure an NSG for Remote Server Administration, Including Azure Bastion
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações implantou o Azure Bastion no nível de SKU Standard em uma VNet chamada vnet-mgmt-prod. A subnet do Bastion foi criada com o nome AzureBastionSubnet e o CIDR 10.0.255.0/27. Um NSG chamado nsg-bastion foi associado a essa subnet. O time relata que, ao tentar iniciar uma sessão RDP via portal do Azure em direção a uma VM na subnet 10.0.1.0/24, a conexão falha imediatamente com a mensagem:
Failed to connect. Please check your Bastion configuration and try again.
O analista verifica o NSG nsg-bastion e coleta as seguintes regras de entrada:
Name Priority Direction Access Protocol Source Port
----------------------- --------- ---------- ------- --------- --------------- -----
Allow-HTTPS-Inbound 100 Inbound Allow TCP Internet 443
Allow-GatewayMgr 200 Inbound Allow TCP GatewayManager 443
DenyAll-Inbound 300 Inbound Deny * * *
E as seguintes regras de saída:
Name Priority Direction Access Protocol Source Destination Port
----------------------- --------- ---------- ------- --------- --------------- --------------- -----
Allow-SSH-RDP-Out 100 Outbound Allow TCP * VirtualNetwork 22,3389
Allow-AzureCloud-Out 200 Outbound Allow TCP * AzureCloud 443
DenyAll-Outbound 300 Outbound Deny * * * *
O Bastion está com status Succeeded no portal. A VM de destino está em execução e possui um NSG que permite tráfego RDP da subnet do Bastion.
Qual é a causa raiz do problema?
A) O CIDR 10.0.255.0/27 da AzureBastionSubnet é insuficiente para o SKU Standard, que requer uma subnet de pelo menos /26.
B) A regra de saída Allow-AzureCloud-Out deveria usar a tag de serviço AzureCloud na porta 443, mas está configurada com a origem como * em vez de AzureBastionSubnet.
C) Está faltando a regra de entrada que permite tráfego da tag de serviço AzureBastionHostCommunication para comunicação entre instâncias do Bastion.
D) A regra de saída Allow-SSH-RDP-Out está configurada corretamente, mas a regra DenyAll-Outbound com prioridade 300 é avaliada antes das regras de permissão, bloqueando todo o tráfego.
Cenário 2 — Decisão de Ação
A equipe de segurança de uma empresa identificou que o NSG nsg-admin-vms, associado à subnet subnet-admin contendo VMs de administração, possui a seguinte regra de entrada:
Name: Allow-RDP-Any
Priority: 100
Direction: Inbound
Access: Allow
Protocol: TCP
Source: *
Destination: VirtualNetwork
Port: 3389
A causa está confirmada: essa regra expõe a porta RDP diretamente para a internet. A empresa decidiu migrar o acesso remoto para Azure Bastion como solução definitiva, mas a implantação do Bastion está estimada para ser concluída em 5 dias úteis. As VMs de administração estão em uso ativo por uma equipe de 8 administradores que trabalham remotamente. A empresa não possui VPN Gateway configurado na VNet.
Qual é a ação correta a tomar neste momento?
A) Remover a regra Allow-RDP-Any imediatamente e solicitar que os administradores aguardem a conclusão da implantação do Bastion.
B) Substituir a regra Allow-RDP-Any por uma regra que restrinja a origem aos endereços IP públicos conhecidos dos administradores remotos, mantendo acesso necessário até o Bastion estar disponível.
C) Associar um novo NSG sem regras de entrada à subnet subnet-admin para bloquear todo o tráfego de entrada imediatamente.
D) Reduzir a prioridade da regra Allow-RDP-Any de 100 para 4000 para diminuir seu impacto enquanto o Bastion é implantado.
Cenário 3 — Causa Raiz
Uma VM chamada vm-db-01 na subnet-data da vnet-core-prod não está respondendo a conexões SSH iniciadas a partir do Azure Bastion. O Bastion está devidamente configurado na AzureBastionSubnet com CIDR 10.0.255.0/26 e seu NSG está com todas as regras obrigatórias aplicadas. O analista verifica o NSG nsg-data, associado à subnet-data, e obtém as seguintes regras de entrada:
Name Priority Direction Access Protocol Source Port
------------------------ --------- ---------- ------- --------- ------------------- -----
Allow-Bastion-SSH 100 Inbound Allow TCP 10.0.255.0/26 22
Allow-App-to-DB 200 Inbound Allow TCP 10.0.1.0/24 5432
Allow-HTTPS-Internal 300 Inbound Allow TCP VirtualNetwork 443
DenyAll-Inbound 1000 Inbound Deny * * *
A equipe confirma que o Bastion inicia a sessão SSH sem erros de configuração no portal, mas a conexão fica em estado de carregamento e expira após 60 segundos. A vm-db-01 está em execução e o serviço SSH está ativo e escutando normalmente na porta 22, conforme verificado com acesso direto via console serial. O disco da VM foi expandido de 128 GB para 256 GB há 2 dias.
Qual é a causa raiz do problema?
A) A regra Allow-Bastion-SSH usa o CIDR 10.0.255.0/26 como origem, mas o Bastion no SKU Standard pode originar tráfego de IPs fora desse CIDR ao usar recursos avançados de sessão.
B) A expansão do disco da VM causou um estado de instabilidade temporária que impede o daemon SSH de aceitar novas conexões externas, mesmo com o serviço aparentemente ativo.
C) O NSG nsg-data não possui uma regra de saída explícita permitindo que a subnet-data responda ao tráfego SSH de volta para o Bastion, e as regras padrão de saída bloqueiam esse retorno.
D) O firewall do sistema operacional da vm-db-01 está bloqueando conexões SSH originadas do CIDR da subnet do Bastion, apesar de o NSG permitir o tráfego.
Cenário 4 — Sequência de Diagnóstico
Um administrador relata que perdeu o acesso SSH a uma VM Linux chamada vm-ops-02 na vnet-ops-prod. O acesso era feito exclusivamente via Azure Bastion. Nenhuma alteração foi feita na VM nas últimas 24 horas. O Bastion estava funcionando normalmente ontem. Ao tentar iniciar a sessão no portal, o erro retornado é:
Connection failed. Unable to reach the virtual machine.
Os passos de investigação disponíveis são:
- [P] Verificar se a VM
vm-ops-02está em execução e se sua NIC está em estado conectado. - [Q] Verificar se o NSG associado à NIC ou subnet da VM possui uma regra de entrada permitindo SSH na porta 22 a partir do CIDR da
AzureBastionSubnet. - [R] Verificar se o Azure Bastion está com status operacional e se o recurso não foi acidentalmente excluído ou reiniciado.
- [S] Verificar se a
AzureBastionSubnetmantém seu CIDR original e se o NSG do Bastion possui todas as regras obrigatórias intactas. - [T] Usar o console serial do Azure para verificar se o daemon SSH está ativo e se o firewall do SO não foi alterado.
Qual é a sequência correta de investigação?
A) R, S, P, Q, T
B) P, Q, R, S, T
C) Q, R, P, S, T
D) S, R, Q, P, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: A
O SKU Standard do Azure Bastion requer que a AzureBastionSubnet tenha tamanho mínimo de /26, o que equivale a 64 endereços. O CIDR 10.0.255.0/27 fornece apenas 32 endereços, que é o mínimo para o SKU Basic. O SKU Standard suporta recursos como sessões simultâneas em maior escala, e a subnet subdimensionada impede a alocação correta das instâncias do Bastion, resultando na falha de conexão mesmo com o recurso aparecendo como Succeeded no portal.
A pista decisiva é a combinação entre o SKU Standard declarado e o CIDR /27. O status Succeeded no portal não garante que o Bastion está operacional, pois esse status reflete apenas a criação do recurso, não sua capacidade de operar corretamente.
O distrator C é tecnicamente relevante em outros contextos: a tag AzureBastionHostCommunication é obrigatória para comunicação entre nós do Bastion em SKUs com múltiplas instâncias, mas sua ausência causaria degradação ou falha parcial, não falha imediata em todas as conexões como descrito. Além disso, o enunciado não menciona múltiplas instâncias configuradas.
O distrator D representa confusão fundamental sobre como NSGs funcionam: as regras são avaliadas em ordem crescente de prioridade, portanto uma regra de permissão com prioridade 100 é sempre avaliada antes de uma regra de negação com prioridade 300. Esse distrator seria verdadeiro apenas se a prioridade da negação fosse menor que a da permissão.
Agir com base no distrator D levaria a criar regras adicionais desnecessárias, sem resolver o problema de subnet subdimensionada que é a causa real.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é que os 8 administradores precisam de acesso remoto contínuo durante os 5 dias até o Bastion estar disponível, e não há VPN Gateway como alternativa. Remover a regra sem substituição (distrator A) causaria interrupção total do trabalho da equipe por dias, o que é inaceitável. A solução correta é reduzir a exposição ao máximo possível dentro das restrições: limitar a origem RDP aos IPs públicos conhecidos dos administradores elimina a exposição para toda a internet enquanto mantém o acesso necessário.
O distrator A ignora a restrição de continuidade operacional. O distrator C é ainda mais extremo: associar um NSG sem regras bloquearia não apenas RDP mas todo o tráfego de entrada, incluindo qualquer comunicação legítima das VMs.
O distrator D é o mais perigoso: alterar a prioridade de uma regra não restringe sua origem. Uma regra Allow-RDP-Any com prioridade 4000 ainda permite tráfego de qualquer origem caso nenhuma outra regra a contradiga antes. Se o NSG não tiver uma regra de negação explícita com prioridade menor que 4000, a exposição permanece idêntica.
Gabarito — Cenário 3
Resposta: D
As regras padrão de saída de um NSG permitem tráfego para VirtualNetwork e para Internet. Isso significa que a subnet-data pode responder ao Bastion via TCP sem necessidade de regra de saída explícita. O NSG de entrada do nsg-data permite SSH da origem correta. O Bastion está configurado corretamente e inicia a sessão sem erro. O serviço SSH está ativo na VM. Com todas essas verificações descartando o NSG e o Bastion, a causa está no sistema operacional da VM.
A pista decisiva é a combinação: conexão que inicia mas expira após 60 segundos, e SSH confirmado como ativo via console serial. Esse padrão de comportamento indica que o pacote chega à VM (NSG permite), o daemon SSH está ativo, mas algo no SO recusa ou descarta a conexão após o handshake inicial. O firewall do SO (como iptables ou ufw) pode ter sido alterado por um processo automatizado ou política de segurança independentemente de alterações manuais.
A informação sobre a expansão do disco é irrelevante: operações de disco no Azure não afetam o daemon SSH nem o estado do firewall do SO.
O distrator C é factualmente incorreto: as regras padrão de saída do Azure NSG permitem tráfego de saída para VirtualNetwork, o que inclui a subnet do Bastion. Não há necessidade de regra de saída explícita para esse cenário.
O distrator A inventa um comportamento inexistente: o SKU Standard do Bastion não origina tráfego fora do CIDR da AzureBastionSubnet.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: R, S, P, Q, T.
O raciocínio diagnóstico correto para uma falha de acesso via Bastion começa pelo componente intermediário, o Bastion em si, e avança progressivamente para os componentes de destino.
- R verifica se o Bastion está operacional. Se o recurso foi excluído ou está degradado, todas as demais verificações são irrelevantes.
- S verifica a integridade da configuração do Bastion: CIDR da subnet e regras NSG obrigatórias. Problemas aqui afetam todas as sessões, não apenas uma VM.
- P verifica se a VM de destino está em execução e conectada. Uma VM parada ou com NIC desconectada seria inacessível independentemente do Bastion.
- Q verifica se o NSG da VM permite tráfego SSH originado da subnet do Bastion. Essa é a causa mais comum de falha de conectividade quando o Bastion está saudável.
- T usa o console serial para verificar o estado interno da VM, como daemon SSH e firewall do SO, apenas após descartar todas as causas externas.
A alternativa B começa pela VM antes de verificar o Bastion, o que pode levar a conclusões errôneas: uma VM aparentemente saudável pode parecer o problema quando na verdade o Bastion está com falha. A alternativa C começa pelo NSG da VM antes de confirmar que o Bastion está ativo, desperdiçando tempo em configurações que podem estar corretas. A alternativa D começa pela subnet do Bastion, o que é razoável, mas pula a verificação do status operacional do recurso antes de entrar em detalhes de configuração.
Árvore de Troubleshooting: Configure an NSG for Remote Server Administration, Including Azure Bastion
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada na árvore
- Azul: nó de pergunta diagnóstica, exige observação ou verificação ativa
- Vermelho: causa identificada, raiz do problema confirmada
- Verde: ação recomendada ou resolução aplicável ao contexto
- Laranja: validação ou verificação intermediária após uma ação corretiva
Para usar esta árvore diante de um problema real, comece identificando se o acesso falhou via Azure Bastion ou via conexão direta com regras NSG. Para o caminho do Bastion, verifique o recurso e sua subnet antes de inspecionar a VM de destino. Para o caminho direto, verifique a porta, o protocolo e a origem da regra NSG. Em ambos os caminhos, o firewall do sistema operacional é investigado por último, após descartar todas as causas de infraestrutura. Cada ramificação elimina uma classe de problema e direciona para a verificação mais específica seguinte, evitando saltos prematuros para diagnósticos internos antes de confirmar os externos.