Laboratório Técnico: Design service chaining, including gateway transit
Questões
Questão 1 — Múltipla Escolha
Uma organização possui três redes virtuais no Azure: Hub-VNet, Spoke-A e Spoke-B. O Hub-VNet contém um gateway de VPN conectado à rede local. O peering entre Hub-VNet e cada Spoke está configurado, mas os usuários da rede local não conseguem alcançar as VMs nos Spokes.
Qual par de configurações deve ser habilitado nos peerings para que o tráfego da rede local atravesse o gateway do Hub até os Spokes?
A) Allow gateway transit no peering do Hub para os Spokes e Use remote gateways no peering dos Spokes para o Hub
B) Use remote gateways no peering do Hub para os Spokes e Allow gateway transit no peering dos Spokes para o Hub
C) Allow gateway transit em ambos os lados do peering, tanto no Hub quanto nos Spokes
D) Allow forwarded traffic no peering do Hub para os Spokes e Use remote gateways no peering dos Spokes para o Hub
Questão 2 — Cenário Técnico
Um arquiteto configurou a topologia abaixo para encadear serviços entre Spokes usando um Network Virtual Appliance (NVA) no Hub:
Spoke-A (10.1.0.0/16) --> Hub-VNet (10.0.0.0/16) --> Spoke-B (10.2.0.0/16)
NVA: 10.0.1.4
As rotas definidas pelo usuário (UDRs) foram aplicadas em Spoke-A apontando o next hop para 10.0.1.4. O tráfego de Spoke-A chega ao NVA, mas não avança para Spoke-B.
Qual é a causa mais provável do problema?
A) O peering entre Hub-VNet e Spoke-B não está com Allow forwarded traffic habilitado
B) O NVA não possui IP Forwarding habilitado no nível do adaptador de rede (NIC) no Azure
C) A UDR em Spoke-A está apontando para o endereço IP do NVA em vez do gateway padrão do Hub
D) O peering entre Spoke-A e Hub-VNet não possui Use remote gateways habilitado
Questão 3 — Verdadeiro ou Falso
Uma Spoke VNet que já utiliza Use remote gateways para aproveitar o gateway de VPN do Hub pode, simultaneamente, ter seu próprio gateway de rede virtual implantado para conexões independentes com a rede local.
Questão 4 — Cenário Técnico
Uma empresa precisa que todo o tráfego de saída das VMs em Spoke-A passe por um NVA no Hub antes de alcançar a internet. O peering entre Spoke-A e Hub-VNet está ativo. O arquiteto aplica a seguinte UDR na sub-rede de Spoke-A:
Destino: 0.0.0.0/0
Next Hop Type: Virtual Appliance
Next Hop Address: 10.0.1.4
Após a configuração, o tráfego ainda segue diretamente para a internet sem passar pelo NVA.
Qual configuração ausente explica esse comportamento?
A) Allow gateway transit não está habilitado no peering do Hub para Spoke-A
B) Allow forwarded traffic não está habilitado no peering do Hub-VNet para Spoke-A
C) A UDR foi aplicada na sub-rede correta, mas o next hop deveria ser do tipo Internet em vez de Virtual Appliance
D) Use remote gateways não está habilitado no peering de Spoke-A para o Hub
Questão 5 — Múltipla Escolha
Em uma topologia hub-and-spoke, qual é o comportamento padrão do Azure em relação ao tráfego entre dois Spokes que fazem peering apenas com o Hub, sem peering direto entre si?
A) O tráfego flui automaticamente entre os Spokes através do Hub, pois o peering é transitivo por padrão
B) O tráfego entre Spokes é bloqueado pelo Azure e não pode ser roteado de nenhuma forma
C) O tráfego entre Spokes não flui automaticamente; é necessário um mecanismo de encaminhamento no Hub, como um NVA com UDRs
D) O tráfego entre Spokes flui automaticamente somente se Allow forwarded traffic estiver habilitado em ambos os peerings com o Hub
Gabarito e Explicações
Gabarito — Questão 1
Resposta: A
O gateway transit é uma funcionalidade assimétrica por design. O lado que possui o gateway deve habilitar Allow gateway transit, sinalizando que está disposto a compartilhá-lo. O lado que não possui gateway deve habilitar Use remote gateways, sinalizando que deseja utilizar o gateway remoto.
Inverter as opções (alternativa B) é o erro mais comum: Use remote gateways no Hub seria inválido porque o Hub é exatamente o lado que possui o gateway. A alternativa C ignora que as opções são complementares e direcionadas, não simétricas. A alternativa D confunde Allow forwarded traffic, que controla tráfego originado fora da VNet, com o mecanismo de compartilhamento de gateway.
Sem essa configuração correta, as rotas da rede local aprendidas pelo gateway do Hub simplesmente não são propagadas para os Spokes.
Gabarito — Questão 2
Resposta: B
Quando um pacote chega ao NVA e precisa ser encaminhado para outro destino, o Azure, por padrão, descarta pacotes cujo endereço IP de destino não corresponde à NIC que os recebeu. O IP Forwarding deve ser habilitado explicitamente na NIC do NVA no portal do Azure (ou via API), além de estar ativado no sistema operacional da VM.
A alternativa A descreve uma condição relevante para tráfego entre Spokes, mas o enunciado indica que o tráfego já sai de Spoke-A e chega ao NVA; o problema está no que acontece depois. A alternativa C é um equívoco conceitual: a UDR corretamente aponta para o IP do NVA como next hop do tipo Virtual Appliance. A alternativa D é irrelevante para esse fluxo, pois Use remote gateways é exclusivo para compartilhamento de gateway VPN/ExpressRoute.
Gabarito — Questão 3
Resposta: Falso
O Azure impõe uma restrição explícita: uma VNet que utiliza Use remote gateways não pode ter um gateway de rede virtual próprio implantado. As duas condições são mutuamente exclusivas. Se uma Spoke VNet precisar de conexões independentes com a rede local, ela deve ter seu próprio gateway e, nesse caso, não pode ativar Use remote gateways.
Esse comportamento existe porque o Azure não consegue determinar de forma consistente qual gateway deve ser usado para aprender e anunciar rotas se ambos existirem simultaneamente. Tentar implantar um gateway em uma VNet com Use remote gateways ativo resultará em erro durante a implantação.
Gabarito — Questão 4
Resposta: B
Allow forwarded traffic controla se a VNet de destino aceita pacotes cujo endereço IP de origem está fora da VNet de onde o tráfego foi encaminhado. Quando o NVA no Hub encaminha o tráfego de Spoke-A para a internet, o pacote tem origem em 10.1.x.x (Spoke-A) e chega ao Hub via peering. Para que o Hub aceite e processe esse tráfego encaminhado, o peering do Hub para Spoke-A precisa ter Allow forwarded traffic habilitado.
A alternativa A refere-se a gateway transit, que é irrelevante para esse fluxo de saída para internet via NVA. A alternativa C é tecnicamente incorreta: Virtual Appliance é o tipo de next hop correto para redirecionar tráfego a um NVA. A alternativa D trata de remote gateways, que não tem relação com o encaminhamento de tráfego por NVA.
Gabarito — Questão 5
Resposta: C
O peering de redes virtuais no Azure não é transitivo. Isso significa que, mesmo que Spoke-A e Spoke-B façam peering com o Hub, elas não se enxergam automaticamente. O Azure não roteia tráfego entre peers de forma encadeada por padrão.
Para viabilizar a comunicação entre Spokes, é necessário um mecanismo explícito no Hub, sendo o mais comum um NVA combinado com UDRs em cada Spoke apontando o tráfego destinado ao outro Spoke para o IP do NVA.
A alternativa A representa a confusão mais frequente: assumir transitividade onde ela não existe. A alternativa B é excessivamente restritiva; o tráfego pode ser roteado, mas exige configuração intencional. A alternativa D descreve um requisito real para tráfego encaminhado, mas sozinho não resolve a ausência de transitividade; sem o NVA e as UDRs, o tráfego ainda não fluirá entre Spokes.