Laboratório de Troubleshooting: Create and configure explicit outbound rules, including SNAT
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que VMs em um ambiente de produção perderam conectividade de saída para endpoints externos após uma janela de manutenção realizada na noite anterior. O ambiente usa um Load Balancer Standard público com regras de saída explícitas configuradas há meses sem problemas. Durante a manutenção, o time de infraestrutura adicionou três novas regras de balanceamento de carga para expor novos serviços internos via frontend existente. Nenhuma alteração foi feita nas regras de saída, nos IPs de frontend nem no backend pool.
O engenheiro de plantão executa o seguinte comando para verificar o estado atual:
az network lb outbound-rule list \
--resource-group rg-prod \
--lb-name lb-prod \
--output table
Name Protocol AllocatedOutboundPorts EnableTcpReset IdleTimeoutInMinutes
---------------- ---------- ------------------------ ---------------- ----------------------
outbound-rule-1 Tcp 1024 True 4
A regra de saída está presente e aparentemente íntegra. Os logs de diagnóstico do Load Balancer mostram tentativas de conexão de saída sendo descartadas silenciosamente.
Informações adicionais coletadas:
- O NSG da subnet não foi alterado durante a manutenção
- O
idleTimeoutInMinutesda regra de saída é4, valor mínimo permitido - As novas regras de balanceamento de carga foram criadas com a propriedade
disableOutboundSnatno valor padrão
Qual é a causa raiz da perda de conectividade de saída?
A. O valor allocatedOutboundPorts: 1024 é insuficiente para o volume atual de conexões, causando esgotamento de SNAT.
B. As novas regras de balanceamento de carga foram criadas com disableOutboundSnat: false, reativando o SNAT automático via inbound e criando conflito com a regra de saída explícita, que passou a ser ignorada.
C. O idleTimeoutInMinutes com valor 4 causa liberação prematura de portas, levando a descartes de conexões ativas.
D. As novas regras de balanceamento de carga criaram um conflito de frontend, fazendo com que o Load Balancer deixasse de encaminhar tráfego de saída pelo IP configurado na regra de saída explícita.
Cenário 2 — Decisão de Ação
A causa raiz foi identificada: um NAT Gateway foi associado à subnet principal do ambiente por engano durante uma reorganização de recursos. O ambiente possui um Load Balancer Standard público com regras de saída explícitas configuradas e um IP público dedicado. Desde a associação incorreta do NAT Gateway, todo o tráfego de saída das VMs passou a usar o IP do NAT Gateway em vez do IP configurado nas regras de saída do Load Balancer.
Restrições do momento:
- O ambiente está em produção ativa com SLA de 99,9%
- Parceiros externos têm regras de firewall baseadas no IP público do Load Balancer
- A remoção do NAT Gateway causa interrupção de conectividade de saída por alguns segundos durante a transição
- Existe uma janela de manutenção programada para daqui a 4 horas
- O time de segurança precisa ser notificado antes de qualquer alteração de topologia de rede em produção
Qual é a ação correta a tomar neste momento?
A. Remover imediatamente o NAT Gateway da subnet, pois a causa está identificada e cada minuto de tráfego saindo pelo IP errado representa risco de bloqueio pelos firewalls dos parceiros.
B. Documentar o problema, notificar o time de segurança e aguardar a janela de manutenção programada para executar a remoção do NAT Gateway com controle de impacto.
C. Criar um novo IP público e associá-lo ao NAT Gateway para que ele passe a usar o mesmo IP esperado pelos parceiros, eliminando o impacto sem necessidade de remoção imediata.
D. Adicionar uma rota UDR na subnet para forçar o tráfego de saída a ignorar o NAT Gateway e retornar ao Load Balancer sem necessidade de janela de manutenção.
Cenário 3 — Causa Raiz
Uma aplicação de processamento em lote executa milhares de requisições HTTP curtas para uma API externa ao longo de cada hora. O ambiente usa um Load Balancer Standard com uma regra de saída explícita configurada conforme abaixo:
{
"name": "outbound-batch",
"protocol": "Tcp",
"allocatedOutboundPorts": 2048,
"enableTcpReset": false,
"idleTimeoutInMinutes": 30,
"frontendIPConfigurations": [
{ "id": "/subscriptions/.../frontendIPConfigurations/pip-batch" }
],
"backendAddressPool": {
"id": "/subscriptions/.../backendAddressPools/pool-batch"
}
}
O backend pool tem 8 instâncias. As falhas começam a ocorrer aproximadamente 20 minutos após o início de cada ciclo de processamento. Os logs da aplicação mostram erros de connection timeout em novas conexões, enquanto conexões já estabelecidas continuam funcionando normalmente. O time de rede confirma que não houve alterações na configuração do Load Balancer nos últimos 30 dias. O NSG da subnet permite todo o tráfego de saída na porta 443.
Informações adicionais:
- Cada instância processa em média 400 requisições simultâneas no pico
- A API externa tem latência média de 800ms por requisição
- O certificado TLS do endpoint externo foi renovado recentemente
Qual é a causa raiz das falhas de conexão?
A. A renovação do certificado TLS do endpoint externo está causando falhas de handshake nas novas conexões TCP após o 20º minuto.
B. Com idleTimeoutInMinutes: 30 e enableTcpReset: false, portas SNAT de conexões anteriores permanecem reservadas por 30 minutos mesmo após o encerramento da conexão, levando ao esgotamento gradual do pool de 2048 portas por instância ao longo do ciclo.
C. O allocatedOutboundPorts: 2048 é insuficiente para 8 instâncias simultâneas, pois o limite total do Load Balancer é dividido igualmente e cada instância recebe menos do que o configurado.
D. O protocolo Tcp na regra de saída não cobre requisições HTTPS na porta 443, que requerem protocolo All para funcionar corretamente.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte alerta: VMs em subnet-app não conseguem alcançar endpoints externos na internet. O ambiente tem um Load Balancer Standard público com regra de saída configurada. Nenhuma alteração recente foi registrada no Change Management.
Os passos de investigação disponíveis são:
- Verificar se há um NAT Gateway associado à subnet e qual IP ele usa
- Confirmar se as VMs do backend pool conseguem resolver DNS para o endpoint externo
- Verificar se a regra de saída do Load Balancer está associada ao backend pool correto e se o frontend IP está ativo
- Checar se o NSG da subnet possui regras de negação de saída para a internet
- Validar se
disableOutboundSnatestá definido comotruenas regras de balanceamento de carga associadas ao mesmo backend pool
Qual é a sequência correta de investigação?
A. 2, 1, 4, 3, 5
B. 4, 3, 5, 1, 2
C. 3, 5, 4, 1, 2
D. 1, 4, 3, 5, 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na descrição: as novas regras de balanceamento de carga foram criadas com a propriedade disableOutboundSnat no valor padrão, que é false. Quando essa propriedade é false em regras de balanceamento de carga associadas ao mesmo backend pool que possui uma regra de saída explícita, o comportamento de SNAT automático via inbound coexiste de forma conflitante com a regra de saída. Em cenários onde a regra de saída explícita deveria ser a única responsável pelo tráfego de saída, o valor padrão false pode fazer com que o Load Balancer não aplique a regra de saída como esperado para o pool afetado, resultando em descartes silenciosos.
A informação sobre o NSG não alterado é irrelevante e foi incluída propositalmente para desviar o foco. O idleTimeoutInMinutes: 4 (alternativa C) não causa descartes de conexões ativas; ele controla apenas o tempo de reserva de portas ociosas. A alternativa A descreve esgotamento de SNAT, que seria gradual e progressivo, não uma interrupção abrupta coincidente com a manutenção. A alternativa D descreve um comportamento que não ocorre no Load Balancer Standard: regras de balanceamento de carga não interferem na seleção do frontend IP para saída.
O distrator mais perigoso é a alternativa A: um operador sob pressão poderia adicionar IPs de frontend desnecessariamente, sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
A causa está identificada e a solução é conhecida, mas o conjunto de restrições define o momento correto para agir. Há uma janela de manutenção a 4 horas, o time de segurança precisa ser notificado antes de alterações de topologia, e a interrupção causada pela remoção do NAT Gateway, embora breve, ocorre em produção ativa com SLA ativo.
A alternativa A representa a ação tecnicamente correta aplicada no momento errado: age sem notificar o time de segurança e sem usar a janela disponível, violando dois processos operacionais explícitos do cenário. A alternativa C é inviável porque um NAT Gateway usa IPs próprios e não pode ser reconfigurado para usar o IP público de um Load Balancer. A alternativa D é incorreta: UDRs não sobrepõem o comportamento de um NAT Gateway associado diretamente à subnet; o NAT Gateway tem precedência sobre rotas de saída e não pode ser contornado via UDR dentro da mesma subnet.
O distrator mais perigoso é a alternativa A, que representa a urgência mal calibrada: a causa foi identificada, a solução é simples, e agir imediatamente parece racional, mas ignora restrições de processo que existem para proteger o ambiente.
Gabarito — Cenário 3
Resposta: B
O cenário descreve um padrão claro: falhas em novas conexões após aproximadamente 20 minutos de operação, enquanto conexões existentes continuam funcionando. Esse comportamento é característico do esgotamento gradual de portas SNAT, não de uma falha de infraestrutura abrupta.
A combinação crítica é: enableTcpReset: false com idleTimeoutInMinutes: 30. Sem o TCP Reset habilitado, o Load Balancer não envia pacotes RST ao encerrar conexões ociosas. Isso significa que as portas SNAT de conexões encerradas continuam reservadas pelo período completo de 30 minutos. Com 8 instâncias, 2048 portas por instância, e 400 requisições simultâneas em média, o pool de portas se esgota progressivamente ao longo do ciclo, impedindo novas conexões a partir do 20º minuto aproximadamente.
A alternativa A é o distrator construído sobre a informação irrelevante: a renovação do certificado TLS foi incluída propositalmente, mas não tem relação causal com falhas que aparecem apenas após 20 minutos de operação normal. A alternativa C descreve incorretamente o comportamento de allocatedOutboundPorts: o valor configurado é alocado por instância, não dividido entre instâncias. A alternativa D é factualmente incorreta: o protocolo Tcp na regra de saída cobre conexões TCP em qualquer porta, incluindo a 443.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 4, 3, 5, 1, 2.
O raciocínio diagnóstico correto parte da camada mais próxima da VM em direção às camadas externas, eliminando causas simples antes de investigar configurações complexas.
O passo 4 (verificar NSG) vem primeiro porque uma regra de negação no NSG bloquearia o tráfego independentemente de qualquer configuração do Load Balancer ou NAT Gateway. É a causa mais simples e local de verificar. O passo 3 (verificar a regra de saída e o frontend) vem em seguida, confirmando se a configuração do Load Balancer está íntegra. O passo 5 (verificar disableOutboundSnat) complementa o passo 3, pois um conflito entre regras de inbound e outbound pode explicar descartes silenciosos mesmo com a regra de saída presente. O passo 1 (NAT Gateway) vem depois porque sua presença sobrepõe tudo anterior e muda completamente o diagnóstico. O passo 2 (DNS) vem por último porque uma falha de DNS produziria erros diferentes de timeout de conexão, sendo menos provável dado o sintoma descrito.
A sequência A começa pelo DNS, que é improvável como causa raiz de um timeout de conexão generalizado. A sequência C começa pela regra de saída antes de verificar o NSG, pulando a causa mais simples e local. A sequência D começa pelo NAT Gateway, que é uma hipótese válida mas menos provável na ausência de alterações recentes documentadas.
Árvore de Troubleshooting: Create and configure explicit outbound rules, including SNAT
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 que descreve o sintoma observado e responda cada pergunta diagnóstica com base no que é verificável diretamente no ambiente: estado do NSG, presença de NAT Gateway, existência e configuração da regra de saída, valor de disableOutboundSnat, composição do backend pool e comportamento temporal das falhas. Cada resposta elimina um ramo e conduz ao próximo nível, até que a causa seja identificada e a ação correspondente possa ser executada com base em evidências, não em suposição.