Share via

Injeção de rota padrão em redes virtuais spoke

  • Artigo

Uma das arquiteturas mais comuns no Azure é o design hub and spoke, em que cargas de trabalho implantadas em uma rede virtual spoke (VNet) enviam tráfego por meio de dispositivos de rede compartilhados que existem na VNet do hub. As rotas definidas pelo usuário (UDR) normalmente precisam ser configuradas nas VNets spoke para direcionar o tráfego para dispositivos de segurança no hub. No entanto, esse design exige que os administradores gerenciem essas rotas em muitos raios.

O Azure Route Server oferece um ponto centralizado onde os dispositivos virtuais de rede (NVAs) podem anunciar rotas que ele injeta nas VNets faladas. Dessa forma, os administradores não precisam criar e atualizar tabelas de rotas em VNets faladas.

Topologia

O diagrama a seguir mostra um design simples de hub e spoke com uma VNet de hub e duas VNets de raio. No hub, um dispositivo virtual de rede e um Route Server foram implantados. Sem o Servidor de Rotas, as rotas definidas pelo usuário teriam que ser configuradas em cada raio. Esses UDRs geralmente conteriam uma rota padrão para 0.0.0.0/0 que envia todo o tráfego das VNets spoke através do NVA. Esse cenário pode ser usado, por exemplo, para inspecionar o tráfego para fins de segurança.

Diagrama mostrando uma topologia básica de hub e spoke.

Com o Servidor de Rotas na VNet do hub, não há necessidade de usar rotas definidas pelo usuário. O NVA anuncia prefixos de rede para o Servidor de Rotas, que os injeta para que apareçam nas rotas efetivas de qualquer máquina virtual implantada na VNet de hub ou VNets spoke que são emparelhadas com a VNet de hub com a configuração Usar o gateway da rede virtual remota ou o Servidor de Rota.

Conectividade com o local através do NVA

Se o NVA for usado para fornecer conectividade à rede local por meio de VPNs IPsec ou tecnologias SD-WAN, o mesmo mecanismo pode ser usado para atrair tráfego dos raios para o NVA. Além disso, o NVA pode aprender dinamicamente os prefixos do Azure a partir do Servidor de Rotas do Azure e anunciá-los com um protocolo de roteamento dinâmico para o local. O diagrama a seguir descreve essa configuração:

Diagrama mostrando uma topologia básica de hub e spoke com conectividade local por meio de um NVA.

Inspecionar o tráfego privado através do NVA

As seções anteriores mostram o tráfego sendo inspecionado pelo dispositivo virtual de rede (NVA) injetando uma 0.0.0.0/0 rota padrão do NVA para o servidor de rota. No entanto, se você quiser inspecionar apenas o tráfego falado e falado no local por meio do NVA, considere que o Azure Route Server não anuncia uma rota que seja o mesmo prefixo ou maior do que o espaço de endereço de rede virtual aprendido com o NVA. Em outras palavras, o Azure Route Server não injetará esses prefixos na rede virtual e eles não serão programados nas NICs de máquinas virtuais no hub ou VNets faladas.

O Azure Route Server, no entanto, anunciará uma sub-rede maior do que o espaço de endereço VNet aprendido com o NVA. É possível anunciar a partir da NVA uma super-rede do que você tem em sua rede virtual. Por exemplo, se sua rede virtual usa o espaço 10.0.0.0/16de endereço RFC 1918, seu NVA pode anunciar 10.0.0.0/8 para o Servidor de Rotas do Azure e esses prefixos serão injetados nas VNets hub e spoke. Esse comportamento de VNet é referenciado em Sobre BGP com VPN Gateway.

Diagrama mostrando a injeção de prefixos privados por meio do Azure Route Server e NVA.

Importante

Se você tiver um cenário em que prefixos com o mesmo comprimento estão sendo anunciados da Rota Expressa e da NVA, o Azure preferirá e programará as rotas aprendidas com a Rota Expressa. Para obter mais informações, veja a secção seguinte.

Conectividade com o local através de gateways de rede virtual

Se existir uma VPN ou um gateway de Rota Expressa na mesma rede virtual que o Servidor de Rotas e o NVA para fornecer conectividade a redes locais, as rotas aprendidas por esses gateways também serão programadas nas VNets faladas. Essas rotas substituem a rota padrão (0.0.0.0/0) injetada pelo Servidor de Rotas, pois seriam mais específicas (máscaras de rede mais longas). O diagrama a seguir descreve o design anterior, onde um gateway de Rota Expressa foi adicionado.

