Aprofundamento sobre o roteamento de WAN Virtual

A WAN Virtual do Azure é uma solução de rede que permite criar topologias de rede sofisticadas com facilidade: abrange o roteamento em regiões do Azure entre as VNets do Azure e locais internos por meio de VPN ponto a site, VPN site a site, ExpressRoute e soluções de virtualização de SDWAN integradas, incluindo a opção para proteger o tráfego. Na maioria dos cenários, não é necessário ter conhecimento aprofundado sobre como o roteamento interno da WAN Virtual funciona, mas em determinadas situações poderá ser útil compreender os conceitos de roteamento da WAN Virtual.

Este documento explora os exemplos de cenários de WAN Virtual que explicam alguns dos comportamentos que as organizações poderão encontrar ao interconectar as VNets e filiais em redes complexas. Os cenários mostrados neste artigo não são de forma alguma recomendações de design, são apenas topologias de amostras projetadas para demonstrar determinadas funcionalidades da WAN Virtual.

Cenário 1: topologia com preferência de roteamento padrão

O primeiro cenário deste artigo analisa uma topologia com dois hubs da WAN Virtual, ExpressRoute, VPN e conectividade SDWAN. Em cada hub, há VNets conectadas diretamente (VNets 11 e 21) e indiretamente por meio de uma NVA (VNets 121, 122, 221 e 222). A VNet 12 troca informações de roteamento com o hub 1 por meio de BGP (consulte Emparelhamento de BGP com um hub virtual), e a VNet 22 tem rotas estáticas configuradas para que as diferenças entre as duas opções possam ser mostradas.

Em cada hub, os dispositivos de VPN e SDWAN servem a uma dupla finalidade: de um lado, anunciam os próprios prefixos individuais (10.4.1.0/24 sobre VPN no hub 1 e 10.5.3.0/24 sobre SDWAN no hub 2) e, de outro, anunciam os mesmos prefixos que os circuitos ExpressRoute na mesma região (10.4.2.0/24 no hub 1 e 10.5.2.0/24 no hub 2). Essa diferença será usada para demonstrar como funciona a Preferência de roteamento do hub da WAN Virtual.

Todas as conexões de filial e VNet são associadas e propagadas para a tabela de roteamento padrão. Embora os hubs sejam protegidos (há um Firewall do Azure implantado em cada hub), eles não são configurados para proteger o tráfego privado ou da Internet. Isso faria com que todas as conexões se propagassem para a tabela de roteamento None, o que removeria todas as rotas não estáticas da tabela de roteamento Default e anularia o objetivo deste artigo, pois a folha de rota efetiva no portal estaria quase vazia (exceto as rotas estáticas para enviar o tráfego ao Firewall do Azure).

Importante

O diagrama anterior mostra dois hubs virtuais seguros, topologia essa que tem suporte pela Intenção de Roteamento. Para obter mais informações, consulte Como configurar políticas de roteamento e intenção de roteamento do Hub da WAN Virtual.

Prontos para usar, os hubs de WAN Virtual trocam informações entre si para que a comunicação entre as regiões seja habilitada. Você poderá inspecionar as rotas efetivas nas tabelas de roteamento de WAN Virtual: por exemplo, a imagem a seguir mostra as rotas efetivas no hub 1:

Essas rotas efetivas serão, em seguida, anunciadas pela WAN Virtual às filiais e as injetarão nas VNets conectadas aos hubs virtuais, tornando desnecessário usar Rotas Definidas pelo Usuário. Ao inspecionar as rotas efetivas em um hub virtual, os campos "Tipo de Próximo Salto" e "Origem" indicarão de onde as rotas são provenientes. Por exemplo, um Tipo de Próximo Salto de "Conexão de Rede Virtual" indica que o prefixo está definido em uma VNet conectada diretamente à WAN Virtual (VNets 11 e 12 na captura de tela anterior).

A NVA na VNet 12 injeta a rota 10.1.20.0/22 no BGP, como indica o Tipo de Próximo Salto "HubBgpConnection" (confira Emparelhamento do BGP com um Hub Virtual). Essa rota de resumo abrange ambos os spokes indiretos VNet 121 (10.1.21.0/24) e VNet 122 (10.1.22.0/24). As VNets e filiais no hub remoto são visíveis com um próximo salto de hub2 e poderá ser visto no caminho de AS que o Número de Sistema Autônomo 65520 foi anexado duas vezes a essas rotas entre hubs.

No hub 2, há uma Solução de Virtualização de Rede SDWAN integrada. Para obter mais detalhes sobre NVAs com suporte para essa integração, visite Sobre NVAs em um hub de WAN Virtual. Observe que a rota para a filial de SDWAN 10.5.3.0/24 tem um próximo salto de VPN_S2S_Gateway. Esse tipo de próximo salto pode indicar atualmente as rotas provenientes de um Gateway de Rede Virtual do Azure ou de NVAs integradas ao hub.

No hub 2, a rota para 10.2.20.0/22 para os spokes indiretos VNet 221 (10.2.21.0/24) e VNet 222 (10.2.22.0/24) é instalada como uma rota estática, conforme indicado pela origem defaultRouteTable. Se você fizer check-in das rotas efetivas para o hub 1, essa rota não estará lá. O motivo é porque as rotas estáticas não são propagadas por meio de BGP, mas devem ser configuradas em cada hub. Portanto, uma rota estática será necessária no hub 1 para fornecer conectividade entre as VNets e filiais no hub 1 para os spokes indiretos no hub 2 (VNets 221 e 222):

