Topologia de rede WAN Virtual do Azure

Este artigo explica como desenhar uma rede com WAN Virtual do Azure. WAN Virtual fornece infraestrutura de hub gerida por Microsoft com roteamento automático, integração nativa SD-WAN e trânsito global integrado entre hubs.

O que este artigo aborda

Este artigo aborda a arquitetura do hub da WAN Virtual, o encaminhamento automático e a propagação de rotas, a comparação entre Basic e Standard, a intenção de encaminhamento para inspeção de tráfego, os padrões de integração SD-WAN e o modelo de custos da WAN Virtual.

Quem precisa deste artigo

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

  • Necessita de trânsito gerido entre várias filiais, instalações, utilizadores remotos ou redes virtuais conectadas.
  • Pretende o encaminhamento gerido pela Microsoft e a conectividade das filiais, em vez de criar e operar pelos seus próprios meios um hub de trânsito à medida.
  • Tem de comparar o WAN Virtual do Azure com o hub-and-spoke antes de optar por uma topologia.
  • Espera que a sua rede cresça para além de um pequeno número de bordas de conectividade geridas manualmente.

Dica

Seguir um percurso do cenário? Selecione o seu cenário no topo da página para obter orientação personalizada. As orientações principais que se seguem aplicam-se a todos os leitores.

Foco em levantar e deslocar: Evite este artigo para uma migração padrão de elevação e deslocação. A maioria dos ambientes lift-and-shift tem menos de 30 ligações de ramais e opera em uma ou duas regiões. Uma topologia tradicional hub-and-spoke com Gateway de VPN proporciona conectividade suficiente. Considere a WAN Virtual apenas se tiver várias filiais ou planear uma expansão rápida.

Foco na modernização: Este artigo torna-se relevante quando o seu programa de modernização inclui requisitos de trânsito à escala de sucursais ou multirregião. A arquitetura hub-and-spoke dupla com gateways de VPN em cada região dá resposta à maioria dos cenários de modernização. A WAN Virtual torna-se relevante quando se ultrapassa a complexidade de encaminhamento que a gestão manual de UDRs pode suportar.

Foco multinuvem: A WAN Virtual é o modelo de trânsito recomendado quando existem várias nuvens privadas virtuais (VPC), filiais, regiões ou extremidades da nuvem. A WAN Virtual serve como equivalente do Azure ao AWS Transit Gateway, proporcionando gestão centralizada de roteamento e conectividade em grande escala. Se estiver a migrar de um ambiente AWS que usa Transit Gateway, a WAN Virtual mapeia diretamente para esse modelo.

Serviços e funcionalidades do Azure

A tabela seguinte lista os serviços e funcionalidades do Azure que suportam uma topologia WAN Virtual:

Serviço ou funcionalidade Função na WAN Virtual Saiba mais
WAN Virtual do Azure Fornece a rede global de transporte gerida e a infraestrutura central Visão geral da WAN Virtual
Hub virtual Rede virtual gerida pela Microsoft que aloja serviços de encaminhamento e de gateway Roteamento virtual de hub
Gateway de VPN (no hub) Conectividade VPN entre sites e de ponto a site para filiais WAN Virtual Gateway de VPN
ExpressRoute Gateway (no hub) Conectividade privada de centros de dados locais por meio de circuitos ExpressRoute WAN Virtual ExpressRoute
Azure Firewall Manager Gestão centralizada de políticas de segurança para Hubs Virtuais Seguros Visão geral do Firewall Manager
Intenção de encaminhamento Direção automática de tráfego através de uma solução de segurança sem tabelas de rotas personalizadas Intenção de roteamento

Como funciona

Diagrama que mostra uma topologia de WAN Virtual com dois hubs regionais, redes virtuais spoke, sites de filial ligados através de VPN e circuitos ExpressRoute. O encaminhamento entre hubs é efetuado através da rede de backbone da Microsoft.

