Usar o Firewall do Azure para rotear uma topologia multihub e spoke

A topologia hub-and-spoke é um padrão de arquitetura de rede comum no Azure que consolida recursos de rede e centraliza serviços de rede. Essa topologia fornece conectividade de rede e segurança para redes virtuais implantadas em diferentes assinaturas ou locatários.

Você pode implementar arquiteturas hub-and-spoke de duas maneiras:

• Hub e spoke autogerenciado (tradicional): você mantém controle total sobre as redes virtuais do hub e a configuração de roteamento.
• WAN Virtual: A Microsoft gerencia as redes virtuais do hub e simplifica a administração por meio de recursos como intenção de roteamento e políticas de roteamento.

Este artigo se concentra em topologias hub-and-spoke autogerenciadas onde você tem visibilidade e controle totais sobre a rede virtual do hub e a implantação do Firewall do Azure.

Você pode reduzir a sobrecarga de administração de uma implementação hub-and-spoke autogerenciada usando o Azure Virtual Network Manager (AVNM). O AVNM pode automatizar a configuração das Tabelas de Rotas do Azure, mas o design geral e as técnicas não mudam em comparação com a abordagem manual. O conteúdo deste artigo aplica-se caso utilize o AVNM ou configure manualmente a sua topologia hub-and-spoke autogerida.

Uma alternativa às Tabelas de Rotas do Azure nas redes virtuais spoke é injetar rotas em sub-redes com o Servidor de Rotas do Azure, conforme documentado em Injeção de rota padrão em redes virtuais spoke . No entanto, esse padrão não é comumente usado devido à complexidade que pode surgir da interação entre o Servidor de Rota do Azure e gateways de rede virtual VPN ou ExpressRoute.

Em uma configuração de hub-and-spoke autogerenciada:

• Hub: uma rede virtual que serve como ponto de conectividade central para sua rede local por meio de VPN, Rota Expressa ou Software-Defined Wide Area Network (SD-WAN). Dispositivos de segurança de rede, como firewalls, são implantados na rede virtual do hub.
• Spokes: Redes virtuais que fazem par com o hub e hospedam suas cargas de trabalho.

Para cargas de trabalho distribuídas por várias regiões, normalmente implanta-se um hub por cada região para agregar o tráfego dos ramos nessa região. O diagrama a seguir mostra uma arquitetura hub-and-spoke autogerenciada de duas regiões com duas redes virtuais spoke em cada região:

Arquitetura de hub-and-spoke de uma única região

Para entender o design de várias regiões, primeiro você precisa entender os conceitos de região única. O diagrama a seguir mostra a configuração da tabela de roteamento para a primeira região:

Considere os requisitos de roteamento para cada fluxo de tráfego potencial no design de região única para entender a configuração de rota definida pelo usuário:

