Pular para o conteúdo principal

Laboratório Técnico: Implement Gateway Load Balancer

Questões​

Questão 1 — Múltipla Escolha​

Ao configurar um Gateway Load Balancer, é necessário encadear ("chain") esse recurso com um balanceador de carga público padrão existente. Qual é o mecanismo correto para estabelecer esse encadeamento?

A) Criar uma regra de NAT de entrada no Standard Load Balancer apontando para o frontend IP do Gateway Load Balancer.

B) Associar o provider configuration do Gateway Load Balancer diretamente ao backend pool do Standard Load Balancer.

C) Referenciar o frontend IP do Gateway Load Balancer na configuração de frontend do Standard Load Balancer por meio do campo Gateway Load Balancer.

D) Inserir o endereço IP do Gateway Load Balancer como um servidor de backend no pool do Standard Load Balancer.

Questão 2 — Cenário Técnico​

Uma equipe de segurança implantou um conjunto de Network Virtual Appliances (NVAs) para inspeção de tráfego e deseja utilizá-los com um Gateway Load Balancer. Durante os testes, percebem que o tráfego inspecionado retorna para o cliente com endereço IP de origem diferente do esperado, quebrando sessões de aplicações stateful. Analise a configuração abaixo:

Gateway Load Balancer Backend Pool:
  - NVA-1: túnel externo porta 10800, túnel interno porta 10801
  - NVA-2: túnel externo porta 10800, túnel interno porta 10801

Regra de balanceamento:
  - Protocolo: All
  - Frontend IP: GatewayLB-Frontend
  - Backend Pool: NVA-Pool
  - Session persistence: None

Qual é a causa mais provável do comportamento inesperado?

A) A session persistence está desativada, fazendo com que pacotes da mesma sessão sejam enviados para NVAs diferentes, que não compartilham estado.

B) As portas de túnel interno e externo são idênticas entre as NVAs, causando conflito no roteamento do tráfego de retorno.

C) O protocolo All não é suportado em regras de Gateway Load Balancer e está silenciosamente ignorando o encapsulamento VXLAN.

D) As NVAs precisam de um endereço IP público próprio para que o Gateway Load Balancer consiga encaminhar o tráfego de retorno corretamente.

Questão 3 — Verdadeiro ou Falso​

Um Gateway Load Balancer pode ser encadeado simultaneamente com múltiplos recursos de frontend de diferentes Standard Load Balancers públicos ou endereços IP públicos de VMs, permitindo que um único conjunto de NVAs inspecione o tráfego de várias origens distintas sem configurações adicionais por origem.

Questão 4 — Cenário Técnico​

Um arquiteto precisa garantir que todo o tráfego de entrada destinado a uma VM com IP público no Azure passe por um appliance de inspeção antes de chegar à VM, sem alterar a configuração de rede da VM nem instalar agentes nela. Ele propõe a arquitetura abaixo:

Internet
    |
    v
IP Público da VM (Standard SKU)
    |
    v
[Encadeamento com Gateway Load Balancer]
    |
    v
NVA (inspeção)
    |
    v
VM de destino (sem alteração de configuração)

Qual afirmação descreve corretamente o comportamento dessa arquitetura?

A) A arquitetura é válida, mas exige que o IP público da VM seja substituído por um frontend IP de um Standard Load Balancer, pois o encadeamento com IP público direto de VM não é suportado.

B) A arquitetura é válida e suportada: IPs públicos de SKU Standard associados a VMs podem ser encadeados com um Gateway Load Balancer da mesma forma que frontends de Standard Load Balancers.

C) A arquitetura é inválida porque o Gateway Load Balancer opera exclusivamente na camada 7 e não consegue inspecionar tráfego de camada 4 destinado diretamente a uma VM.

D) A arquitetura é válida, mas a VM de destino precisa ter o IP público removido e substituído por um IP privado, pois o Gateway Load Balancer não coexiste com IPs públicos no mesmo adaptador de rede.

Questão 5 — Múltipla Escolha​

O Gateway Load Balancer utiliza um mecanismo de encapsulamento para transportar o tráfego entre o balanceador e as NVAs do pool de backend. Qual é a consequência direta desse encapsulamento para as NVAs que integram o backend pool?

A) As NVAs recebem o tráfego já desencapsulado e com o IP de destino original preservado, sem necessidade de qualquer configuração adicional de interface.

B) As NVAs devem ser configuradas para terminar e reencapsular o tráfego usando o protocolo VXLAN-GPE, pois o Gateway Load Balancer não realiza o desencapsulamento automaticamente antes da entrega ao backend.