Diagrama mostrando uma topologia básica de hub e spoke com conectividade local por meio de um NVA e ExpressRoute.

Não é possível configurar as sub-redes nas VNets spoke para aprender apenas as rotas do Servidor de Rotas do Azure. Desabilitar "Propagar rotas de gateway" em uma tabela de rotas associada a uma sub-rede impediria que ambos os tipos de rotas (rotas do gateway de rede virtual e rotas do Servidor de Rotas do Azure) fossem injetados em NICs nessa sub-rede.

Por padrão, o Route Server anuncia todos os prefixos aprendidos do NVA para o ExpressRoute também. Isso pode não ser desejado, por exemplo, devido aos limites de rota da Rota Expressa ou do próprio Servidor de Rotas. Nesse caso, o NVA pode anunciar suas rotas para o Route Server, incluindo a comunidade no-advertise BGP (com valor 65535:65282). Quando o Route Server recebe rotas com essa comunidade BGP, ele as injeta nas sub-redes, mas não as anuncia para nenhum outro par BGP (como gateways ExpressRoute ou VPN ou outros NVAs).

Coexistência de SDWAN com o ExpressRoute e o Firewall do Azure

Um caso particular do design anterior é quando os clientes inserem o Firewall do Azure no fluxo de tráfego para inspecionar todo o tráfego que vai para redes locais, seja por meio da Rota Expressa ou por meio de dispositivos SD-WAN/VPN. Nessa situação, todas as sub-redes spoke têm tabelas de rotas que impedem que os raios aprendam qualquer rota da Rota Expressa ou do Servidor de Rotas e têm rotas padrão (0.0.0.0/0) com o Firewall do Azure como próximo salto, como mostra o diagrama a seguir:

Diagrama mostrando topologia de hub e spoke com conectividade local via NVA para VPN e ExpressRoute, onde o Firewall do Azure faz o breakout.

A sub-rede do Firewall do Azure aprende as rotas provenientes da Rota Expressa e da VPN/SDWAN NVA, e decide se envia tráfego de uma forma ou de outra. Conforme descrito na seção anterior, se o dispositivo NVA anunciar mais de 200 rotas para o Servidor de Rotas, ele deverá enviar suas rotas BGP marcadas com a comunidade no-advertiseBGP. Dessa forma, os prefixos SDWAN não serão injetados de volta no local via Rota Expressa.

Simetria de tráfego

Se várias instâncias NVA forem usadas no cenário ativo/ativo para melhor resiliência ou escalabilidade, a simetria de tráfego será um requisito se os NVAs precisarem manter o estado das conexões. É o caso, por exemplo, dos Firewalls de Nova Geração.

  • Para conectividade das máquinas virtuais do Azure com a Internet pública, o NVA usa a conversão de endereços de rede de origem (SNAT) para que o tráfego de saída seja originado do endereço IP público do NVA, alcançando assim simetria de tráfego.
  • Para o tráfego de entrada da Internet para cargas de trabalho em execução em máquinas virtuais, além da conversão de endereços de rede (DNAT) de destino, os NVAs precisarão fazer a conversão de endereços de rede de origem (SNAT), para garantir que o tráfego de retorno das máquinas virtuais chegue à mesma instância NVA que processou o primeiro pacote.
  • Para conectividade Azure-to-Azure, como a máquina virtual de origem tomará a decisão de roteamento independentemente do destino, o SNAT é necessário hoje para alcançar a simetria de tráfego.

Várias instâncias NVA também podem ser implantadas em uma configuração ativa/passiva, por exemplo, se uma delas anunciar rotas piores (com um caminho AS mais longo) do que a outra. Nesse caso, o Servidor de Rotas do Azure injetará apenas a rota preferencial nas máquinas virtuais VNet e a rota menos preferencial só será usada quando a instância NVA primária parar de anunciar sobre BGP.

Diferentes servidores de rota para anunciar rotas para gateways de rede virtual e redes virtuais

Como as seções anteriores mostraram, o Servidor de Rotas do Azure tem uma função dupla:

  • Ele aprende e anuncia rotas de/para gateways de rede virtual (VPN e ExpressRoute)
  • Ele configura rotas aprendidas em sua rede virtual e em redes virtuais diretamente emparelhadas

