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

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.

Neste cenário 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:

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.

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, consulte Preferência de roteamento.

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.

Para evitar que as suas VNets spoke sejam programadas com os prefixos internos aprendidos pelo gateway VPN e ExpressRoute, você pode desativar "Propagar rotas de gateway" nas tabelas de rotas das sub-redes spoke. Para garantir que o tráfego de VNet para local seja inspecionado pelo NVA, pode-se configurar uma UDR como 0.0.0.0/0 (rota definida pelo usuário) nas tabelas de rotas das sub-redes spoke, definindo o próximo salto como sendo o NVA/Firewall na VNet central. Observe que desativar "Propagate gateway routes" impedirá que essas sub-redes spoke aprendam dinamicamente rotas do Route Server.

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. 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:

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 1000 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.

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 assegurar a simetria do encaminhamento, ative as políticas de rede da Tabela de Rotas para os pontos finais privados nas sub-redes onde os Pontos Finais Privados são implementados.

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.

Também é importante observar que o Route Server não oferece suporte ao tráfego de caminho de dados. Ao anunciar rotas para o Route Server, o NVA precisa anunciar rotas com o próximo salto como ele mesmo, um balanceador de carga na frente do NVA ou um NVA/Firewall na mesma VNet que o NVA.

Conteúdos relacionados

• Saiba mais sobre o suporte do Azure Route Server para ExpressRoute e Azure VPN.
• Saiba como Configurar o emparelhamento entre o Azure Route Server e o Network Virtual Appliance.