• Tráfego entre spokes: os spokes não são emparelhados entre si, e o emparelhamento de rede virtual não é transitivo. Cada coneção sabe como encaminhar para a rede virtual do hub por predefinição, mas não para outras coneções. Uma rota aplicada 0.0.0.0/0 a todas as sub-redes faladas cobre o tráfego falado.
• Tráfego de ramificações para a internet: A rota na 0.0.0.0/0 tabela de rotas de ramificações também abrange o tráfego enviado para a internet pública. Esta rota sobrescreve, por padrão, a rota do sistema incluída em sub-redes públicas. Para obter mais informações, consulte Acesso de saída padrão no Azure.
• Tráfego Internet-para-satélite: o tráfego da internet para o satélite geralmente passa primeiro pelo Firewall do Azure. O Firewall do Azure tem regras de DNAT (Tradução de Endereço de Rede de Destino) configuradas, que também traduzem o endereço IP de origem (Tradução de Endereço de Rede de Origem ou SNAT). As cargas de trabalho spoke veem o tráfego como proveniente da sub-rede do Firewall do Azure. O emparelhamento de rede virtual cria rotas do sistema para o hub (10.1.0.0/24), para que os spokes saibam como encaminhar o tráfego de retorno.
• Tráfego local-para-satélite e satélite-para-local: Considere cada direção separadamente:
  • Tráfego do local para spoke: o tráfego é encaminhado da rede no local para os gateways VPN ou ExpressRoute. Com o roteamento padrão no Azure, uma rota do sistema é criada na GatewaySubnet (e outras sub-redes na rede virtual do hub) para cada spoke. Você deve substituir essas rotas de sistema e definir o próximo salto para o endereço IP privado do Azure Firewall. Neste exemplo, você precisa de duas rotas em uma tabela de rotas associada à sub-rede do gateway, uma para cada spoke (10.1.1.0/24 e 10.1.2.0/24). Usar um sumário como 10.1.0.0/16 que engloba todas as redes virtuais de conexão não funciona porque as rotas do sistema injetadas pelos pares de rede virtual na sub-rede do gateway são mais específicas (/24 em comparação com o /16 sumário). Esta tabela de rotas deve ter a alternância Propagate gateway routes habilitada (definida como Sim), caso contrário, o roteamento de gateway pode se tornar imprevisível.
  • Tráfego entre ramificações e locais internos: Os emparelhamentos de rede virtual entre o hub e os raios devem ter Permitir Trânsito de Gateway habilitado no lado do hub e Usar Gateways Remotos habilitado no lado do raio. Essas configurações são necessárias para que os gateways VPN e ExpressRoute anunciem os prefixos spoke através do Border Gateway Protocol (BGP) para redes no local. Essas configurações também fazem com que os porta-vozes aprendam os prefixos anunciados do local para o Azure por padrão. Como os prefixos nas instalações locais são mais específicos do que a rota 0.0.0.0/0 definida pelo usuário na tabela de rotas dos spokes, o tráfego dos spokes para as instalações locais passaria o firewall por padrão. Para evitar essa situação, defina o alternador Propagate Gateway Routes como No na tabela de rotas spoke para que os prefixos no local não sejam aprendidos e a rota seja usada para o 0.0.0.0/0 tráfego para o local.

Você pode gerenciar a tabela de rotas associada às sub-redes spoke e a tabela de rotas associada à sub-rede do gateway usando o Gerenciador de Rede Virtual do Azure para reduzir a sobrecarga administrativa. Para obter mais informações, consulte Usar o Firewall do Azure como o próximo salto.

Cargas de trabalho do hub da rede virtual

Se você implantar cargas de trabalho na rede virtual do hub (como controladores de domínio do Ative Directory, servidores DNS ou outra infraestrutura compartilhada), isso aumentará a complexidade do design hub-and-spoke. Recomendamos que você evite colocar cargas de trabalho no hub e, em vez disso, implante-as em um spoke dedicado para serviços compartilhados.

Esta seção descreve a configuração necessária para cargas de trabalho de hub para que você possa avaliar se essa complexidade é aceitável para suas necessidades. Também descrevemos um erro comum que pode causar tráfego assimétrico e quedas de pacotes.

O diagrama a seguir mostra um design de região única com uma sub-rede de carga de trabalho na rede virtual do hub:

O detalhe crítico é que as rotas configuradas pelo utilizador na sub-rede do gateway e nas sub-redes spoke são definidas para a sub-rede específica de carga de trabalho e não para todo o prefixo da rede virtual do hub:

• Configuração da sub-rede do gateway: configurar uma rota na sub-rede do gateway para toda a rede virtual do hub (10.1.0.0/24 neste exemplo) substitui a rota do sistema para a rede virtual do hub. Isso faz com que o tráfego de controle intra-sub-rede entre os gateways VPN ou ExpressRoute seja enviado para o firewall, potencialmente interrompendo a operação do gateway.
• Configuração da sub-rede Spoke: A configuração de uma rota nas sub-redes spoke para toda a rede virtual do hub (10.1.0.0/24 neste exemplo) substitui a rota do sistema criada pelo emparelhamento com a rede virtual do hub. Todo o tráfego enviado para o hub seria redirecionado para o Azure Firewall, incluindo o tráfego originado do próprio Azure Firewall, como o tráfego da Internet para o spoke, que passa pela Tradução de Endereço de Rede de Origem (SNAT). Essa configuração introduz tráfego assimétrico e causa quedas de pacotes.

Inspeção de tráfego entre sub-redes

Na configuração atual, o tráfego entre os spokes é enviado para o firewall, mas o tráfego intra-spoke permanece dentro da rede virtual spoke e é controlado usando Grupos de Segurança de Rede. Esse design considera as redes virtuais como um limite de segurança: o firewall inspeciona apenas o tráfego que sai ou entra em uma rede virtual.

