Pular para o conteúdo principal

Laboratório Técnico: Configure Forced Tunneling

Questões​

Questão 1 — Múltipla Escolha​

Uma empresa exige que todo o tráfego de saída das VMs em uma VNet seja inspecionado por um firewall corporativo on-premises antes de atingir a internet. O engenheiro de rede configura o forced tunneling via uma rota personalizada com prefixo 0.0.0.0/0 apontando para o gateway VPN.

Qual é o tipo de next hop correto a ser definido nessa User Defined Route (UDR) para direcionar o tráfego ao gateway VPN?

A) Internet B) VirtualNetworkGateway C) VirtualAppliance D) VnetLocal

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

Um administrador configura forced tunneling em uma VNet com duas subnets: AppSubnet e GatewaySubnet. Ele associa uma route table com a rota 0.0.0.0/0 → VirtualNetworkGateway diretamente à GatewaySubnet.

Após a configuração, o túnel VPN para on-premises para de funcionar e a conectividade com a VNet é perdida.

Qual é a causa mais provável desse comportamento?

A) O prefixo 0.0.0.0/0 não é suportado em UDRs associadas a qualquer subnet. B) O gateway VPN não suporta roteamento de tráfego com forced tunneling ativo. C) Route tables com rotas personalizadas não devem ser associadas à GatewaySubnet, pois isso pode quebrar o comportamento do gateway. D) A rota deveria usar o next hop Internet em vez de VirtualNetworkGateway para tráfego de retorno.

Questão 3 — Múltipla Escolha​

Uma organização usa Azure Virtual WAN com branches conectados via Site-to-Site VPN. O time de segurança solicita que todo o tráfego de internet das branches seja roteado pelo hub central antes de sair para a internet, usando forced tunneling.

Qual configuração viabiliza esse comportamento no contexto do Virtual WAN?

A) Criar UDRs com 0.0.0.0/0 em cada spoke VNet e associar à subnet padrão. B) Habilitar a opção Enable internet security na conexão VPN do branch e configurar uma rota estática 0.0.0.0/0 no hub apontando para um NVA ou Azure Firewall. C) Configurar BGP para anunciar o prefixo 0.0.0.0/0 a partir do hub para os branches via route policy. D) Associar uma route table ao Virtual WAN hub com next hop VirtualNetworkGateway.

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

Um engenheiro precisa implementar forced tunneling em uma VNet que ainda não possui gateway VPN provisionado. Ele executa os seguintes passos:

# Passo 1: Cria a subnet de gateway
az network vnet subnet create \
  --name GatewaySubnet \
  --vnet-name MyVNet \
  --resource-group MyRG \
  --address-prefix 10.0.255.0/27

# Passo 2: Cria a route table e associa à AppSubnet
az network route-table create --name ForcedTunnelRT --resource-group MyRG
az network route-table route create \
  --route-table-name ForcedTunnelRT \
  --name DefaultRoute \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualNetworkGateway \
  --resource-group MyRG

# Passo 3: Associa a route table à AppSubnet (não à GatewaySubnet)
az network vnet subnet update \
  --name AppSubnet \
  --vnet-name MyVNet \
  --resource-group MyRG \
  --route-table ForcedTunnelRT

Após a execução, nenhum tráfego é redirecionado ao on-premises. Qual é a causa raiz?

A) O prefixo 0.0.0.0/0 em UDRs só funciona quando o next hop é VirtualAppliance. B) A route table foi associada à AppSubnet em vez da GatewaySubnet, local obrigatório para forced tunneling. C) O gateway VPN ainda não foi provisionado, portanto o next hop VirtualNetworkGateway não tem destino resolvível para encaminhar o tráfego. D) O tamanho /27 da GatewaySubnet é insuficiente e impede o provisionamento do gateway, bloqueando o roteamento.

Questão 5 — Verdadeiro ou Falso​

Ao habilitar o forced tunneling em uma VNet, todo o tráfego das subnets configuradas, incluindo o tráfego destinado a serviços PaaS do Azure acessados por seus endereços IP públicos, será redirecionado pelo túnel VPN para on-premises, a menos que Private Endpoints ou Service Endpoints estejam configurados para esses serviços.