Numa topologia de WAN Virtual:

  1. Um recurso WAN Virtual atua como o contentor de topo que agrupa um ou mais hubs virtuais entre regiões.
  2. Cada hub virtual é uma rede virtual gerida pela Microsoft. O hub contém endpoints de serviço para VPN, ExpressRoute e serviços de firewall. Não implementas nem geres diretamente a rede virtual do hub.
  3. As redes virtuais spoke ligam-se ao hub virtual através de ligações VNet (semelhantes ao peering na topologia hub-spoke tradicional). O router do hub virtual trata de todo o encaminhamento automaticamente.
  4. Os sites de sucursal ligam-se por VPN site a site ou gateways ExpressRoute implementados no hub virtual.
  5. Quando implementa múltiplos hubs, estes interligam-se automaticamente através da backbone da Microsoft, que permite o trânsito global sem encaminhamento gerido pelo cliente.

Roteamento de hub virtual

O router do hub virtual gere todo o encaminhamento entre redes virtuais conectadas, ramais e outros hubs. Principais comportamentos:

  • Trânsito automático: Redes virtuais ligadas ao mesmo hub podem comunicar sem UDRs. O router de hub propaga rotas entre todas as conexões por defeito.
  • Trânsito inter-hub: As rotas propagam-se automaticamente entre hubs na mesma WAN Virtual. O tráfego entre regiões flui através da espinha dorsal da Microsoft.
  • Tabelas de rota: Para cenários avançados de isolamento (como isolar o desenvolvimento da produção), pode criar tabelas de rotas personalizadas dentro do hub para controlar a propagação da rota.
  • Débito agregado: O router do hub virtual suporta até 50 Gbps de débito agregado quando configurado com 50 unidades máximas de infraestrutura de encaminhamento. A implementação padrão utiliza 2 unidades de infraestrutura de encaminhamento (3 Gbps). Pode aumentar a capacidade de processamento aumentando o número de unidades de infraestrutura de encaminhamento nas definições do concentrador.

Note

O encaminhamento automático aplica-se à conectividade de trânsito predefinida. Cenários personalizados que encaminham o tráfego através de appliances virtuais de rede (NVAs) no hub podem requerer tabelas de rotas personalizadas.

Como escolher

Esta secção ajuda-o a selecionar a topologia e o nível certos para o seu ambiente.

Hub-spoke comparado com WAN Virtual

Utilize esta tabela para determinar se uma topologia tradicional hub-spoke ou a WAN Virtual é a opção certa para o seu ambiente:

Fator Hub-and-spoke (tradicional) WAN Virtual do Azure
Gestão Rede virtual hub gerida pelo cliente Infraestrutura hub gerida pela Microsoft
Melhor para Até ~30 ligações VPN de filial 30+ filiais VPN ou muitas regiões do Azure
Roteamento O cliente configura UDRs para tráfego spoke-to-spoke Roteamento automático no hub virtual
SD-WAN integração Implementação e configuração manual do NVA Integração nativa de parceiros SD-WAN
Trânsito global Requer encaminhamento inter-regional gerido pelo cliente Integrado: todos os concentradores interligam-se automaticamente
Modelo de custos Recursos do Hub VNet pagos separadamente (Firewall, Gateway, Bastion) Preços por unidade de implantação e por unidade de escala

Dica

A WAN Virtual é uma alternativa de escala ao hub-spoke, não uma substituição. Organizações com menos de 30 sucursais, uma única região e com necessidade de controlo total sobre os recursos do hub devem utilizar uma topologia tradicional hub-and-spoke.

Considerações sobre a migração: Se estiver a migrar de uma arquitetura tradicional em hub-and-spoke para a WAN Virtual, planeie uma migração com execução paralela. Implemente um hub da WAN Virtual juntamente com o hub existente, migre gradualmente as ligações dos spokes e valide o encaminhamento após a migração de cada ligação. A WAN Virtual não suporta a importação de configurações UDR existentes, por isso é necessário redesenhar o encaminhamento para usar o modelo de propagação automática do router hub.

Quando manter a topologia hub-spoke: Escolha a topologia hub-spoke tradicional se precisar de controlo granular sobre a rede virtual do hub (por exemplo, implementando NVAs personalizadas diretamente na sub-rede do hub), se a sua organização operar apenas numa única região com menos de 10 filiais, ou se os requisitos de conformidade exigirem uma infraestrutura de encaminhamento gerida pelo cliente.

Standard comparado com o nível Básico

O WAN Virtual oferece dois níveis. Escolha o nível que se adeque às suas necessidades de roteamento e conectividade:

Feature Básico Standard
VPN de site para site ✅ ✅
VPN de ponto a site ❌ ✅
ExpressRoute ❌ ✅
Trânsito VNet-para-VNet ❌ ✅
Trânsito entre hubs ❌ ✅
Azure Firewall in hub ❌ ✅
NVA no concentrador ❌ ✅

Importante

Podes fazer upgrade do nível Básico para o Standard, mas não podes fazer downgrade do Standard para o Basic. Escolha Standard se precisar de roteamento de trânsito, conectividade ExpressRoute ou integração de segurança.

Modelo de custo

A WAN Virtual utiliza preços baseados em unidades que difere dos tradicionais hub-spoke:

  • Unidades de implantação (hub): Paga-se uma taxa por hora pelo próprio centro virtual. Esta taxa é um custo fixo para a infraestrutura do hub gerido.
  • Unidades de escala (gateways): Os gateways VPN e ExpressRoute são faturados com base no número de unidades de escala que fornece. Mais unidades de escala aumentam proporcionalmente a capacidade de largura de banda e o custo.
  • Unidades de infraestrutura de encaminhamento: O router do hub é faturado por cada unidade de infraestrutura de encaminhamento. A implementação padrão inclui duas unidades (3 Gbps). Podes escalar até 50 unidades (50 Gbps) para ambientes de alta produtividade.
  • Processamento de dados: Paga-se pelos dados processados através do hub, incluindo VNet-para-VNet, branch-to-VNet e tráfego inter-hub. O tráfego ligado à internet encaminhado através do Azure Firewall tem encargos de processamento de dados separados.
  • Suplemento do Hub Virtual Seguro: Quando implementa o Azure Firewall através do Firewall Manager, os encargos padrão do Azure Firewall também se aplicam aos custos do hub da WAN Virtual.

Compare os custos face a uma topologia tradicional hub-and-spoke. Para implantações pequenas com ramificações mínimas, um hub gerido pelo cliente pode ser mais rentável. Para um número elevado de filiais (30+), a automação e a infraestrutura gerida da WAN Virtual normalmente compensam o preço unitário. Para preços detalhados, consulte conceitos de preços da WAN Virtual.

Hub Virtual Seguro: quando usar o Gestor de Firewalls

Um Hub Virtual Seguro integra o Azure Firewall (ou um NVA suportado) com o Gestor de Firewalls para políticas centralizadas:

Configuração Utilizar quando Benefício
Centro Virtual Padrão (sem firewall) Apenas conectividade entre filial e VNet, segurança gerida ao nível de cada spoke Implementação mais simples, custo mais baixo
Hub Virtual Seguro com Gestor de Firewall Inspeção centralizada de tráfego para tráfego privado e de internet Política consistente e intenção de encaminhamento eliminam a necessidade de UDRs
Hub Virtual Seguro com parceiro NVA Investimento existente em firewalls de terceiros, requisitos de funcionalidades específicas Utilizar ferramentas e conhecimentos já existentes dos fornecedores

Intenção de encaminhamento

A intenção de roteamento simplifica o controlo do tráfego no WAN Virtual, ao encaminhar automaticamente o tráfego por uma solução de segurança (Azure Firewall ou uma NVA suportada), sem tabelas de rotas personalizadas nem UDRs.

Quando ativa a intenção de roteamento, declara políticas para dois tipos de tráfego:

  • Tráfego na Internet: Todo o tráfego ligado à internet proveniente de redes virtuais ligadas passa pela solução de segurança no hub.
  • Tráfego privado: Todo o tráfego entre redes virtuais, ramais e outros hubs passa pela solução de segurança.

A intenção de roteamento elimina a necessidade de gerir tabelas de roteamento manualmente. O plano de controlo da WAN Virtual configura automaticamente todas as rotas necessárias em todos os hubs ligados e em todas as redes virtuais spoke.

Note

A intenção de roteamento requer um Hub Virtual Seguro com Azure Firewall ou um parceiro NVA suportado. Só está disponível no nível Standard.

Warning

As modificações da tabela de roteamento que a intenção de roteamento faz são irreversíveis. Podes remover a intenção de roteamento, mas removê-la não restaura automaticamente a tua configuração predefinida do RouteTable anterior. Guarda um instantâneo da tua configuração antes de ativares a intenção de roteamento, porque precisas de restaurar manualmente quaisquer rotas anteriores caso as removas mais tarde.

Limites de ligação e escalabilidade

