Topologia de rede hub-and-spoke

Este artigo explica como criar uma rede hub-and-spoke em Azure. Uma rede virtual do hub central hospeda serviços compartilhados enquanto redes virtuais de spoke isoladas hospedam cargas de trabalho individuais.

O que este artigo aborda

Este artigo aborda os serviços compartilhados da rede virtual de hub, o isolamento de spokes e os padrões de roteamento (padrão, emparelhamento direto e baseados em stamp). Também aborda o trânsito de gateway para conectividade híbrida e o escalonamento de topologias hub-spoke com o Gerenciador de Rede Virtual do Azure.

Quem precisa deste artigo

Leia este artigo se uma ou mais dessas condições se aplicarem:

• Você precisa de serviços de rede compartilhados, como firewall, DNS, Bastion, Gateway de VPN ou ExpressRoute para várias cargas de trabalho.
• Você deseja centralizar a inspeção de tráfego, o controle de roteamento ou a administração em vez de repetir esses serviços em todas as VNets.
• Você precisa de uma topologia repetível para separar os serviços compartilhados da plataforma das VNets de cargas de trabalho.
• Você quer comparar o modelo hub-and-spoke com outros modelos de transporte antes de padronizar sua topologia.

Se você tiver uma única carga de trabalho sem requisitos de serviço compartilhado, comece com uma topologia de rede simples .

Azure serviços e recursos

A tabela a seguir lista os Azure serviços e recursos que dão suporte a uma topologia hub-and-spoke:

Como funciona

Em uma topologia hub e spoke:

1. Uma rede virtual de hub atua como o ponto central da conectividade. Ele contém serviços de rede compartilhados, como firewall, gateway e host do Bastion.
2. Emparelhar as redes virtuais hub e spoke. Cada spoke hospeda uma carga de trabalho: um aplicativo, um ambiente de equipe ou um serviço isolado.
3. O emparelhamento VNet é não transitivo. Os spokes podem se conectar ao hub, mas não podem se comunicar diretamente entre si por meio do hub, a menos que você configure o roteamento ou o emparelhamento direto entre eles.

O que acontece na rede virtual do hub

Use a tabela a seguir para determinar quais serviços colocar em seu hub:

Layout da sub-rede do hub

Uma rede virtual de hub bem projetada normalmente inclui estas sub-redes:

Para obter diretrizes detalhadas de dimensionamento de sub-rede, consulte VNets e sub-redes.

Como escolher uma variante

Hub-and-spoke tem três variantes comuns. Escolha com base em seus requisitos de isolamento e comunicação:

Hub e spoke padrão

Essa variante é a mais comum. Todo o tráfego spoke-to-spoke passa pelo firewall do hub para inspeção. Os spokes se comunicam apenas por meio do hub, nunca diretamente.

Padrão de roteamento: Aplique uma UDR (rota definida pelo usuário) a cada sub-rede spoke com a rota padrão (0.0.0.0/0) apontando para o endereço IP privado do firewall do hub. Isso força todo o tráfego de saída, incluindo o tráfego entre spokes, a passar pelo firewall para registro e filtragem.

Limite de emparelhamento: Uma única rede virtual de hub dá suporte a até 500 conexões de emparelhamento (limite de plataforma padrão). Se você usar Gerenciador de Rede Virtual do Azure (AVNM) com uma configuração de conectividade hub-spoke, o limite aumentará para 1.000 spokes.

Hub e spoke com emparelhamento direto

Em algumas arquiteturas, pares específicos de spokes exigem comunicação de baixa latência sem passar pelo firewall do hub. Para esses casos, adicione o emparelhamento direto de VNet entre o par de spokes, ou use grupos conectados do AVNM.

Use o emparelhamento direto de spokes quando:

• Duas cargas de trabalho trocam dados de alta taxa de transferência (por exemplo, replicação de banco de dados entre spokes).
• A latência do salto pelo firewall é inaceitável em um caminho de dados específico.
• Você aceita que o tráfego com emparelhamento direto contorna a inspeção do firewall central.

Padrão de estampas (totalmente isolado)

O padrão Stamps é uma alternativa para cenários que exigem isolamento de raio de explosão estrito. Cada carga de trabalho é implantada em uma rede virtual totalmente independente sem hub e sem emparelhamento com outras cargas de trabalho.

