Pular para o conteúdo principal

Laboratório Técnico: Configure Virtual Hub Routing

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de rede precisa garantir que o tráfego entre duas redes virtuais (VNets) conectadas ao mesmo Virtual WAN hub seja inspecionado por um NVA (Network Virtual Appliance) hospedado em uma VNet dedicada, também conectada ao mesmo hub. As VNets de carga de trabalho não devem se comunicar diretamente entre si.

Qual configuração de roteamento no Virtual WAN hub atende a esse requisito?

A) Criar uma Route Table customizada e associar as VNet connections das cargas de trabalho a ela, com rotas estáticas apontando o prefixo das outras VNets para o próximo salto no NVA, e propagar essas connections apenas para a Route Table do NVA.

B) Associar todas as VNet connections à Route Table padrão (defaultRouteTable) e adicionar rotas estáticas com o prefixo 0.0.0.0/0 apontando para o NVA.

C) Habilitar o Routing Intent com política de tráfego privado e definir o NVA como próximo salto, sem necessidade de Route Tables customizadas adicionais.

D) Criar uma Route Table customizada, associar todas as VNet connections a ela e configurar propagação bidirecional entre todas as connections para garantir visibilidade mútua.

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

Um arquiteto configurou o Virtual WAN hub com a seguinte estrutura de roteamento:

  • VNet-App connection: associada à RT-App, propaga para RT-App e defaultRouteTable
  • VNet-Shared connection: associada à defaultRouteTable, propaga para defaultRouteTable
  • VNet-App não recebe rotas de VNet-Shared

Após revisar os logs, o arquiteto confirma que VNet-App não consegue alcançar recursos em VNet-Shared. Qual é a causa mais provável?

A) A connection de VNet-App propaga para defaultRouteTable, mas a defaultRouteTable não está associada à connection de VNet-App, logo ela não recebe as rotas que VNet-Shared propaga.

B) VNet-Shared precisa propagar suas rotas também para RT-App para que VNet-App aprenda o prefixo de VNet-Shared.

C) O Virtual WAN hub exige que ambas as connections estejam associadas à mesma Route Table para que a comunicação entre VNets seja possível.

D) A propagação de VNet-App para defaultRouteTable está criando um loop de roteamento que descarta os pacotes antes de chegarem a VNet-Shared.

Questão 3 — Verdadeiro ou Falso​

Afirmação: No Azure Virtual WAN, quando o Routing Intent está habilitado com política de tráfego privado, as rotas aprendidas via BGP pelas conexões de Site-to-Site VPN e ExpressRoute são automaticamente suprimidas da defaultRouteTable, e o hub passa a anunciar apenas a rota 0.0.0.0/0 e os prefixos RFC 1918 como rotas de retorno para os branches.

Verdadeiro ou Falso?

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

Uma empresa possui dois Virtual WAN hubs na mesma vWAN: Hub-East e Hub-West. Uma VNet conectada ao Hub-East precisa alcançar uma VNet conectada ao Hub-West. O time de rede relata que a conectividade entre as VNets não está funcionando, apesar de ambas as connections estarem associadas e propagando para a defaultRouteTable de seus respectivos hubs.

Hub-East defaultRouteTable:
  - Rota para VNet-East: Next Hop = VNet-East connection
  - (sem rota para prefixos de Hub-West)

Hub-West defaultRouteTable:
  - Rota para VNet-West: Next Hop = VNet-West connection
  - (sem rota para prefixos de Hub-East)

Qual é a causa raiz do problema?

A) As VNet connections precisam propagar para a Route Table do hub remoto diretamente, o que não é suportado no Virtual WAN.

B) A conectividade inter-hub depende de que os hubs estejam conectados entre si; se a conexão inter-hub não estiver estabelecida ou estiver desabilitada, os prefixos de um hub não são propagados para o outro.

C) É necessário criar rotas estáticas manuais em ambas as defaultRouteTables apontando os prefixos remotos para o endereço IP do hub remoto.

D) VNets só podem se comunicar entre hubs diferentes se estiverem associadas a uma Route Table customizada com o label cross-hub habilitado.

Questão 5 — Múltipla Escolha​

Ao configurar rotas estáticas em uma Route Table de um Virtual WAN hub, qual das opções abaixo descreve corretamente o comportamento do campo próximo salto (next hop)?

A) O próximo salto deve ser obrigatoriamente um endereço IP privado de um recurso dentro de uma VNet conectada ao hub, pois o Virtual WAN não aceita connection objects como próximo salto.

