Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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 a preferência de roteamento do hub WAN Virtual funciona.
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 na propagação de todas as conexões para a tabela de rotas None, o que removeria todas as rotas não estáticas da tabela de rotas Default e comprometeria o objetivo deste artigo, uma vez que a lista de rotas efetivas no portal ficaria quase vazia (exceto pelas rotas estáticas para enviar o tráfego ao Firewall do Azure).
Importante
O diagrama anterior mostra dois hubs virtuais seguros. Esta topologia é suportada com Routing Intent. 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 num hub virtual, os campos "Tipo de próximo salto" e "Origem" indicarão de onde vêm as rotas. Por exemplo, um tipo de próximo salto de "Conexão de Rede Virtual" indica que o prefixo está definido numa VNet que está diretamente conectada à Rede WAN Virtual (VNets 11 e 12 na imagem 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 hub2, e pode-se ver no caminho AS que o Número de Sistema Autónomo 65520 foi prefixado duas vezes para estas rotas interhub.
No hub 2 há um dispositivo virtual de rede SDWAN integrado. Para obter mais detalhes sobre as NVAs suportadas para esta integração, visite Sobre NVAs num hub WAN virtual. Observe que a rota para a filial SDWAN 10.5.3.0/24 tem um próximo salto de VPN_S2S_Gateway. Este tipo de próximo salto pode atualmente indicar rotas provenientes de um gateway de rede virtual do Azure ou de NVAs integradas 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. Ao verificar as rotas efetivas para o hub 1, essa rota não se encontra lá. O motivo é porque as rotas estáticas não são propagadas via BGP, mas precisam ser configuradas em todos os hubs. Assim, é necessária uma rota estática no hub 1 para fornecer conectividade entre as VNets e as filiais no hub 1 e 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, esta topologia é suportada pela 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 se pode ver nas rotas, o ExpressRoute Global Reach antecipa várias vezes o Número do Sistema Autónomo do ExpressRoute (12076) antes de enviar as rotas de volta ao Azure, tornando essas rotas menos preferidas. No entanto, a precedência de roteamento padrão do hub da Virtual WAN do ExpressRoute ignora o comprimento do caminho AS ao tomar decisões 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 como VPN.
Com uma preferência de roteamento de VPN para hub, 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 VPN_S2S_Gateway, enquanto com a preferência de roteamento 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 pelo ExpressRoute. Depois de configurar o dispositivo VPN no local para adicionar seu Número de Sistema Autónomo (65501) às rotas VPN para torná-las menos preferíveis, o hub 1 agora seleciona ExpressRoute como próximo salto para 10.4.2.0/24:
O Hub 2 irá mostrar uma tabela semelhante para as rotas efetivas, onde as VNets e filiais no outro hub agora aparecem com Remote Hub como 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 as localizações locais conectadas via ExpressRoute, geralmente é desejável conectar um único circuito de ExpressRoute a vários hubs de WAN Virtual em uma topologia que às vezes é descrita como "gravata borboleta", como mostra a topologia a seguir:
Importante
O diagrama anterior mostra dois hubs virtuais seguros, esta topologia é suportada pela Routing Intent. 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:
Ao retornar à preferência de roteamento padrão do hub do ExpressRoute, as rotas para as filiais remotas e VNets no hub 1 voltarão a mostrar o ExpressRoute como próximo salto. Embora desta vez o motivo não seja o alcance global, mas o facto de que os circuitos do ExpressRoute fazem voltar 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 da WAN Virtual FAQ