Quando usar Selos:

• A conformidade regulatória não requer nenhum caminho de rede entre cargas de trabalho.
• SaaS com múltiplos clientes em que cada cliente tem uma infraestrutura independente.
• Isolamento máximo de falhas: uma falha em um carimbo não pode se propagar para outras pessoas.

Exemplo: isolamento de SaaS multitenant

Um provedor SaaS hospeda cada cliente corporativo em um carimbo dedicado. Cada carimbo contém sua própria VNet (10.x.0.0/16), gateway de aplicativo, camada de computação e banco de dados. Não existe emparelhamento de VNet entre os stamps, portanto, um NSG mal configurado ou uma carga de trabalho comprometida no stamp do Locatário A não consegue acessar os recursos do Locatário B pela rede. O provedor gerencia carimbos por meio de modelos do Azure Resource Manager e os implanta em grupos de recursos separados ou assinaturas separadas para grandes locatários. A troca de dados entre locatários, quando necessário, usa um namespace de Barramento de Serviço do Azure compartilhado. Cada stamp acessa este namespace por meio de endpoints privados.

Compensações:

• Nenhum serviço compartilhado. Cada stamp precisa de seu próprio firewall, gateway e host do Bastion (se necessário), o que aumenta os custos.
• Nenhuma comunicação entre cargas de trabalho em rede privada.
• A sobrecarga operacional aumenta porque você gerencia redes independentes em vez de infraestrutura centralizada.
• O custo aumenta linearmente com a contagem de selos porque a economia de serviço compartilhado não se aplica.

Se suas cargas de trabalho precisarem de serviços compartilhados ou comunicação entre cargas de trabalho, use a variante de hub e spoke padrão.

Padrões de comunicação spoke-to-spoke

Como o emparelhamento VNet é não transitivo, a comunicação spoke-to-spoke requer roteamento explícito. Esta seção explica como o tráfego flui entre spokes usando o firewall do hub.

Fluxo de tráfego: Spoke A para Spoke B por meio do firewall do hub

A sequência a seguir descreve como um pacote viaja de uma VM no Spoke A (10.1.0.4) para uma VM no Spoke B (10.2.0.4):

1. Spoke Uma VM envia um pacote destinado a 10.2.0.4. A tabela de rotas efetiva da VM contém uma UDR com 0.0.0.0/0 → 10.0.1.4 (o IP privado do Firewall do Azure).
2. O pacote atravessa o link de emparelhamento da VNet da Spoke A para a VNet do hub. O peering permite que o tráfego chegue à sub-rede do firewall.
3. Firewall do Azure recebe o pacote em sua interface interna. Ele avalia o pacote em relação às regras de rede e às regras de aplicativo na ordem de prioridade.
4. Se uma regra permitir o fluxo, o firewall encaminha o pacote para 10.2.0.4. O pacote cruza o link de emparelhamento hub aSpoke-B.
5. A VM spoke B recebe o pacote. O tráfego de retorno segue o mesmo caminho no sentido inverso. A UDR do Spoke B envia a resposta de volta por meio do firewall.

Configurando as tabelas de roteamento

Aplique estas tabelas de rotas para habilitar o padrão anterior:

1. Crie uma tabela de rotas para sub-redes de spoke. Desative a propagação de rotas BGP se quiser impedir que as rotas do ambiente local substituam suas UDRs.
2. Adicione uma rota padrão (0.0.0.0/0) com o tipo VirtualAppliance de próximo salto e o endereço do próximo salto definido como o IP privado Firewall do Azure.
3. Associe a tabela de rotas a cada sub-rede de spoke que precise acessar outros spokes ou a internet.
4. Crie regras de firewall de rede que permitam o tráfego específico entre spokes. Por exemplo, permitir 10.1.0.0/16 → 10.2.0.0/16 nas portas 443 e 1433.

Alternativa: grupos conectados ao AVNM para conexão spoke-to-spoke direta

Se você não precisar de inspeção de firewall entre spokes específicos, os grupos conectados a AVNM fornecerão um modelo de conectividade de malha. Os spokes no mesmo grupo conectado se comunicam diretamente sem atravessar o hub. Isso reduz a latência e os requisitos de capacidade de processamento do firewall, mas contorna a inspeção centralizada.

Trânsito de gateway