B) O próximo salto pode ser uma VNet connection, uma VPN connection, uma ExpressRoute connection ou o endereço IP de um NVA em uma VNet spoke, dependendo do tipo de rota configurada.

C) O próximo salto em rotas estáticas no hub aceita apenas endereços IP, nunca objetos de connection, independentemente do tipo de tráfego.

D) O próximo salto para rotas estáticas que direcionam tráfego a um NVA deve ser o endereço IP público do NVA, pois o hub roteia o tráfego via internet antes de entregá-lo à VNet spoke.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: A

A alternativa A descreve corretamente o padrão de segmentação de roteamento com inspeção via NVA no Virtual WAN. As VNet connections das cargas de trabalho são associadas a uma Route Table customizada com rotas estáticas direcionando o tráfego para o próximo salto no NVA. A propagação é configurada apenas para a Route Table do NVA, impedindo que as VNets de carga de trabalho aprendam rotas umas das outras diretamente.

O principal erro dos distratores:

  • B usa 0.0.0.0/0 para direcionar todo o tráfego ao NVA, mas sem segmentação entre as conexões, o que permite comunicação direta entre as VNets via rotas aprendidas.
  • C descreve o Routing Intent, que é válido para cenários com Azure Firewall ou NVAs suportados via Routing Intent, mas não é aplicável a qualquer NVA arbitrário em uma VNet spoke sem suporte explícito.
  • D configura propagação bidirecional entre todas as connections, o que permite visibilidade direta entre as VNets, violando o requisito de isolamento.

Gabarito — Questão 2​

Resposta: B

O mecanismo central aqui é: uma VNet connection aprende apenas as rotas que são propagadas para a Route Table à qual ela está associada. Como VNet-App está associada à RT-App, ela aprende apenas o que é propagado para RT-App. A connection de VNet-Shared propaga apenas para defaultRouteTable, e não para RT-App. Portanto, VNet-App nunca aprende o prefixo de VNet-Shared.

O distrator A confunde o sentido do fluxo: a propagação de VNet-App para defaultRouteTable determina o que outros aprendem sobre VNet-App, não o que VNet-App aprende sobre outros.

O distrator C é um equívoco comum: o Virtual WAN suporta explicitamente comunicação entre VNets em Route Tables diferentes, desde que o roteamento seja configurado corretamente.

Gabarito — Questão 3​

Resposta: Falso

A afirmação mistura dois comportamentos distintos. Quando o Routing Intent com política de tráfego privado está habilitado, o hub anuncia os prefixos RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) para os branches como rotas de atração, direcionando o tráfego privado pelo next hop configurado (ex: Azure Firewall). No entanto, as rotas aprendidas via BGP das conexões de branch não são simplesmente suprimidas da defaultRouteTable: elas continuam sendo processadas pelo hub para garantir roteamento de retorno adequado. O Routing Intent modifica o comportamento de anúncio de rotas para os branches, mas não elimina o aprendizado interno de rotas BGP no hub.

Gabarito — Questão 4​

Resposta: B

No Virtual WAN, a propagação de rotas entre hubs ocorre automaticamente somente quando os hubs estão conectados entre si (conexão inter-hub estabelecida dentro da mesma vWAN). Sem essa conexão ativa, cada hub opera de forma isolada: as defaultRouteTables não trocam informações e os prefixos de VNets de um hub não aparecem no outro.

O distrator C descreve uma solução para roteamento com NVAs ou cenários específicos, mas não é a causa raiz nem a correção adequada para o problema descrito. O distrator D é inteiramente fictício: não existe o conceito de label cross-hub no Virtual WAN.

Gabarito — Questão 5​

Resposta: B

Em Route Tables de Virtual WAN hubs, o campo de próximo salto aceita diferentes tipos de objetos dependendo do destino desejado. Para direcionar tráfego a uma VNet spoke, o próximo salto pode ser a própria VNet connection. Para direcionar a um NVA dentro de uma VNet spoke, o próximo salto é o endereço IP privado do NVA. Para branches, pode ser uma VPN ou ExpressRoute connection.

O distrator A nega a possibilidade de usar connection objects, o que é incorreto. O distrator C generaliza incorretamente que apenas IPs são aceitos. O distrator D é tecnicamente inválido: o hub nunca roteia tráfego privado via endereço IP público de um NVA, pois isso violaria o modelo de roteamento privado do Virtual WAN.