A WAN Virtual suporta implementações em larga escala:

  • Até 1.000 ligações VPN site-to-site por hub virtual.
  • Múltiplos hubs por WAN Virtual (um por região, ou vários por região para isolamento).
  • Até 50 Gbps de débito agregado por router de hub (requer, no máximo, 50 unidades de infraestrutura de encaminhamento. A predefinição é 2 unidades de 3 Gbps).
  • Conectividade entre quaisquer pontos em todas as ligações de VNet, filiais VPN e circuitos ExpressRoute no mesmo hub.

Para organizações que excedam os limites de um único hub, implemente hubs adicionais na mesma ou em regiões diferentes. A WAN Virtual gere automaticamente o encaminhamento entre hubs.

SD-WAN integração de parceiros

WAN Virtual proporciona integração nativa com SD-WAN dispositivos parceiros. Dispositivos parceiros podem:

  • Exportar a informação do dispositivo de ramo para o Azure de forma programática.
  • Descarregue automaticamente a configuração do Azure.
  • Estabelecer conectividade IPsec/IKE ao hub virtual sem necessidade de configuração manual.

Esta automatização reduz, à escala, o tempo de implementação de ramificações de dias para minutos. Para a lista atual de parceiros suportados, veja WAN Virtual partners.

Como funciona a automação de parceiros

Os parceiros de SD-WAN utilizam a API de automatização da conectividade da WAN Virtual para gerir programaticamente os ciclos de vida dos dispositivos das filiais:

  • Registo de dispositivos: O controlador parceiro regista dispositivos de ramificação com o recurso WAN Virtual, incluindo metadados do dispositivo e requisitos de largura de banda.
  • Download de configuração: A plataforma parceira puxa a configuração do hub gateway (endereços IP, chaves pré-partilhadas, definições BGP) sem interação manual com portais.
  • Estabelecimento do túnel: O dispositivo parceiro estabelece túneis IPsec para o gateway VPN do hub virtual usando a configuração descarregada.
  • Monitorização contínua do estado: A plataforma parceira monitoriza o estado dos túneis e pode restabelecer a ligação se os túneis falharem.

Parceiros como VMware SD-WAN, Fortinet SD-WAN, Cisco Viptella e Versa Networks suportam este modelo de automação. Cada parceiro implementa a sua própria camada de orquestração sobre a API WAN Virtual. Avalie capacidades específicas de cada parceiro, como encaminhamento com reconhecimento da aplicação, otimização do tráfego e saída local para a Internet, antes de selecionar um parceiro.

Considerações de design

Para a maioria das migrações lift-and-shift, a WAN Virtual não é a topologia inicial. Avalie quando se torna justificado:

  • Quando a WAN Virtual se torna justificada. Se a sua infraestrutura lift-and-shift incluir mais de 30 sites de filial, abranger três ou mais regiões do Azure, ou exigir integração com SD-WAN, o encaminhamento automatizado da WAN Virtual reduz a sobrecarga operacional em comparação com a gestão de UDRs em vários emparelhamentos hub-and-spoke.
  • A topologia hub-and-spoke é suficiente para infraestruturas mais pequenas. Um único hub com Gateway de VPN suporta até 30 ligações site-to-site e 500 peerings de spokes. Se a sua migração se mantiver dentro destes limites, o modelo hub-spoke tradicional é mais simples e económico.
  • Existe um caminho de migração. Se começar com uma topologia hub-spoke e, mais tarde, precisar de WAN Virtual, pode migrar ao implementar um hub da WAN Virtual juntamente com o hub existente e mover gradualmente as ligações spoke.

Implementações multirregional não requerem automaticamente WAN Virtual. Avalie a complexidade de encaminhamento:

  • Uma topologia hub-and-spoke dupla costuma ser suficiente. Para arquiteturas ativas-ativas de duas regiões, implemente um hub em cada região com emparelhamento de VNet entre os hubs. Este padrão lida com a maioria dos cenários de modernização sem a sobrecarga de preços por unidade da WAN Virtual.
  • Quando a complexidade leva à WAN Virtual. Se a sua modernização ultrapassar duas regiões, adicionar conectividade de sucursais entre regiões ou exigir propagação automática de rotas entre centros sem gestão manual de UDR, a WAN Virtual simplifica as operações.
  • Não confundas multirregião com WAN Virtual. A decisão de usar WAN Virtual depende do número de branchs, do número de regiões e da complexidade do encaminhamento. A multirregião sozinha não é justificação suficiente.