Esta dupla funcionalidade muitas vezes é interessante, mas às vezes pode ser prejudicial para certos requisitos. Por exemplo, se o Servidor de Rotas for implantado em uma VNet com um NVA anunciando uma rota 0.0.0.0/0 e um gateway de Rota Expressa anunciando prefixos de publicidade locais, ele configurará todas as rotas (tanto o 0.0.0.0/0 do NVA quanto os prefixos locais) nas máquinas virtuais em sua VNet e VNets emparelhadas diretamente. Como consequência, como os prefixos locais serão mais específicos do que 0.0.0.0/0, o tráfego entre o local e o Azure ignorará o NVA. Se isso não for desejado, as seções anteriores deste artigo mostraram como desabilitar a propagação de BGP nas sub-redes VM e configurar UDRs.

No entanto, há uma abordagem alternativa e mais dinâmica. É possível usar diferentes Servidores de Rota do Azure para diferentes funcionalidades: um deles será responsável por interagir com os gateways de rede virtual e o outro por interagir com o roteamento de rede virtual. O diagrama a seguir mostra um design possível para isso:

Diagrama mostrando uma topologia básica de hub e spoke com conectividade local via ExpressRoute e dois Servidores de Rota.

O Route Server 1 no hub é usado para injetar os prefixos do SDWAN na Rota Expressa. Como as VNets spoke são emparelhadas com a VNet de hub sem Usar o gateway da rede virtual remota ou o Servidor de Rota (no emparelhamento de VNet falado) e Usar o gateway ou o Servidor de Rota desta rede virtual (Trânsito de gateway no emparelhamento de VNet de hub), as VNets spoke não aprendem essas rotas (nem os prefixos SDWAN nem os prefixos ExpressRoute).

Para propagar rotas para as VNets faladas, o NVA usa o Route Server 2, implantado em uma nova VNet auxiliar. O NVA propagará apenas uma única 0.0.0.0/0 rota para o Route Server 2. Como as VNets spoke são emparelhadas com essa VNet auxiliar com Usar o gateway da rede virtual remota ou o Servidor de Rota (no emparelhamento de VNet falado) e Usar o gateway desta rede virtual ou o Servidor de Rota (Trânsito de gateway no emparelhamento de VNet do hub), a 0.0.0.0/0 rota será aprendida por todas as máquinas virtuais nos raios.

O próximo salto para a 0.0.0.0/0 rota é o NVA, então as VNets faladas ainda precisam ser emparelhadas para a VNet do hub. Outro aspeto importante a ser observado é que a VNet do hub precisa ser emparelhada com a VNet onde o Route Server 2 está implantado, caso contrário, ele não poderá criar a adjacência BGP.

Se o tráfego da Rota Expressa para as VNets spoke for enviado para um NVA de firewall para inspeção, uma tabela de rotas na GatewaySubnet ainda será necessária, caso contrário, o gateway de rede virtual da Rota Expressa enviará pacotes para as máquinas virtuais usando as rotas aprendidas com o emparelhamento de VNet. As rotas nesta tabela de rotas devem corresponder aos prefixos spoke e o próximo salto deve ser o endereço IP do NVA do firewall (ou o balanceador de carga na frente dos NVAs do firewall, para redundância). O NVA do firewall pode ser o mesmo que o NVA SDWAN no diagrama acima, ou pode ser um dispositivo diferente, como o Firewall do Azure, já que o NVA SDWAN pode anunciar rotas com o próximo salto apontando para outros endereços IP. O diagrama a seguir mostra esse design com a adição do Firewall do Azure:

Nota

Para qualquer tráfego local destinado a Pontos de Extremidade Privados, esse tráfego ignorará o NVA do Firewall ou o Firewall do Azure no hub. No entanto, isso resulta em roteamento assimétrico (que pode levar à perda de conectividade entre pontos de extremidade locais e privados) à medida que os pontos de extremidade privados encaminham o tráfego local para o firewall. Para garantir a simetria de roteamento, habilite as políticas de rede da Tabela de Rotas para pontos de extremidade privados nas sub-redes onde os Pontos de Extremidade Privados são implantados.

Diagrama mostrando uma topologia básica de hub e spoke com conectividade local via Rota Expressa, um Firewall do Azure e dois Servidores de Rota.

Este design permite a injeção automática de rotas em VNets spoke sem interferência de outras rotas aprendidas com ExpressRoute, VPN ou um ambiente SDWAN, e a adição de NVAs de firewall para inspeção de tráfego.

Conteúdos relacionados