O trânsito via gateway permite que todos os spokes compartilhem um único gateway de VPN ou gateway do ExpressRoute implantado no hub. Sem o trânsito do gateway, cada spoke precisa de seu próprio gateway para acessar redes locais.

Etapas de configuração

1. Implante um gateway VPN ou ExpressRoute no hub GatewaySubnet.
2. Na conexão de emparelhamento do hub (hub → spoke): habilite Permitir o trânsito do gateway.
3. Na conexão de emparelhamento no lado do spoke (spoke → hub): habilite Usar gateways remotos.
4. Verifique a propagação de rotas. Após a configuração, verifique as rotas efetivas na NIC de uma máquina virtual spoke. A tabela de rotas mostra os prefixos do ambiente local aprendidos por meio do gateway do hub, com tipo de próximo salto VNetGlobalPeering ou VNetPeering.

Quando configuradas, as rotas aprendidas pelo gateway de hub (por exemplo, prefixos locais do ExpressRoute) são propagadas automaticamente para tabelas de roteamento spoke.

Limitações de tráfego do gateway

• O trânsito do gateway funciona com todas as camadas do Gateway de VPN, exceto a camada Básica. Se você usar o Gateway de VPN Básico, não poderá compartilhá-lo com redes virtuais emparelhadas.
• Uma rede virtual spoke pode usar apenas um gateway remoto. Você não pode habilitar Use remote gateways em um spoke que emparelhe com vários hubs.
• Se você usar UDRs para forçar o tráfego por meio do firewall, verifique se a UDR não substitui as rotas locais propagadas pelo gateway sem querer. Defina rotas mais específicas para prefixos locais, se necessário.

Gerenciador de Rede Virtual do Azure em grande escala

Quando seu ambiente cresce além de um punhado de spokes, o gerenciamento de conexões de emparelhamento e tabelas de rotas manualmente se torna complexo. O AVNM fornece automação para topologias hub-spoke:

O AVNM é especialmente valioso quando você gerencia topologias hub-spoke em várias regiões ou precisa de associação dinâmica à medida que novas redes virtuais spoke entram online.

Considerações de dimensionamento

À medida que a topologia hub-spoke cresce, planeje os seguintes limites de plataforma e padrões organizacionais:

Limites de emparelhamento e conectividade

Organização da assinatura

• Separe as redes spoke em assinaturas específicas para cada carga de trabalho para ambientes com mais de 10 redes spoke. Isso isola a cobrança, o RBAC e os limites de cotas por equipe responsável pela carga de trabalho.
• Use uma assinatura de conectividade dedicada para a VNet do hub, os gateways e o firewall. Esse é o padrão recomendado pelas landing zones do Azure (assinatura da plataforma).
• Agrupe assinaturas em um grupo de gerenciamento para que o AVNM possa descobrir e gerenciar dinamicamente VNets spoke em várias assinaturas usando condições do Azure Policy.

Aplicando topologia com o Azure Policy

Use a Política do Azure para evitar desvios de configuração:

• Negar pareamento para VNets que não são de hub. Atribua uma política no nível do grupo de gerenciamento para bloquear a criação de emparelhamento de VNet, a menos que o destino seja a VNet de hub designada.
• Exigir associação UDR. Atribua uma política que audite (ou negue) sub-redes de spoke sem uma tabela de rotas que inclua a rota 0.0.0.0/0 → Firewall.
• Impor a participação no grupo AVNM. Use regras de associação dinâmica na AVNM com base em marcas (por exemplo, NetworkRole:Spoke) para que novas VNets sejam registradas automaticamente.

Caminho de migração de simples para hub-spoke

Se você começou com uma topologia de rede simples e seu ambiente cresceu para exigir serviços compartilhados ou segmentação entre cargas de trabalho, siga este caminho de migração:

Etapa 1: Planejar a VNet do hub

1. Aloque um novo espaço de endereço para o hub (por exemplo, 10.0.0.0/16) que não se sobreponha à sua VNet plana existente.
2. Determine quais serviços compartilhados implantar: firewall, gateway, Bastion, resolvedor DNS.
3. Tamanho das sub-redes do hub de acordo com a tabela de layout da sub-rede do hub .

Etapa 2: Implantar serviços compartilhados no hub