A WAN Virtual fornece o equivalente em Azure ao AWS Transit Gateway para trânsito centralizado e escalável:

  • Equivalência do Transit Gateway. O hub virtual da WAN Virtual funciona como o AWS Transit Gateway: encaminha automaticamente o tráfego entre redes virtuais conectadas, filiais e túneis VPN cross-cloud. Se estás a migrar da AWS, este mapeamento simplifica a tradução da tua arquitetura.
  • Hub virtual seguro (Secure Virtual Hub). Implemente o Azure Firewall através do Firewall Manager no hub virtual. Ative a intenção de roteamento para direcionar todo o tráfego privado e da internet através do firewall. Isto proporciona uma inspeção centralizada do tráfego cross-cloud que entra no Azure.
  • Ligações VPN para Google Cloud e AWS. Crie ligações VPN site-to-site do hub WAN Virtual para o Google Cloud VPN (HA VPN) e os AWS Virtual Private Gateways. A WAN Virtual suporta até 1.000 ligações VPN por hub, proporcionando espaço para crescimento à medida que migra mais cargas de trabalho.
  • Planeamento multirregional. Implemente hubs virtuais em cada região do Azure onde as aplicações migradas aterram. O encaminhamento inter-hub é propagado automaticamente pela rede principal da Microsoft, à semelhança do modelo de peering do Transit Gateway na AWS.

Pré-requisitos

Antes de implementar uma topologia WAN Virtual:

  • Compreender os conceitos de hub-and-spoke. A WAN Virtual baseia-se no modelo hub-spoke. Consulte a topologia hub-and-spoke para compreender os conceitos fundamentais.
  • Faça o inventário dos locais das suas agências. Documente o número de ramos, a sua distribuição geográfica e a conectividade atual (VPN, MPLS, SD-WAN).
  • Defina a sua estratégia regional. Determina quais as regiões do Azure que alojam cargas de trabalho e onde precisas de hubs virtuais.
  • Escolhe o teu nível. Decida entre Basic (apenas VPN site-to-site) e Standard (trânsito completo, ExpressRoute, firewall) com base na tabela comparativa de níveis neste artigo.
  • Avalie os requisitos de segurança. Determine se a inspeção centralizada (Hub Virtual Seguro) ou a segurança por raio é adequada.

Considerações de segurança

  • Centro Virtual Seguro. Implemente o Azure Firewall através do Firewall Manager para aplicar políticas de segurança consistentes em todas as redes virtuais e branches conectadas. O Firewall Manager fornece gestão centralizada de regras em múltiplos hubs seguros.
  • Intenção de roteamento. Ative a intenção de roteamento para direcionar automaticamente o tráfego privado e da internet através da sua solução de segurança. Esta abordagem impede que o tráfego contorne a inspeção ao eliminar a configuração manual do encaminhamento.
  • Limitações do NVA-in-hub. Os appliances virtuais de rede implementados no hub têm capacidades diferentes do Azure Firewall. Verifique a paridade de funcionalidades com os seus requisitos de segurança antes de escolher um parceiro NVA.
  • Modelo de segurança da SD-WAN. Quando integra dispositivos parceiros de SD-WAN, a segurança do tráfego depende da implementação do parceiro. Avalie as capacidades de encriptação, autenticação e inspeção de tráfego do parceiro.
  • Isolamento de tráfego entre centros. O tráfego entre hubs virtuais flui pela espinha dorsal da Microsoft e não atravessa a internet pública. A rede backbone é uma rede privada, mas o tráfego não é cifrado na camada de rede por defeito. Use TLS na camada de aplicação para dados sensíveis entre regiões.

Saiba mais

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Conectividade híbrida: Ligue as suas cargas de trabalho migradas de volta às instalações locais através do Gateway de VPN ou ExpressRoute.

Próximo passo na sua jornada de modernização:

Planifique a sua implementação em várias regiões: Expanda a sua arquitetura por várias regiões para obter resiliência ativo-ativo.

A seguir na sua jornada através da cloud:

Desenhe os seus VNets da zona de aterragem Azure: Construa a base da rede virtual do Azure para as suas cargas de trabalho ligadas e migradas.

  • Last updated on