Injeção de rota padrão em redes virtuais do spoke
Uma das arquiteturas mais comuns no Azure é o design de hub e spoke, em que as cargas de trabalho implantadas em uma rede virtual (VNet) do spoke enviam tráfego por meio dos dispositivos de rede compartilhados que existem na VNet do hub. Normalmente, as UDR (rotas definidas pelo usuário) precisam ser configuradas nos VNets do 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 vários spokes.
O Servidor de Rota do Azure oferece um ponto centralizado em que NVAs (soluções de virtualização de rede) podem anunciar toas injetadas nas VNets do spoke. Dessa forma, os administradores não precisam criar e atualizar tabelas de rotas em VNets do spoke.
Topologia
O diagrama a seguir descreve um design simples de hub e spoke com uma VNet de hub e duas VNets de spoke. No hub, uma solução de virtualização de rede e um Servidor de Rota foram implantados. Sem o Servidor de Rota, as rotas definidas pelo usuário teriam que ser configuradas em cada spoke. Essas UDRs geralmente contêm uma rota padrão para 0.0.0.0/0 que envia todo o tráfego das VNets do spoke por meio de NVA. Esse cenário pode ser usado, por exemplo, para inspecionar o tráfego para fins de segurança.
Com o Servidor de Rota na VNet do hub, não é necessário usar rotas definidas pelo usuário. A NVA anuncia prefixos de rede para o Servidor de Rota, que os injeta para que apareçam nas rotas efetivas em qualquer máquina virtual implantada na VNet do hub ou nas VNets do spoke que são emparelhadas com a VNet do hub com a configuração Usar o gateway da rede virtual remota ou 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 de tecnologias de SD-WAN, o mesmo mecanismo poderá ser usado para atrair o tráfego dos Spokes para o NVA. Além disso, o NVA pode aprender de forma dinâmica os prefixos do Azure no Servidor de Rota 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 por meio da NVA
As seções anteriores descrevem o tráfego que está sendo inspecionado pela NVA (solução de virtualização de rede) injetando uma rota padrão 0.0.0.0/0 da NVA para o Servidor de Rota. No entanto, se você quiser inspecionar apenas o tráfego spoke a spoke e spoke a local por meio da NVA, considere que o Servidor de Rota do Azure não anuncia um rota com o mesmo prefixo ou maior que o espaço de endereço da rede virtual aprendido na NVA. Em outras palavras, o Servidor de Rota do Azure não injetará esses prefixos na rede virtual e não será programado nas NICs de máquinas virtuais no hub ou VNets do spoke.
No entanto, o Servidor de Rota do Azure anunciará uma sub-rede maior do que o espaço de endereço da VNet que é aprendido com a NVA. É possível anunciar da NVA uma super-rede do que você tem em sua rede virtual. Por exemplo, se sua rede virtual usa o espaço de endereço RFC 1918 10.0.0.0/16, sua NVA poderá anunciar 10.0.0.0/8 para o Servidor de Rota do Azure e esses prefixos serão injetados nas VNets do hub e do spoke. Esse comportamento de VNet é referenciado em Sobre BGP com Gateway de VPN.
Importante
Se você tiver um cenário em que prefixos com o mesmo comprimento estão sendo anunciados do ExpressRoute e da NVA, o Azure preferirá e programará as rotas aprendidas com o ExpressRoute. Para obter mais informações, consulte a próxima seção.
Conectividade com o local por meio de gateways de rede virtual
Se um gateway de ExpressRoute ou VPN existir na mesma rede virtual que o Servidor de Rota e a NVA para fornecer conectividade a redes locais, as rotas aprendidas por esses gateways também serão programadas nas VNets do spoke. Essas rotas substituem a rota padrão (0.0.0.0/0) injetada pelo Servidor de Rota, pois elas seriam mais específicas (máscaras de rede mais longas). O diagrama a seguir descreve o design anterior, onde um gateway do ExpressRoute foi adicionado.
Você não pode configurar as sub-redes nas VNets do spoke para aprender apenas as rotas do Servidor de Rota do Azure. Desabilitar “Propagar rotas de gateway” em uma tabela de rotas associada a uma sub-rede impediria que os dois tipos de rotas (rotas do gateway de rede virtual e rotas do Servidor de Rota do Azure) fossem injetadas em NICs nessa sub-rede.
Por padrão, o Servidor de Rota também anuncia todos os prefixos aprendidos na NVA para ExpressRoute. Talvez isso não seja conveniente, por exemplo, devido aos limites de rota do ExpressRoute ou do próprio Servidor de Rota. Nesse caso, a NVA pode anunciar as rotas para o Servidor de Rota, incluindo a comunidade do BGP no-advertise (com o valor 65535:65282). Quando o Servidor de Rota recebe rotas com essa comunidade do BGP, ele as injeta nas sub-redes, mas não as anuncia para outros pares de BGP (como gateway de VPN ou ExpressRoute ou outras NVAs).
Coexistência do SDWAN com o ExpressRoute e o Firewall do Azure
Um caso específico do design anterior consiste em quando os clientes inserem o Firewall do Azure no fluxo de tráfego, para inspecionar todo o tráfego direcionado para as redes locais, usando o ExpressRoute ou os dispositivos SD-WAN/VPN. Nessa situação, todas as sub-redes spoke têm tabelas de rotas que impedem que os spokes aprendam as rotas do ExpressRoute ou do Servidor de Rota e tenham rotas padrão (0.0.0.0/0) com o Firewall do Azure como próximo salto, conforme mostrado no diagrama a seguir:
A sub-rede do Firewall do Azure aprende as rotas provenientes do ExpressRoute e da NVA VPN/SDWAN e decide se o tráfego será enviado 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 Rota, deverá enviar as rotas do BGP marcadas com a comunidade do BGP no-advertise. Dessa forma, os prefixos SDWAN não serão injetados de volta no local por meio do Express-Route.
Simetria de tráfego
Se várias instâncias de NVA forem usadas no cenário ativo/ativo para melhorar a resiliência ou escalabilidade, a simetria de tráfego será um requisito se as NVAs precisarem manter o estado das conexões. Isso é, por exemplo, o caso dos Firewalls da Próxima Geração.
- Para conectividade das máquinas virtuais do Azure com a Internet pública, a NVA usará a SNAT (conversão de endereços de rede de origem) para que o tráfego de saída seja originado do endereço IP público da NVA, obtendo, dessa forma, 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 DNAT (conversão de endereços de rede de destino), as NVAs exigirão a SNAT (conversão de endereços de rede de origem) para garantir que o tráfego de retorno das máquinas virtuais fique na mesma instância de NVA que processou o primeiro pacote.
- Para conectividade do Azure para o Azure, como a máquina virtual de origem assumirá a decisão de roteamento independentemente do destino, a SNAT é atualmente necessária para obter a simetria do tráfego.
Várias instâncias de 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 Rota do Azure injetará apenas a rota preferencial nas máquinas virtuais de VNet, e a rota menos preferencial será usada somente quando a instância DE NVA primária parar de anunciar pelo BGP.
Diferentes Servidores de Rota para anunciar as rotas para os Gateways de Rede Virtual e as VNets
Como as seções anteriores mostraram, o Servidor de Rota do Azure tem duas funções:
- Aprende e anuncia as rotas de/para gateway de rede virtual (VPN e ExpressRoute)
- Isso configura as rotas aprendidas em sua VNet e nas VNets emparelhadas diretamente
Em geral, essa funcionalidade dupla é interessante, mas às vezes pode ser desfavorável para determinados requisitos. Por exemplo, se o Servidor de Rota for implantado em uma VNet com uma NVA que anuncia a rota 0.0.0.0/0 e prefixos de publicidade de gateway do ExpressRoute no local, ele configurará todas as rotas (a 0.0.0.0.0/0 da NVA e os prefixos locais) nas máquinas virtuais em sua VNet e nas VNets emparelhadas diretamente. Como consequência, como os prefixos locais serão mais específicos do que 0.0.0.0/0/0, o tráfego entre o local e o Azure ignorará a NVA. Se isso não for desejado, as seções anteriores deste artigo mostraram como desabilitar a propagação de BGP nas sub-redes de 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 outro por interagir com o roteamento de rede virtual. O diagrama a seguir mostra um possível design para esse caso:
O Servidor de Rota 1 no hub é usado para injetar os prefixos de SDWAN no ExpressRoute. Como as VNets spoke são emparelhadas com a VNet do hub sem a configuração Usar o gateway da rede virtual remota ou o Servidor de Rota (no emparelhamento da VNet spoke) e Usar o gateway ou o Servidor de Rota dessa rede virtual (Trânsito de gateway no emparelhamento da VNet do hub), as VNets spoke não aprendem essas rotas (nem os prefixos SDWAN e os prefixos do ExpressRoute).
Para propagar rotas para as VNets do spoke, a NVA usa o Servidor de Rota 2, implantado em uma nova VNet auxiliar. A NVA propagará apenas uma única rota 0.0.0.0/0 para o Servidor de Rota 2. Como as VNets spoke são emparelhadas com essa VNet auxiliar com a configuração Usar o gateway da rede virtual remota ou o Servidor de Rota (no emparelhamento da VNet spoke) e Usar o gateway ou o Servidor de Rota dessa rede virtual (Trânsito de gateway no emparelhamento da VNet do hub), a rota 0.0.0.0/0 será aprendida por todas as máquinas virtuais nos spokes.
O próximo salto para a rota 0.0.0.0/0 é a NVA, portanto, as VNets do spoke ainda precisam ser emparelhadas com a VNet do hub. Outro aspecto importante a ser observado é que a VNet do hub precisa ser emparelhada com a VNet em que o Servidor de Rota 2 foi implantado. Caso contrário, ela não poderá criar a adjacência de BGP.
Se o tráfego do ExpressRoute para as VNets do spoke for enviado para uma NVA de firewall para inspeção, uma tabela de rotas no GatewaySubnet ainda será necessária. Caso contrário, o gateway da rede virtual do ExpressRoute enviará pacotes para as máquinas virtuais usando as rotas aprendidas com o emparelhamento VNet. As rotas nessa tabela de rotas devem corresponder aos prefixos spoke, e o próximo salto deve ser o endereço IP da NVA do firewall (ou o balanceador de carga na frente das NVAs do firewall, para redundância). A NVA do firewall pode ser igual à NVA de SDWAN no diagrama acima ou pode ser um dispositivo diferente, como Firewall do Azure, já que a 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:
Observação
Para qualquer tráfego do local destinado a pontos de extremidade privados, esse tráfego ignorará a NVA do Firewall ou o Firewall do Azure no hub. No entanto, isso resulta em um roteamento assimétrico (que pode levar à perda de conectividade entre os pontos de extremidade privados e locais), pois os Pontos de Extremidade Privados encaminham o tráfego local para o Firewall. Para garantir a simetria do roteamento, ative Políticas de rede da tabela de roteamento para pontos de extremidade privados nas sub-redes em que os pontos de extremidade privados estão implantados.
Esse design permite a injeção automática de rotas em VNets de spoke sem interferência de outras rotas aprendidas no ExpressRoute, VPN ou ambiente SDWAN e a adição de NVAs de firewall para inspeção de tráfego.