Laboratório de Troubleshooting: Implement Gateway Load Balancer
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que, após encadear um IP público de SKU Standard de uma VM de produção com um Gateway Load Balancer recém-criado, todo o tráfego de entrada parou de chegar à VM. Antes do encadeamento, a VM respondia normalmente. O Gateway Load Balancer tem um backend pool com duas NVAs e uma regra de balanceamento configurada.
O operador executa os seguintes testes:
# Teste de conectividade a partir de cliente externo
curl -v --connect-timeout 10 http://<ip-publico-da-vm>
# Resultado: Connection timed out
# Verificacao do estado das NVAs no backend pool do Gateway LB
az network lb show \
--name GatewayLB-Prod \
--resource-group rg-networking \
--query "backendAddressPools[].loadBalancerBackendAddresses[].name"
# Resultado: ["nva-1-nic", "nva-2-nic"]
# Verificacao do health probe
az network lb probe show \
--lb-name GatewayLB-Prod \
--resource-group rg-networking \
--name probe-nva
# Resultado: protocol: TCP, port: 80, intervalInSeconds: 15, numberOfProbes: 2
O time informa ainda que ambas as NVAs estão com o serviço de inspeção em execução na porta 443, e que o grupo de segurança de rede associado às NICs das NVAs permite todo o tráfego de entrada e saída.
Qual é a causa raiz da interrupção do tráfego?
A) O encadeamento com IP público direto de VM não é suportado pelo Gateway Load Balancer; o recurso consumidor precisa ser um Standard Load Balancer.
B) O health probe está configurado para verificar a porta TCP 80, enquanto as NVAs escutam apenas na porta 443, fazendo com que ambas sejam marcadas como unhealthy e nenhum tráfego seja entregue.
C) O grupo de segurança de rede das NVAs está bloqueando o tráfego encapsulado VXLAN-GPE, pois regras que permitem "todo o tráfego" não se aplicam a protocolos de tunelamento.
D) A regra de balanceamento do Gateway Load Balancer não está corretamente associada ao frontend IP, pois o portal do Azure exige uma etapa adicional de "Apply" após o encadeamento.
Cenário 2 — Decisão de Ação
A causa do problema a seguir já foi identificada pela equipe: o tunnel interface das NVAs no backend pool do Gateway Load Balancer está configurado com o tipo incorreto. A interface de entrada está definida como External tanto para o tráfego vindo do cliente quanto para o tráfego de retorno, quando o correto seria Internal para a interface de retorno.
O ambiente é de produção e está em horário de pico. A correção exige acesso administrativo às NVAs, que são appliances de terceiros gerenciados por um fornecedor externo. Um ticket de mudança foi aberto, mas a janela de manutenção aprovada é somente na próxima madrugada. O tráfego de produção está passando pelo Gateway Load Balancer com inspeção parcial, mas sem interrupção total do serviço.
A equipe considera as seguintes ações imediatas:
A) Remover imediatamente o encadeamento entre o IP público da VM e o Gateway Load Balancer para restaurar o fluxo direto de tráfego sem inspeção, aguardando a janela de manutenção para corrigir a configuração das NVAs.
B) Solicitar acesso emergencial ao fornecedor das NVAs e corrigir a configuração do tunnel interface agora, fora da janela de manutenção aprovada, para garantir inspeção correta imediatamente.
C) Manter o encadeamento ativo e aguardar a janela de manutenção aprovada, documentando o comportamento atual e monitorando o tráfego para detectar qualquer deterioração do serviço.
D) Criar um segundo Gateway Load Balancer com as configurações corretas e redirecionar o encadeamento para o novo recurso, eliminando o downtime da correção.
Cenário 3 — Causa Raiz
Um arquiteto analisa reclamações de usuários que acessam uma aplicação publicada atrás de um Standard Load Balancer público, encadeado a um Gateway Load Balancer com três NVAs no backend pool. Os usuários relatam que sessões longas de upload de arquivos grandes são interrompidas de forma intermitente, enquanto requisições curtas funcionam perfeitamente.
O arquiteto coleta os seguintes dados:
Regra de balanceamento do Gateway Load Balancer:
Protocol: All
Session persistence: None
Idle timeout: 4 minutos (valor padrao)
Configuracao das NVAs:
Tipo: Firewall stateful de terceiros
Estado de sincronizacao de sessao entre NVAs: Desabilitado
Uptime: 99,97% nos ultimos 30 dias
Health probes:
Todas as 3 NVAs: Healthy
Intervalo: 5 segundos
Threshold: 2 falhas consecutivas
O arquiteto nota ainda que os uploads interrompidos sempre ocorrem em arquivos acima de 500 MB e que a infraestrutura de rede subjacente passou por uma atualização de firmware nos switches há duas semanas, coincidindo com o início das reclamações.
Qual é a causa raiz das interrupções intermitentes?
A) A atualização de firmware dos switches introduziu fragmentação de pacotes para arquivos grandes, causando descarte antes mesmo de chegar ao Gateway Load Balancer.
B) O idle timeout de 4 minutos está encerrando conexões de upload longas antes de serem concluídas, pois uploads de arquivos grandes ultrapassam esse limite sem atividade suficiente.
C) A ausência de session persistence faz com que pacotes de uma mesma sessão de upload sejam distribuídos entre NVAs diferentes, e como a sincronização de estado entre elas está desabilitada, a sessão é descartada pela NVA que recebe pacotes sem contexto.
D) O health probe com intervalo de 5 segundos e threshold de 2 falhas está removendo e reinserindo NVAs do pool com frequência suficiente para interromper sessões longas durante o ciclo de verificação.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe um alerta: o tráfego de entrada para um serviço público encadeado com um Gateway Load Balancer está chegando à VM de destino sem passar pelas NVAs de inspeção. O encadeamento foi configurado há três dias e funcionou corretamente até esta manhã.
Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
- Verificar se o frontend IP do Gateway Load Balancer ainda está referenciado na configuração de frontend do recurso consumidor (IP público da VM ou Standard Load Balancer).
- Analisar logs de fluxo do Network Watcher para confirmar se o tráfego está bypassando as NVAs ou se as NVAs estão encaminhando sem inspecionar.
- Verificar o status de health dos membros do backend pool do Gateway Load Balancer.
- Confirmar se houve alguma alteração recente na configuração do recurso consumidor, como recriação do IP público ou troca de SKU.
- Testar conectividade direta às NVAs para verificar se estão ativas e respondendo ao health probe.
Qual sequência representa o raciocínio diagnóstico mais eficiente, do mais abrangente para o mais específico?
A) 2 → 4 → 1 → 3 → 5
B) 1 → 4 → 3 → 5 → 2
C) 3 → 5 → 1 → 4 → 2
D) 4 → 1 → 2 → 5 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O health probe configurado na porta TCP 80 tenta estabelecer conexão com as NVAs nessa porta a cada 15 segundos. Como as NVAs escutam apenas na porta 443, as conexões são recusadas ou expiram. Após 2 tentativas falhas consecutivas (conforme o threshold configurado), ambas as NVAs são marcadas como unhealthy e removidas do pool de backend ativo. Com o pool vazio, o Gateway Load Balancer não tem para onde encaminhar o tráfego, resultando em timeout total para o cliente.
A pista direta no enunciado é a combinação entre port: 80 no probe e o fato de as NVAs escutarem na porta 443. Essa discrepância é suficiente para explicar o sintoma completamente.
A informação sobre o NSG permitindo "todo o tráfego" é propositalmente irrelevante: mesmo que o NSG bloqueasse o encapsulamento VXLAN, o sintoma seria diferente e não dependeria de qual porta o probe usa. A alternativa A é falsa: encadeamento com IP público de VM é explicitamente suportado. A alternativa D descreve um fluxo de portal que não existe. O distrator mais perigoso é a alternativa C, que invoca o mecanismo de VXLAN de forma plausível, mas o NSG já foi descrito como permissivo, eliminando essa hipótese com os dados disponíveis.
Gabarito — Cenário 2
Resposta: C
O cenário informa explicitamente que o serviço não está totalmente interrompido: o tráfego flui com inspeção parcial. Não há risco imediato que justifique ações fora do processo de mudança aprovado. A ação correta é manter o estado atual, monitorar ativamente e aguardar a janela de manutenção, que ocorre na madrugada seguinte.
A alternativa A seria correta se houvesse risco de interrupção total ou de exposição de segurança crítica, mas o enunciado não descreve esse nível de impacto. Remover o encadeamento eliminaria completamente a inspeção, o que pode ser pior do que a inspeção parcial atual dependendo da política de segurança. A alternativa B ignora a restrição explícita de que as NVAs são gerenciadas por fornecedor externo e que há uma janela de manutenção já aprovada. Atuar fora dessa janela sem autorização pode violar contratos e processos de governança. A alternativa D é tecnicamente criativa, mas criaria um novo recurso em produção sem planejamento, introduzindo risco desnecessário em horário de pico, e não resolve o problema original nas NVAs existentes.
Gabarito — Cenário 3
Resposta: C
A chave do diagnóstico está na combinação de dois fatos declarados: session persistence desabilitada e sincronização de estado entre NVAs desabilitada. Sem persistência de sessão, o Gateway Load Balancer distribui os pacotes de uma mesma conexão TCP entre NVAs diferentes usando o hash de 5 tuplas, que pode variar para fluxos de longa duração ou com múltiplos pacotes. Quando um pacote chega a uma NVA que não possui o estado inicial da sessão, o firewall stateful descarta o pacote por não reconhecer a conexão, quebrando o upload.
O fato de que apenas arquivos grandes são afetados confirma essa hipótese: sessões curtas completam antes que o balanceamento redistribua pacotes para uma NVA diferente, enquanto sessões longas têm maior probabilidade de sofrer redistribuição ao longo do tempo.
A informação sobre a atualização de firmware dos switches é a isca irrelevante do cenário. Embora a coincidência temporal seja provocativa, o enunciado não fornece nenhuma evidência de fragmentação ou descarte em nível de switch, e a causa explicada pela alternativa C justifica completamente o sintoma sem precisar desse elemento. O distrator mais perigoso é a alternativa B: o idle timeout de 4 minutos é plausível, mas uploads ativos de arquivos grandes geram tráfego contínuo, o que impede o timer de ociosidade de expirar durante a transferência ativa.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 1 → 4 → 3 → 5 → 2, que segue o raciocínio diagnóstico do mais abrangente e menos custoso para o mais específico e confirmatório.
O passo 1 verifica primeiro se o encadeamento ainda existe: se o frontend IP do Gateway Load Balancer não está mais referenciado no recurso consumidor, o bypass é explicado imediatamente sem precisar investigar mais. O passo 4 investiga se houve uma mudança recente (recriação de IP público ou troca de SKU) que poderia ter desfeito o encadeamento silenciosamente. O passo 3 verifica se o backend pool tem membros saudáveis. O passo 5 testa as NVAs diretamente para confirmar responsividade ao probe. O passo 2 é o mais custoso e granular (análise de logs de fluxo) e só faz sentido após eliminar as causas estruturais anteriores.
A sequência A começa pela análise de logs, que é o instrumento mais detalhado mas também o mais demorado e que pressupõe que o problema está no fluxo de dados, não na configuração do encadeamento. A sequência C começa pelo estado do health probe, que é relevante mas não explica um bypass completo se o encadeamento estiver intacto. A sequência D começa investigando mudanças recentes antes de confirmar se o encadeamento ainda existe, saltando uma etapa mais rápida de verificar o estado atual.
Árvore de Troubleshooting: Implement Gateway Load Balancer
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Verde | Ação recomendada ou resolução |
| Vermelho | Causa identificada |
| 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 com base no que você consegue verificar diretamente no ambiente. Siga o caminho correspondente à sua resposta até alcançar um nó vermelho (causa identificada) ou verde (ação recomendada). Nós laranja indicam pontos onde é necessário coletar mais dados antes de prosseguir. Não pule etapas: o valor diagnóstico está na eliminação progressiva de hipóteses, não na intuição sobre qual causa parece mais provável.