C) As NVAs recebem o tráfego encapsulado e precisam processar apenas o cabeçalho externo, descartando o payload original após a inspeção.

D) As NVAs devem expor uma interface de rede dedicada exclusivamente ao Gateway Load Balancer, separada da interface usada para comunicação com outras redes.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: C

O encadeamento entre um recurso consumidor (Standard Load Balancer público ou IP público de VM) e o Gateway Load Balancer é feito referenciando o frontend IP configuration do Gateway Load Balancer no campo correspondente da configuração de frontend do recurso consumidor. Esse vínculo instrui o Azure a redirecionar o tráfego pelo Gateway Load Balancer antes de entregá-lo ao destino final.

As alternativas A e D representam o equívoco de tratar o Gateway Load Balancer como um destino de backend convencional, o que não é sua função. A alternativa B confunde a terminologia: o "provider configuration" está relacionado à configuração do backend pool do próprio Gateway Load Balancer, não ao mecanismo de encadeamento com recursos consumidores.

Gabarito — Questão 2​

Resposta: A

O Gateway Load Balancer distribui o tráfego entre as NVAs do pool de backend usando um algoritmo de hash de 5 tuplas por padrão. Com session persistence desativada, pacotes pertencentes à mesma sessão TCP podem ser encaminhados para NVAs diferentes. Como appliances de inspeção stateful mantêm tabelas de estado locais, uma NVA que recebe apenas parte de uma sessão não possui o contexto completo, resultando em respostas incorretas ou descarte de pacotes.

A alternativa B é um distrator plausível, mas portas idênticas entre NVAs distintas é o comportamento esperado e correto no modelo de túnel do Gateway Load Balancer: cada NVA tem sua própria identidade de túnel definida pelo par (IP, porta). A alternativa C é falsa: o protocolo All é explicitamente suportado. A alternativa D inverte a lógica: as NVAs no backend pool do Gateway Load Balancer devem ter IPs privados, não públicos.

Gabarito — Questão 3​

Verdadeiro

Um único Gateway Load Balancer pode ser encadeado com múltiplos recursos consumidores independentes, sejam frontends de diferentes Standard Load Balancers públicos ou IPs públicos de VMs distintas. Cada recurso consumidor configura individualmente o encadeamento apontando para o mesmo frontend IP do Gateway Load Balancer. Isso permite centralizar a inspeção de tráfego de múltiplas origens em um único conjunto de NVAs, sem necessidade de configurações adicionais no Gateway Load Balancer por origem encadeada.

Esse comportamento é fundamental para o modelo de segurança centralizada em arquiteturas hub-and-spoke ou em cenários onde vários serviços públicos compartilham o mesmo appliance de segurança.

Gabarito — Questão 4​

Resposta: B

O Gateway Load Balancer suporta encadeamento não apenas com frontends de Standard Load Balancers, mas também diretamente com IPs públicos de SKU Standard associados a interfaces de rede de VMs. Isso é exatamente o caso de uso descrito: transparência total para a VM de destino, sem alteração de sua configuração, e inspeção intermediária pelas NVAs.

A alternativa A representa um equívoco comum: presumir que apenas Standard Load Balancers podem ser consumidores. A alternativa C é incorreta porque o Gateway Load Balancer opera na camada 3/4 (não na camada 7) e utiliza VXLAN-GPE para encaminhar pacotes sem inspecioná-los ele próprio. A alternativa D contradiz o funcionamento do produto: a VM mantém seu IP público; o encadeamento é configurado nesse mesmo IP público, não o substitui.

Gabarito — Questão 5​

Resposta: B

O Gateway Load Balancer encapsula o tráfego usando VXLAN com Generic Protocol Extension (VXLAN-GPE) ao enviá-lo para as NVAs do backend pool. As NVAs são responsáveis por terminar esse encapsulamento, inspecionar ou processar o payload original, e reencapsular o tráfego antes de devolvê-lo ao Gateway Load Balancer. Esse modelo preserva o endereço IP original do cliente e do destino, tornando a inspeção transparente para ambos os lados da comunicação.

A alternativa A é o equívoco mais perigoso: assumir que as NVAs recebem tráfego já desencapsulado levaria a uma configuração incorreta que simplesmente descartaria os pacotes encapsulados. A alternativa C distorce o modelo: as NVAs processam o payload completo, não apenas o cabeçalho externo. A alternativa D confunde o Gateway Load Balancer com soluções que exigem interfaces dedicadas por tipo de tráfego, o que não é um requisito desse serviço.