Esta afirmação é verdadeira ou falsa?

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O next hop VirtualNetworkGateway é o tipo correto em uma UDR quando se deseja redirecionar tráfego pelo gateway VPN da VNet. Esse next hop instrui o Azure a encaminhar os pacotes correspondentes ao gateway provisionado na GatewaySubnet.

O distrator VirtualAppliance seria usado se o destino do forced tunneling fosse um NVA (Network Virtual Appliance), como um firewall de terceiros ou o próprio Azure Firewall, e exigiria a especificação do IP privado do appliance. O distrator Internet instrui o Azure a rotear diretamente para a internet, anulando qualquer intenção de forced tunneling. VnetLocal representa o roteamento interno à VNet, sem saída para gateway ou internet.

Gabarito — Questão 2​

Resposta: C

A GatewaySubnet é uma subnet gerenciada internamente pelo Azure e possui restrições explícitas de configuração. Associar uma route table personalizada a ela, especialmente com rotas que alteram o comportamento do next hop padrão, pode interferir no plano de controle do gateway VPN, causando falhas na manutenção do túnel e perda de conectividade.

A documentação da Microsoft é clara ao afirmar que não se deve associar route tables à GatewaySubnet. Essa é uma das armadilhas mais comuns em cenários de forced tunneling, pois o erro é cometido na subnet errada. As UDRs de forced tunneling devem ser aplicadas às subnets de workload, como AppSubnet, WebSubnet, etc.

Gabarito — Questão 3​

Resposta: B

No contexto do Azure Virtual WAN, o mecanismo de forced tunneling para branches difere do modelo clássico de VNet com UDRs. A opção Enable internet security na conexão VPN do branch é o controle que instrui o hub a inspecionar e redirecionar o tráfego de internet do branch. Combinada com uma rota 0.0.0.0/0 no hub apontando para um Azure Firewall ou NVA, essa configuração implementa o comportamento equivalente ao forced tunneling.

Associar UDRs diretamente ao hub do Virtual WAN não é o mecanismo correto; hubs do Virtual WAN usam route tables de hub com um modelo diferente das VNets clássicas. A propagação BGP de 0.0.0.0/0 pode ser parte de soluções avançadas, mas não é o mecanismo primário e gerenciado para esse cenário no Virtual WAN.

Gabarito — Questão 4​

Resposta: C

O next hop do tipo VirtualNetworkGateway em uma UDR requer que um gateway VPN esteja provisionado e em estado operacional na VNet. Sem o gateway, o Azure não tem para onde encaminhar o tráfego que corresponde àquela rota, e o redirecionamento simplesmente não ocorre. A configuração da route table está correta em termos de estrutura e associação (aplicada à AppSubnet, não à GatewaySubnet).

O distrator sobre /27 é plausível porque esse tamanho é o mínimo recomendado para gateways com recursos avançados como VPN Gateway de alta disponibilidade, mas um /27 é válido e não impede o provisionamento. O distrator sobre VirtualAppliance representa uma confusão entre os dois modelos de forced tunneling (via gateway VPN versus via NVA).

Gabarito — Questão 5​

Resposta: Verdadeiro

Quando o forced tunneling é implementado com uma rota 0.0.0.0/0 → VirtualNetworkGateway, todo o tráfego de saída das subnets configuradas é afetado, incluindo requisições a endpoints públicos de serviços PaaS do Azure como Storage Accounts, SQL Database e Key Vault acessados por seus IPs públicos. Esse tráfego será encaminhado ao on-premises, o que pode causar latência elevada, consumo de banda no link VPN e até bloqueio se o firewall on-premises não permitir o tráfego de retorno.

A afirmação é não óbvia justamente porque muitos assumem que "tráfego Azure para Azure" ficaria fora do túnel. Os mecanismos que evitam esse comportamento são Service Endpoints (que mantêm o tráfego dentro da rede do Azure, sem passar pelo gateway) e Private Endpoints (que substituem o IP público do serviço por um IP privado na VNet, tornando a rota 0.0.0.0/0 irrelevante para aquele serviço).