Para inspecionar o tráfego entre sub-redes na mesma rede virtual spoke, modifique a tabela de rotas associada às sub-redes spoke conforme mostrado no diagrama a seguir:

No diagrama anterior, duas sub-redes spoke são introduzidas em cada rede virtual spoke, e as tabelas de rotas para os spokes na rede virtual A2 são descritas. O envio de tráfego entre sub-redes para o firewall requer que cada sub-rede tenha uma tabela de rotas separada, pois as rotas a serem instaladas em cada sub-rede são diferentes.

Para a sub-rede A21, você precisa destas duas rotas extras:

• Rota para 10.1.2.0/24: Substitui a rota do sistema para tráfego dentro da rede virtual. Sem outras rotas, todo o tráfego de rede intravirtual é enviado para o Firewall do Azure, até mesmo o tráfego entre máquinas virtuais na mesma sub-rede.
• Rota para 10.1.2.0/26 com o próximo salto Rede Virtual: uma exceção à rota anterior, portanto, o tráfego dentro dessa sub-rede específica não é enviado para o firewall, mas é roteado localmente dentro da rede virtual. Essa rota é específica para cada sub-rede, e é por isso que você precisa de uma tabela de rotas separada para cada sub-rede.

SD-WAN dispositivos virtuais de rede

Se você usar SD-WAN Network Virtual Appliances (NVAs) em vez de gateways VPN ou ExpressRoute, o design será semelhante, conforme mostrado no diagrama a seguir:

Há diferentes formas de integrar SD-WAN NVAs na Azure. Para obter mais informações, consulte integração SD-WAN com topologias de rede hub-and-spoke do Azure. Este artigo mostra a integração usando o Azure Route Server, um dos métodos mais comuns para rotear tráfego para redes SD-WAN. Os SD-WAN NVAs anunciam os prefixos locais para o Azure Route Server via BGP. O Azure Route Server injeta esses prefixos na sub-rede do Firewall do Azure para que o Firewall do Azure tenha informações de roteamento para redes locais. Os spokes não aprendem os prefixos on-premises porque a opção "Propagar rotas de gateway" está desativada na tabela de rotas do spoke.

Se você não quiser configurar o prefixo de cada rede virtual spoke na tabela de rotas associada à sub-rede NVA, você pode colocar os SD-WAN NVAs em sua rede virtual dedicada. A rede virtual NVA não aprende os prefixos spoke porque eles não estão diretamente emparelhados, e uma rota de resumo é possível, conforme mostrado no diagrama a seguir:

Arquitetura de hub-and-spoke multirregional

Depois de compreender como o tráfego funciona numa região única de hub-and-spoke, estender o design para uma arquitetura de várias regiões é mais fácil. O diagrama a seguir mostra um design de rede atualizado com hubs em duas regiões (A e B):

A única adição à configuração são as tabelas de rotas associadas às sub-redes do Firewall do Azure em cada região. Cada rede virtual de hub conhece apenas os prefixos das redes virtuais diretamente interligadas, portanto, não há roteamento para os prefixos de filiais remotas. Adicione rotas definidas pelo usuário para cada sub-rede do Firewall do Azure para que o tráfego de cada região seja roteado para o Firewall do Azure correspondente.

Neste exemplo, cada região pode ser facilmente resumida:

• A região A contém prefixos em 10.1.0.0/16
• A região B contém prefixos em 10.2.0.0/16

Definir endereços IP em cada região que são facilmente resumidos torna sua configuração de roteamento mais simples. Caso contrário, você precisa criar uma rota para cada fala remota.

Habilite Propagar rotas de gateway na tabela de rotas de sub-rede do Firewall do Azure para que o firewall possa aprender rotas locais de gateways VPN e ExpressRoute.

Para simplificar o gerenciamento de rotas definidas pelo usuário em um ambiente de várias regiões, você pode usar o Gerenciador de Rede Virtual do Azure. Para obter mais informações, consulte Gerenciar rotas definidas pelo usuário em várias topologias hub-and-spoke com o AVNM.

Próximos passos

• Saiba como implantar e configurar um Firewall do Azure.