Roteamento de WAN virtual aprofundado
A WAN Virtual do Azure é uma solução de rede que permite criar facilmente topologias de rede sofisticadas: engloba o encaminhamento entre regiões do Azure entre VNets do Azure e localizações locais através de VPN Ponto a Site, VPN Site a Site, ExpressRoute e dispositivos SDWAN integrados, incluindo a opção de proteger o tráfego. Na maioria dos cenários, não é necessário que você tenha um conhecimento profundo de como o roteamento interno da WAN Virtual funciona, mas em determinadas situações pode ser útil entender os conceitos de roteamento da WAN Virtual.
Este documento explora exemplos de cenários de WAN virtual que explicam alguns dos comportamentos que as organizações podem encontrar ao interconectar suas redes virtuais e ramificações 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 exemplo projetadas para demonstrar determinadas funcionalidades da WAN Virtual.
Cenário 1: topologia com preferência de roteamento padrão
O primeiro cenário neste artigo analisa uma topologia com dois hubs WAN Virtual, ExpressRoute, VPN e conectividade SDWAN. Em cada hub, há VNets conectadas diretamente (VNets 11 e 21) e indiretamente através de um NVA (VNets 121, 122, 221 e 222). A VNet 12 troca informações de roteamento com o hub 1 via BGP (consulte Emparelhamento BGP com um hub virtual), e a VNet 22 tem rotas estáticas configuradas, para que as diferenças entre ambas as opções possam ser mostradas.
Em cada hub, os appliances VPN e SDWAN servem a um duplo propósito: de um lado anunciam seus 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 do 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 WAN Virtual.
Todas as conexões VNet e branch são associadas e propagadas para a tabela de rotas padrão. Embora os hubs sejam seguros (há um Firewall do Azure implantado em cada hub), eles não estão configurados para proteger o tráfego privado ou da Internet. Isso resultaria em todas as conexões se propagando para a tabela de rotas, o None que removeria todas as rotas não estáticas da tabela de Default rotas e derrotaria o objetivo deste artigo, uma vez que a folha de rota efetiva no portal estaria quase vazia (exceto para as rotas estáticas para enviar tráfego para o Firewall do Azure).
Importante
O diagrama anterior mostra dois hubs virtuais seguros, essa topologia é suportada com a intenção de roteamento. Para obter mais informações, consulte Como configurar a intenção de roteamento e as políticas de roteamento do Hub WAN Virtual.
Prontos para uso, os hubs WAN virtuais trocam informações entre si para que a comunicação entre regiões seja habilitada. Você pode inspecionar as rotas efetivas nas tabelas de rotas da WAN Virtual: por exemplo, a imagem a seguir mostra as rotas efetivas no hub 1:
Essas rotas efetivas serão então anunciadas pela WAN Virtual para filiais e as injetarão nas VNets conectadas aos hubs virtuais, tornando desnecessário o uso de 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 estão vindo. Por exemplo, um tipo de próximo salto de "Conexão de rede virtual" indica que o prefixo é definido em uma VNet diretamente conectada à WAN virtual (VNets 11 e 12 na captura de tela anterior)
O NVA na VNet 12 injeta a rota 10.1.20.0/22 sobre BGP, como o tipo de próximo salto "HubBgpConnection" implica (consulte Emparelhamento BGP com um hub virtual). Esta rota de resumo abrange os raios indiretos VNet 121 (10.1.21.0/24) e VNet 122 (10.1.22.0/24). VNets e ramificações no hub remoto são visíveis com um próximo salto de , e pode ser visto no caminho AS que o Número 65520 do hub2Sistema Autônomo foi preparado duas vezes para essas rotas interhub.
No hub 2 há um dispositivo virtual de rede SDWAN integrado. Para obter mais detalhes sobre NVAs suportados para essa integração, visite Sobre NVAs em um hub WAN virtual. Observe que a rota para a ramificação 10.5.3.0/24 SDWAN tem um próximo salto de VPN_S2S_Gateway. Esse tipo de próximo salto pode indicar hoje rotas provenientes de um Gateway de Rede Virtual do Azure ou de NVAs integrados no hub.
No hub 2, a rota para 10.2.20.0/22 os raios 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ê verificar as rotas efetivas para o hub 1, essa rota não estará lá. O motivo é porque as rotas estáticas não são propagadas via BGP, mas precisam ser configuradas em todos os hubs. Assim, uma rota estática é necessária no hub 1 para fornecer conectividade entre as redes virtuais e ramificações no hub 1 para os raios indiretos no hub 2 (VNets 221 e 222):
Depois de adicionar a rota estática, o hub 1 também conterá a 10.2.20.0/22 rota:
Cenário 2: Alcance Global e preferência de roteamento de hub
Mesmo que o hub 1 conheça o prefixo ExpressRoute do circuito 2 (10.5.2.0/24) e o hub 2 conheça o prefixo ExpressRoute do circuito 1 (10.4.2.0/24), as rotas ExpressRoute de regiões remotas não são anunciadas de volta para links ExpressRoute locais. Consequentemente, o Alcance Global da Rota Expressa é necessário para que os locais da Rota Expressa se comuniquem entre si:
Importante
O diagrama anterior mostra dois hubs virtuais seguros, essa topologia é suportada com a intenção de roteamento. Para obter mais informações, consulte Como configurar a intenção de roteamento e as políticas de roteamento do Hub WAN Virtual.
Conforme explicado na preferência de roteamento do hub virtual, a WAN virtual favorece as rotas provenientes da Rota Expressa por padrão. Como as rotas são anunciadas do hub 1 para o circuito 1 da Rota Expressa, do circuito 1 da Rota Expressa para o circuito 2 e do circuito 2 da Rota Expressa para o hub 2 (e vice-versa), os hubs virtuais preferem esse caminho em vez do link interhub mais direto agora. As rotas efetivas no hub 1 mostram isso:
Como você pode ver nas rotas, o Alcance Global da Rota Expressa precede o Número do Sistema Autônomo da Rota Expressa (12076) várias vezes antes de enviar 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 da Rota Expressa ignora o comprimento do caminho AS ao tomar a decisão de roteamento.
As rotas efetivas no hub 2 serão semelhantes:
A preferência de roteamento pode ser alterada para VPN ou AS-Path, conforme explicado em Preferência de roteamento de hub virtual. Por exemplo, você pode 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 têm esta aparência:
A imagem anterior mostra que a rota para 10.4.2.0/24 tem agora um próximo salto de , enquanto com a preferência de VPN_S2S_Gatewayroteamento padrão da Rota Expressa era ExpressRouteGateway. No entanto, no hub 2 a rota para 10.5.2.0/24 ainda aparecerá com um próximo salto de ExpressRoute, porque neste caso a rota alternativa não vem de um gateway VPN, mas de um NVA integrado no hub:
No entanto, o tráfego entre hubs ainda está preferindo as rotas que vêm via ExpressRoute. Para usar a conexão direta mais eficiente entre os hubs virtuais, a preferência de rota pode ser definida como "Caminho AS" em ambos os hubs:
Agora, as rotas para raios remotos e ramificações no hub 1 terão um próximo salto de Remote Hub como pretendido:
Você pode ver que o prefixo IP para o hub 2 (192.168.2.0/23) ainda aparece acessível pelo link Alcance Global, mas isso não deve afetar o tráfego, pois não deve haver nenhum tráfego endereçado a dispositivos no hub 2. Essa rota poderia ser um problema, no entanto, se houvesse NVAs em ambos os hubs estabelecendo túneis SDWAN entre si.
No entanto, observe que 10.4.2.0/24 agora é preferível sobre o VPN Gateway. Isso pode acontecer se as rotas anunciadas via VPN tiverem um caminho AS mais curto do que as rotas anunciadas pela Rota Expressa. Depois de configurar o dispositivo VPN local para anexar seu Número de Sistema Autônomo (65501) às rotas VPN para tornar o menos preferível, o hub 1 agora seleciona ExpressRoute como próximo salto para 10.4.2.0/24:
O Hub 2 mostrará uma tabela semelhante para as rotas efetivas, onde as VNets e ramificações no outro hub agora aparecem com Remote Hub o próximo salto:
Cenário 3: Conexão cruzada dos circuitos da Rota Expressa a ambos os hubs
Para adicionar links diretos entre as regiões do Azure e os locais locais conectados via Rota Expressa, geralmente é desejável conectar um único circuito de Rota Expressa a vários hubs de WAN Virtual em uma topologia algumas vezes descrita como "gravata borboleta", como mostra a topologia a seguir:
Importante
O diagrama anterior mostra dois hubs virtuais seguros, essa topologia é suportada com a intenção de roteamento. Para obter mais informações, consulte Como configurar a intenção de roteamento e as políticas de roteamento do Hub 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 da Rota Expressa, as rotas para ramificações remotas e redes virtuais no hub 1 mostrarão novamente a Rota Expressa como próximo salto. Embora desta vez o motivo não seja o alcance global, mas o fato de que os circuitos da Rota Expressa recuperam os anúncios de rota que recebem de um hub para o outro. Por exemplo, as rotas efetivas do hub 1 com preferência de roteamento de hub da Rota Expressa são as seguintes:
Alterar novamente a preferência de roteamento de hub para AS Path retorna as rotas entre hubs para o caminho ideal usando a conexão direta entre hubs 1 e 2:
Próximos passos
Para obter mais informações sobre a WAN Virtual, consulte:
- Perguntas frequentes sobre a WAN virtual