Laboratório Técnico: Configure user-defined routes
Questões
Questão 1 — Múltipla Escolha
Uma equipe de segurança exige que todo o tráfego de saída de uma sub-rede de aplicação para a internet passe obrigatoriamente por um Network Virtual Appliance (NVA) implantado em uma sub-rede dedicada. O NVA já está configurado e com IP forwarding habilitado na interface de rede.
Qual é o recurso do Azure que deve ser criado e associado para garantir que o tráfego seja redirecionado conforme exigido?
A) Um Network Security Group (NSG) com uma regra de saída apontando para o IP do NVA como destino
B) Uma route table com uma rota definida pelo usuário (UDR) do tipo VirtualAppliance, associada à sub-rede de aplicação
C) Uma route table com uma rota definida pelo usuário (UDR) do tipo VirtualAppliance, associada à sub-rede do NVA
D) Um Azure Firewall configurado como gateway padrão na sub-rede de aplicação, substituindo qualquer rota existente
Questão 2 — Cenário Técnico
Um administrador criou a seguinte rota em uma route table associada à sub-rede app-subnet:
Prefixo de destino : 0.0.0.0/0
Tipo do próximo salto : VirtualAppliance
Endereço do próximo salto: 10.1.1.4
Após associar a route table, as VMs na app-subnet perdem completamente a conectividade, inclusive com outras sub-redes dentro da mesma VNet. O NVA no IP 10.1.1.4 está em execução e com IP forwarding habilitado na NIC.
Qual é a causa mais provável do problema?
A) O tipo VirtualAppliance não é compatível com rotas de prefixo 0.0.0.0/0; o tipo correto seria Internet
B) A route table foi associada à sub-rede errada; ela deveria ser associada à sub-rede do NVA
C) O NVA está na mesma VNet que as VMs, o que impede o roteamento entre sub-redes via UDR
D) O NVA não está processando ou encaminhando o tráfego recebido, atuando como um buraco negro para todos os pacotes
Questão 3 — Verdadeiro ou Falso
Uma user-defined route (UDR) com prefixo 10.0.0.0/16 e tipo de próximo salto None configurada em uma route table associada a uma sub-rede descarta silenciosamente todo o tráfego destinado a esse prefixo, impedindo a comunicação mesmo que existam rotas de sistema mais específicas para sub-redes dentro desse intervalo.
Questão 4 — Múltipla Escolha
Uma organização possui duas VNets conectadas via VNet Peering: vnet-hub (10.0.0.0/16) e vnet-spoke (10.1.0.0/16). Na vnet-spoke, há uma route table associada à spoke-subnet com a seguinte UDR:
Prefixo de destino : 10.0.0.0/16
Tipo do próximo salto : VirtualAppliance
Endereço do próximo salto: 10.0.1.4
O peering está configurado com Allow forwarded traffic habilitado em ambos os lados. Mesmo assim, o tráfego da spoke-subnet para a vnet-hub não chega ao destino e é descartado.
Qual é a causa mais provável?
A) O VNet Peering não suporta UDRs que redirecionam tráfego entre VNets pareadas
B) A opção Use remote gateways não está habilitada na vnet-spoke, impedindo o roteamento via NVA
C) O NVA em 10.0.1.4 está na vnet-hub, mas a sub-rede onde ele reside não tem uma route table que permita o retorno do tráfego para a vnet-spoke
D) A UDR na spoke-subnet sobrescreve a rota de peering, mas o NVA não está encaminhando o tráfego para a vnet-hub
Questão 5 — Cenário Técnico
Um administrador precisa garantir que VMs em uma sub-rede específica nunca roteem tráfego para a internet diretamente, nem via gateway padrão do Azure. A exigência é que qualquer tentativa de acesso externo seja simplesmente descartada sem redirecionamento.
O administrador cria a seguinte UDR e associa à sub-rede:
Prefixo de destino : 0.0.0.0/0
Tipo do próximo salto : ?
Qual tipo de próximo salto atende exatamente a esse requisito?
A) Internet
B) VirtualNetworkGateway
C) None
D) VirtualAppliance com endereço 0.0.0.0
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Uma route table com uma UDR do tipo VirtualAppliance deve ser associada à sub-rede de origem do tráfego, ou seja, a sub-rede de aplicação. É ali que o Azure consulta a tabela de rotas para decidir o próximo salto de pacotes originados naquela sub-rede.
O principal erro conceitual dos distratores é confundir o ponto de associação da route table. A alternativa C associa a tabela à sub-rede do NVA, o que controlaria o tráfego saindo do NVA, não o tráfego chegando a ele. A alternativa A confunde NSG com roteamento: NSGs filtram tráfego por permissão ou negação, mas não redirecionam pacotes para um próximo salto. A alternativa D introduz um serviço diferente sem relação direta com a configuração de UDR.
Gabarito — Questão 2
Resposta: D
A rota está tecnicamente correta em estrutura: o prefixo 0.0.0.0/0, o tipo VirtualAppliance e o endereço do próximo salto são válidos. O IP forwarding habilitado na NIC do NVA é condição necessária, mas não suficiente. O NVA precisa também estar configurado no nível do sistema operacional para encaminhar pacotes (por exemplo, net.ipv4.ip_forward=1 no Linux, ou roteamento habilitado no Windows). Sem isso, o NVA recebe os pacotes, mas os descarta em vez de encaminhá-los, comportando-se como um buraco negro.
Os demais distratores representam equívocos comuns: VirtualAppliance é compatível com 0.0.0.0/0 (A é falso); a route table deve mesmo estar na sub-rede de origem, não na do NVA (B é o comportamento correto e já está feito); VMs na mesma VNet podem se comunicar via NVA com UDRs sem restrição topológica (C é falso).
Gabarito — Questão 3
Falso
Essa afirmação é falsa. As UDRs seguem o princípio do prefixo mais longo (longest prefix match). Se existirem rotas de sistema para sub-redes mais específicas dentro de 10.0.0.0/16, como 10.0.1.0/24, essas rotas mais específicas prevalecem sobre a UDR com o prefixo mais amplo. O tráfego destinado a 10.0.1.5, por exemplo, usaria a rota de sistema /24 e não seria descartado pela UDR /16.
O ponto não óbvio aqui é que None descarta tráfego apenas quando não existe rota mais específica que vença no longest prefix match. Compreender essa precedência é essencial para evitar bloqueios acidentais ou, pelo contrário, para criar bloqueios intencionais e precisos.
Gabarito — Questão 4
Resposta: D
Quando uma UDR redireciona tráfego entre VNets pareadas para um NVA, o NVA é responsável por encaminhar esse tráfego ao destino final. Se o NVA não estiver configurado para fazer IP forwarding no nível do SO, os pacotes chegam a ele e são descartados. A rota de peering foi sobrescrita pela UDR (comportamento esperado e correto), mas o elo seguinte da cadeia, o NVA, não completou o encaminhamento.
A alternativa C é tecnicamente relevante em cenários de retorno de tráfego assimétrico, mas não é a causa de descarte na direção spoke -> hub descrita. A alternativa B confunde Use remote gateways com roteamento via NVA: essa opção é relevante para tráfego via VPN Gateway ou ExpressRoute, não para NVAs em peering. A alternativa A é falsa: UDRs funcionam normalmente em topologias com VNet Peering.
Gabarito — Questão 5
Resposta: C
O tipo de próximo salto None instrui o Azure a descartar silenciosamente os pacotes que correspondem ao prefixo, sem tentar encaminhá-los a nenhum destino. É o equivalente a uma rota do tipo "null route" ou "blackhole" em roteamento tradicional.
A alternativa A (Internet) encaminharia o tráfego diretamente para a internet via backbone do Azure, o oposto do requisito. A alternativa B (VirtualNetworkGateway) redirecionaria para um gateway VPN ou ExpressRoute, não descartaria. A alternativa D é inválida: VirtualAppliance exige um endereço IP de próximo salto válido e funcional; 0.0.0.0 não é um endereço operacional, e o comportamento seria imprevisível ou resultaria em erro de configuração.