Após adicionar a rota estática, o hub 1 também conterá a rota 10.2.20.0/22:

Cenário 2: Alcance Global e preferência de roteamento de hub

Mesmo que o hub 1 conheça o prefixo do ExpressRoute do circuito 2 (10.5.2.0/24) e o hub 2 conheça o prefixo do ExpressRoute do circuito 1 (10.4.2.0/24), as rotas do ExpressRoute de regiões remotas não são anunciadas de volta para links do ExpressRoute locais. Consequentemente, o Alcance Global do ExpressRoute é necessário para que os locais do ExpressRoute se comuniquem entre si:

Importante

O diagrama anterior mostra dois hubs virtuais seguros, topologia essa que tem suporte pela Intenção de Roteamento. Para obter mais informações, consulte Como configurar políticas de roteamento e intenção de roteamento do Hub da WAN Virtual.

Conforme explicado na Preferência de roteamento do hub virtual, por padrão, a WAN Virtual favorece as rotas provenientes do ExpressRoute. Como as rotas são anunciadas do hub 1 para o circuito ExpressRoute 1, do circuito ExpressRoute 1 para o circuito 2 e do circuito ExpressRoute 2 para o hub 2 (e vice-versa), agora os hubs virtuais preferem esse caminho em vez do link entre hubs mais direto. As rotas efetivas no hub 1 mostram o seguinte:

Como é possível ver nas rotas, o Alcance Global do ExpressRoute precede o Número de Sistema Autônomo do ExpressRoute (12076) várias vezes antes de enviar as rotas de volta ao Azure para tornar essas rotas menos preferíveis. No entanto, a precedência de roteamento de hub padrão da WAN Virtual do ExpressRoute ignora o comprimento do caminho de AS ao tomar a decisão de roteamento.

As rotas efetivas no hub 2 serão semelhantes:

A preferência de roteamento poderá ser alterada para VPN ou AS-Path, conforme explicado na Preferência de roteamento de hub virtual. Por exemplo, você poderá definir a preferência para VPN conforme mostrado nesta imagem:

Com uma preferência de roteamento de hub de VPN, as rotas efetivas no hub 1 serão semelhantes ao seguinte:

A imagem anterior mostra que a rota para 10.4.2.0/24 teve um próximo salto de VPN_S2S_Gateway, enquanto com a preferência de roteamento padrão do ExpressRoute foi ExpressRouteGateway. No entanto, no hub 2 a rota para 10.5.2.0/24 ainda aparecerá com um próximo salto de ExpressRoute, pois, nesse caso, a rota alternativa não é proveniente de um Gateway de VPN mas de uma NVA integrada no hub:

No entanto, o tráfego entre os hubs ainda prefere as rotas que chegam por meio do ExpressRoute. Para usar a conexão direta mais eficiente entre os hubs virtuais, a preferência de rota pode ser definida como "AS Path" em ambos os hubs:

Agora, as rotas para filiais e spokes remotos no hub 1 terão um próximo salto de Remote Hub, conforme pretendido:

É possível ver que o prefixo IP do hub 2 (192.168.2.0/23) ainda parece acessível pelo link Alcance Global, mas isso não deverá afetar o tráfego, pois não deverá haver tráfegos endereçados a dispositivos no hub 2. Essa rota poderá ser um problema se houver NVAs em ambos os hubs estabelecendo túneis SDWAN entre si.

No entanto, observe que 10.4.2.0/24 agora é preferencial ao Gateway de VPN. Isso poderá acontecer se as rotas anunciadas por meio de VPN tiverem um caminho de AS mais curto do que as rotas anunciadas no ExpressRoute. Após configurar o dispositivo VPN local para anexar o Número de Sistema Autônomo (65501) às rotas VPN para tornar o menos preferencial, o hub 1 selecionará o ExpressRoute como próximo salto para: 10.4.2.0/24:

O Hub 2 mostrará uma tabela semelhante para as rotas efetivas, em que as VNets e as filiais no outro hub agora aparecerão com Remote Hub como próximo salto:

Cenário 3: Conexão cruzada dos circuitos do ExpressRoute a ambos os hubs

Para adicionar links diretos entre as regiões do Azure e os locais conectados por meio do ExpressRoute, geralmente é desejável conectar apenas um circuito ExpressRoute a vários hubs de WAN Virtual em uma topologia algumas vezes descrita como "gravata-borboleta", como a seguinte topologia mostra:

Importante

O diagrama anterior mostra dois hubs virtuais seguros, topologia essa que tem suporte pela Intenção de Roteamento. Para obter mais informações, confira Como configurar políticas de roteamento e a intenção de roteamento do Hub da WAN Virtual.

A WAN Virtual mostra que ambos os circuitos estão conectados a ambos os hubs:

Voltando à preferência de roteamento de hub padrão do ExpressRoute, as rotas para as filiais remotas e VNets no hub 1 mostrarão novamente o ExpressRoute como próximo salto. Embora agora o motivo não seja o Alcance Global, mas o fato de que os circuitos do ExpressRoute recuperam os anúncios de rota que obtêm de um hub para o outro. Por exemplo, as rotas efetivas do hub 1 com a preferência de roteamento de hub do ExpressRoute são as seguintes:

A alteração da preferência de roteamento do hub novamente para AS Path retorna as rotas entre hubs para o caminho ideal usando a conexão direta entre os hubs 1 e 2:

Próximas etapas

Para obter mais informações sobre a WAN Virtual, veja:

• As Perguntas frequentes da WAN Virtual