Laboratório Técnico: Configure routing rules
Questões
Questão 1 — Múltipla Escolha
Uma equipe de redes precisa garantir que o tráfego originado de uma sub-rede específica em uma VNet sempre seja inspecionado por um Network Virtual Appliance (NVA) antes de alcançar a Internet, mesmo que existam rotas padrão aprendidas via BGP de um gateway VPN.
Qual mecanismo garante que a rota pelo NVA seja efetivamente utilizada?
A) Configurar uma rota estática na tabela de rotas do gateway VPN com next hop do tipo VirtualNetworkGateway
B) Associar uma User-Defined Route (UDR) à sub-rede com uma rota para 0.0.0.0/0 e next hop do tipo VirtualAppliance, apontando para o IP privado do NVA
C) Habilitar BGP route propagation na tabela de rotas da sub-rede para que o NVA anuncie sua própria rota padrão
D) Criar uma rota do sistema do tipo VirtualNetworkGateway e associá-la diretamente à sub-rede de origem
Questão 2 — Cenário Técnico
Um engenheiro configura o seguinte trecho em uma Route Table associada a uma sub-rede de workloads:
Prefixo de destino : 10.2.0.0/16
Next hop type : VirtualAppliance
Next hop address : 10.1.0.4
Durante os testes, o tráfego destinado a 10.2.1.50 chega corretamente ao NVA, mas o tráfego destinado a 10.2.0.10 não chega à máquina de destino após passar pelo NVA. O NVA está funcional e recebendo os pacotes.
Qual é a causa mais provável do problema?
A) A rota UDR cobre apenas o prefixo /24 e ignora endereços no intervalo /16
B) O NVA não tem IP forwarding habilitado na interface de rede no Azure
C) A sub-rede de destino 10.2.0.0/24 possui uma UDR sobreposta que redireciona o tráfego de volta ao NVA, causando loop
D) O Azure bloqueia automaticamente tráfego de retorno em rotas do tipo VirtualAppliance por padrão
Questão 3 — Verdadeiro ou Falso
Uma User-Defined Route com next hop do tipo None associada a uma sub-rede descarta silenciosamente o tráfego correspondente ao prefixo configurado, sem gerar qualquer resposta ICMP de destino inacessível para a origem.
Questão 4 — Múltipla Escolha
Uma empresa possui duas VNets conectadas via VNet Peering. A VNet A contém um NVA que deve inspecionar todo o tráfego entre a VNet B e redes on-premises conectadas via gateway VPN na VNet A. O peering já está configurado com Allow Gateway Transit na VNet A e Use Remote Gateways na VNet B.
O que ainda é necessário para que o tráfego da VNet B passe obrigatoriamente pelo NVA antes de atingir o on-premises?
A) Habilitar BGP route propagation na tabela de rotas da VNet B para aceitar as rotas anunciadas pelo gateway VPN
B) Criar uma UDR na sub-rede da VNet B com rota para os prefixos on-premises com next hop VirtualAppliance apontando para o IP do NVA na VNet A
C) Configurar uma rota estática no gateway VPN da VNet A redirecionando o tráfego de retorno para o NVA
D) Associar a Route Table do NVA diretamente ao gateway subnet da VNet A
Questão 5 — Cenário Técnico
Uma equipe associou uma Route Table a uma sub-rede e desabilitou a propagação de rotas de gateway (BGP route propagation = Disabled). Após isso, máquinas nessa sub-rede perderam conectividade com redes on-premises, mas continuam alcançando recursos dentro da própria VNet.
O engenheiro responsável afirma que o problema pode ser resolvido adicionando manualmente uma UDR com next hop VirtualNetworkGateway para os prefixos on-premises.
A afirmação do engenheiro está correta?
A) Não, pois UDRs não suportam o tipo de next hop VirtualNetworkGateway em nenhum cenário
B) Sim, pois uma UDR com next hop VirtualNetworkGateway instrui o Azure a encaminhar o tráfego para o gateway VPN ou ExpressRoute da VNet, restaurando a conectividade
C) Não, pois desabilitar a propagação de rotas de gateway apaga permanentemente as entradas na tabela de rotas efetivas e elas não podem ser reinscritas via UDR
D) Sim, mas somente se o gateway for do tipo ExpressRoute; gateways VPN não aceitam esse tipo de next hop em UDRs
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Uma UDR com next hop VirtualAppliance tem precedência sobre rotas aprendidas via BGP do gateway VPN porque UDRs são avaliadas antes das rotas propagadas por gateway na ordem de preferência do Azure. O Azure resolve conflitos de roteamento pela especificidade do prefixo primeiro e, quando os prefixos são idênticos, pela origem da rota: UDRs sobrepõem rotas de gateway propagadas.
O principal equívoco representado pelos distratores é confundir a hierarquia de precedência. Habilitar propagação BGP (opção C) faria o oposto: tornaria as rotas do gateway visíveis, não as suprimiria. A opção A configura uma rota no lado errado (no gateway, não na sub-rede de origem). A opção D descreve uma rota do sistema, que não pode ser criada manualmente e tem precedência inferior à UDR.
Escolher a alternativa errada resultaria em o tráfego contornar o NVA, eliminando a inspeção e criando uma lacuna de segurança invisível para a equipe.
Gabarito — Questão 2
Resposta: B
Quando um NVA recebe pacotes e não os encaminha, o problema mais comum no Azure é a ausência do IP forwarding habilitado na interface de rede (NIC) do recurso. O Azure, por padrão, descarta pacotes cujo destino não seja o IP da própria NIC. Habilitar IP forwarding na NIC no portal/ARM instrui o Azure a permitir que o NVA funcione como roteador.
A opção A é tecnicamente incorreta: a UDR cobre /16, que inclui qualquer endereço 10.2.x.x. A opção C descreveria um problema de loop, mas o enunciado indica que os pacotes chegam ao NVA e param ali, não que retornam em loop. A opção D não existe como comportamento real do Azure.
Sem IP forwarding habilitado, o NVA registra o tráfego chegando, mas o plano de dados do Azure descarta os pacotes antes de qualquer processamento do sistema operacional do NVA.
Gabarito — Questão 3
Verdadeiro
O next hop do tipo None implementa um "buraco negro" de roteamento. O Azure descarta os pacotes correspondentes silenciosamente, sem enviar ICMPv4 Type 3 (Destination Unreachable) de volta à origem. Esse comportamento é intencional e diferente do que a maioria dos roteadores tradicionais faz.
Isso tem implicações práticas importantes: aplicações que dependem de mensagens ICMP de erro para detectar destinos inacessíveis podem ficar aguardando timeout completo da conexão TCP antes de perceber a falha, aumentando latência percebida e dificultando diagnósticos com ferramentas como traceroute.
Gabarito — Questão 4
Resposta: B
Mesmo com peering configurado com Allow Gateway Transit e Use Remote Gateways, o Azure aprende as rotas on-premises na VNet B via propagação de gateway, mas não redireciona automaticamente esse tráfego por um NVA que reside em outra VNet. Para forçar a passagem pelo NVA, é obrigatório criar uma UDR na sub-rede da VNet B com os prefixos on-premises e next hop VirtualAppliance apontando para o IP privado do NVA na VNet A.
O principal equívoco dos distratores é assumir que o peering com transit já garante a inspeção. Ele garante apenas a conectividade via gateway. A opção A, habilitar propagação BGP, faria as rotas on-premises aparecerem na tabela efetiva da VNet B, mas sem forçar o caminho pelo NVA. A opção D é inválida: associar Route Tables ao gateway subnet da VNet A pode quebrar a funcionalidade do gateway e não afeta o roteamento originado na VNet B.
Gabarito — Questão 5
Resposta: B
O next hop do tipo VirtualNetworkGateway é um valor válido e suportado em UDRs. Quando a propagação de rotas de gateway está desabilitada, as rotas aprendidas via BGP (do gateway VPN ou ExpressRoute) deixam de aparecer automaticamente na tabela efetiva da sub-rede. A solução correta é inserir manualmente UDRs com next hop VirtualNetworkGateway para os prefixos on-premises, restaurando o caminho sem reativar a propagação automática.
A opção A é factualmente incorreta: VirtualNetworkGateway é um tipo de next hop documentado e amplamente utilizado em cenários de hub-and-spoke onde se deseja controle granular. A opção C confunde "desabilitar propagação" com destruição permanente de estado. A opção D é um distrator clássico: VirtualNetworkGateway funciona para ambos os tipos de gateway, VPN e ExpressRoute.
Entender que desabilitar a propagação não remove a capacidade de usar o gateway, apenas a automação das rotas, é fundamental para cenários de hub-and-spoke com inspeção de tráfego.