1. Crie a VNet do hub e implante Firewall do Azure (ou sua NVA escolhida).
2. Implante o gateway VPN/ExpressRoute se precisar de conectividade híbrida.
3. Implante Azure Bastion para acesso seguro à VM.
4. Configure o Resolvedor de DNS Privado se estiver usando DNS personalizado.

Etapa 3: Migrar cargas de trabalho para spokes

1. Crie VNets spoke com novos espaços de endereço para cada carga de trabalho. Se você não puder alterar os endereços IP, poderá manter as faixas de IP existentes, desde que não se sobreponham ao hub.
2. Conecte cada spoke ao hub. Habilite o trânsito do gateway no lado do hub e use gateways remotos no lado do spoke.
3. Aplique UDRs às sub-redes de spoke com a rota padrão apontando para o firewall do hub.
4. Mova ou reimplante VMs e serviços da VNet plana para o spoke adequado. Use o Azure Resource Mover ou a reimplantação, dependendo da complexidade da carga de trabalho.
5. Crie regras de firewall para permitir os padrões de tráfego entre spoke e spoke para a Internet que você permitiu anteriormente dentro da VNet simples.

Etapa 4: Descomissionar a VNet plana

1. Verifique se todas as cargas de trabalho podem ser acessadas por meio da nova topologia hub-spoke.
2. Atualize os registros DNS se os endereços IP privados forem alterados.
3. Remova a VNet simples antiga depois de migrar e validar todo o tráfego.

Quando considerar a WAN Virtual em vez disso

Se a topologia hub-spoke estiver se tornando mais complexa, avalie se o WAN Virtual do Azure é a opção mais adequada:

Para obter uma comparação detalhada, consulte WAN Virtual do Azure topologia.

Considerações sobre o design

Pré-requisitos

Antes de criar uma rede hub-and-spoke:

• Conclua seu plano de rede virtual e sub-rede. Saiba de quantas ramificações você precisa e quais sub-redes cada ramificação requer.
• Defina seu esquema de endereço IP. Os espaços de endereço "hub" e "spoke" não devem se sobrepor.
• Entenda que o emparelhamento de VNet não é transitivo: as redes spoke não herdam conectividade com outras redes spoke por meio do hub.

Considerações de segurança

Uma topologia em hub-and-spoke centraliza a aplicação de políticas de segurança no hub. Aplique estes princípios:

• Encaminhar todo o tráfego das redes spoke pelo firewall do hub. Use UDRs com a rota padrão apontando para o firewall. Essa configuração garante que o firewall inspecione e registre logs em todos os fluxos spoke-to-spoke e spoke-to-internet.
• Use NSGs nas sub-redes spoke como defesa em profundidade. Mesmo com um firewall central, os grupos de segurança de rede em sub-redes spoke fornecem uma camada extra de segmentação. Negar tráfego lateral inesperado no nível da sub-rede. Para obter diretrizes de design do NSG, consulte grupos de segurança de rede e grupos de segurança de aplicativos.
• Habilite o trânsito do gateway com cuidado. O trânsito pelo gateway expõe as rotas do ambiente local a todas as redes spoke. Verifique se as regras de firewall contemplam a conectividade ampliada.
• Remova os IPs públicos das VMs de spoke. Azure Bastion no hub fornece acesso de gerenciamento seguro sem expor VMs à Internet.
• Trate cada spoke como um limite de segurança. As cargas de trabalho em spokes diferentes permanecem isoladas por padrão. A conectividade entre os spokes requer regras explícitas de roteamento e firewall.

Artigos relacionados

• Topologia de rede simples: para cargas de trabalho individuais que não precisam de serviços compartilhados
• Topologia do WAN Virtual do Azure: para o roteamento gerenciado e a conectividade em escala
• Rede de várias regiões: para cargas de trabalho que abrangem várias regiões Azure
• VNets e sub-redes: dimensionamento de sub-redes para componentes do hub
• Planejamento de endereços IP: planejamento CIDR para hub e ramificações
• Grupos de segurança de rede e grupos de segurança de aplicativos: defesa em profundidade em sub-redes de spoke

Saiba mais

• Topologia de rede Hub-spoke no Azure
• Emparelhamento de rede virtual
• Visão geral do Firewall do Azure
• Visão geral do Gerenciador de Rede Virtual do Azure
• Trânsito de Gateway de VPN para emparelhamento
• Emparelhamento VNet e Azure Bastion

Próximas Etapas