Usar o Firewall do Azure para rotear uma topologia multi-hub e spoke

A topologia hub-and-spoke é um padrão comum de arquitetura de rede no Azure que consolida os recursos de rede e centraliza os 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 autogerenciada (tradicional): você mantém controle total sobre as redes virtuais 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 roteamento de intenção e políticas de roteamento.

Este artigo se concentra em topologias de hub e spoke autogerenciadas em que você tem total visibilidade e controle 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 de hub e spoke autogerenciada usando o AVNM (Azure Virtual Network Manager). O AVNM pode automatizar a configuração das Tabelas de Rotas do Azure, mas o design geral e as técnicas não são alterados em comparação com a abordagem manual. O conteúdo deste artigo se aplica tanto ao uso do AVNM quanto à configuração manual da sua topologia hub e spoke autogerenciada.

Uma alternativa às Tabelas de Rotas do Azure nas redes virtuais spoke é injetar rotas em sub-redes com o Servidor de Rota do Azure, conforme documentado na 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 Rotas do Azure e gateways de rede virtual VPN ou ExpressRoute.

Em uma configuração hub e spoke autogerenciada:

• Hub: uma rede virtual que serve como o ponto de conectividade central para sua rede local por meio de VPN, ExpressRoute 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 emparelhamento com o hub e hospedam suas cargas de trabalho.

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

Arquitetura hub e 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 de spoke para spoke: as spokes não estão emparelhadas entre si e o emparelhamento de redes virtuais não é transitivo. Cada spoke sabe como rotear para a rede virtual hub por padrão, mas não para outras spokes. Uma rota para 0.0.0.0/0 aplicada a todas as sub-redes spoke abrange o tráfego de spoke para spoke.
• Tráfego de spoke para a Internet: a rota 0.0.0.0/0 na tabela de rotas spoke também abrange o tráfego enviado à Internet pública. Essa rota sobrescreve a rota do sistema que é incluída, por padrão, nas sub-redes públicas. Para obter mais informações, consulte Acesso de saída padrão no Azure.
• Tráfego de internet para spoke: o tráfego da Internet para o spoke geralmente passa primeiro pelo Firewall do Azure. O Firewall do Azure tem regras de DNAT (Conversão de Endereços de Rede de Destino) configuradas, o que também converte o endereço IP de origem (Conversão de Endereços 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 redes virtuais cria rotas de sistema para o hub (10.1.0.0/24), para que as spokes saibam como rotear o tráfego de retorno.
• Tráfego local para spoke e tráfego spoke para local: considere cada direção separadamente:
  • Tráfego local para spoke: o tráfego chega da rede local aos gateways VPN ou ExpressRoute. Com o roteamento padrão no Azure, uma rota de sistema é criada na GatewaySubnet (e em 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 Firewall do Azure. Neste exemplo, você precisa de duas rotas em uma tabela de rotas associada à sub-rede de gateway, uma para cada spoke (10.1.1.0/24 e 10.1.2.0/24). Usar um resumo como 10.1.0.0/16 que abranja todas as redes virtuais spoke não funciona porque as rotas de sistema injetadas pelos emparelhamentos de redes virtuais na sub-rede de gateway são mais específicas (/24 em comparação com o resumo /16). Essa tabela de rotas deve ter a alternância propagar rotas de gateway habilitadas (definida como Sim), caso contrário, o roteamento de gateway pode se tornar imprevisível.
  • Tráfego spoke para local: os emparelhamentos de redes virtuais entre hub e spokes devem ter Permitir Trânsito de Gateway habilitado no lado do hub e Usar Gateways Remotos habilitado no lado da spoke. Essas configurações são obrigatórias para que os gateways VPN e ExpressRoute anunciem os prefixos de spoke por meio do Border Gateway Protocol (BGP) para redes locais. Essas configurações também fazem com que as spokes aprendam os prefixos anunciados de locais para o Azure por padrão. Como os prefixos locais são mais específicos do que a rota 0.0.0.0/0 definida pelo usuário na tabela de rotas spoke, o tráfego de spokes para o local ignoraria o firewall por padrão. Para evitar essa situação, defina o botão Propagar Rotas do Gateway como Não na tabela de rotas spoke, para que os prefixos locais não sejam aprendidos e a rota 0.0.0.0/0 seja usada para o tráfego 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 de rede virtual do hub

Se você implantar cargas de trabalho na rede virtual do hub (como controladores de domínio do Active 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 uma spoke dedicada 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 seus requisitos. 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 usuário 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 de rede virtual do hub:

• Configuração da sub-rede do gateway: configurar uma rota na sub-rede de 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 dentro da sub-rede entre os gateways VPN ou ExpressRoute seja enviado para o firewall, o que pode interromper a operação do gateway.
• Configuração da sub-rede spoke: configurar uma rota nas sub-redes spoke para toda a rede virtual do hub (10.1.0.0/24 neste exemplo) substitui a rota de sistema criada pelo emparelhamento com a rede virtual do hub. Todo o tráfego enviado ao hub seria enviado ao Firewall do Azure, incluindo o tráfego originado no próprio Firewall do Azure, como o tráfego de internet para a spoke que passa por Conversão de Endereço de Rede de Origem (SNAT). Essa configuração introduz o 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 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 spokes na rede virtual A2 são descritas. Enviar tráfego entre sub-redes para o firewall requer que cada sub-rede tenha uma tabela de rotas separada porque as rotas a serem instaladas em cada sub-rede são diferentes.

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

• Rota para 10.1.2.0/24: substitui a rota de sistema para o tráfego intrarrede virtual. Sem outras rotas, todo o tráfego de rede intra-virtual é 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 próximo salto Rede Virtual: exceção à rota anterior, portanto, o tráfego dentro desta sub-rede específica não é enviado para o firewall, mas sim 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 NVAs (Dispositivos Virtuais de Rede) em vez de gateways VPN ou ExpressRoute, o design será semelhante, conforme mostrado no diagrama a seguir:

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

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

Arquitetura hub e spoke multirregional

Depois de entender como o tráfego funciona em uma única região hub e spoke, estender o design para uma arquitetura multirregional é simples. 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 emparelhadas, portanto, não há roteamento para os prefixos de spokes remotas. Adicione rotas definidas pelo usuário para cada sub-rede do Firewall do Azure para que o tráfego para 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ê precisará criar uma rota para cada spoke remota.

Habilite Propagar rotas do gateway na tabela de rotas da sub-rede do Firewall do Azure para que o firewall possa aprender as 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, confira Gerenciar rotas definidas pelo usuário em várias topologias hub e spoke com AVNM.

Próximas etapas

• Aprenda a implantar e configurar um Firewall do Azure.