Migrar para a WAN Virtual do Azure

O Azure WAN Virtual permite que as empresas simplifiquem a conectividade global para beneficiarem da escala da rede global da Microsoft. Este artigo fornece detalhes técnicos para empresas que pretendem migrar de uma topologia hub-and-spoke gerida pelo cliente existente, para um design que tira partido dos hubs de WAN Virtual geridos pela Microsoft.

Para obter informações sobre os benefícios que o Azure WAN Virtual permite às empresas adotarem uma rede global empresarial moderna centrada na cloud, veja Arquitetura de rede de trânsito global e WAN Virtual.

: Azure WAN Virtual

O modelo de conectividade hub-and-spoke do Azure foi adotado por milhares de nossos clientes para tirar partido do comportamento de encaminhamento transitivo predefinido da Rede do Azure para criar redes cloud simples e dimensionáveis. O Azure WAN Virtual baseia-se nestes conceitos e introduz novas capacidades que permitem topologias de conectividade global, não só entre localizações no local e o Azure, mas também permitir que os clientes tirem partido da escala da rede Microsoft para aumentar as redes globais existentes.

Este artigo mostra como migrar um ambiente hub-and-spoke gerido pelo cliente existente para uma topologia baseada no Azure WAN Virtual.

Scenario

A Contoso é uma organização financeira global com escritórios na Europa e na Ásia. Estão a planear mover as aplicações existentes de um datacenter no local para o Azure e criaram um design de base baseado na arquitetura hub-and-spoke gerida pelo cliente, incluindo redes virtuais do hub regional para conectividade híbrida. Como parte da mudança para tecnologias baseadas na cloud, a equipa de rede foi encarregada de garantir que a conectividade está otimizada para a empresa avançar.

A figura seguinte mostra uma vista de alto nível da rede global existente, incluindo a conectividade a várias regiões do Azure.

Contoso: topologia de rede existente da Contoso

Os seguintes pontos podem ser compreendidos a partir da topologia de rede existente:

• Uma topologia hub-and-spoke é utilizada em múltiplas regiões, incluindo circuitos do ExpressRoute para conectividade de volta a uma Rede De Área Larga (WAN) privada comum.

• Alguns destes sites também têm túneis VPN diretamente no Azure para aceder às aplicações alojadas na cloud.

Requisitos

A equipa de rede foi incumbida de fornecer um modelo de rede global que pode suportar a migração da Contoso para a cloud e tem de otimizar as áreas de custo, dimensionamento e desempenho. Em resumo, os seguintes requisitos devem ser cumpridos:

• Forneça o trimestre principal (QG) e as sucursais com o caminho otimizado para aplicações alojadas na cloud.
• Remova a dependência dos datacenters no local (DC) existentes para terminação de VPN, mantendo os seguintes caminhos de conectividade:
  • Branch-to-VNet: os escritórios ligados à VPN têm de conseguir aceder às aplicações migradas para a cloud na região local do Azure.
  • Branch-to-Hub to Hub-to-VNet: os escritórios ligados à VPN têm de conseguir aceder às aplicações migradas para a cloud na região remota do Azure.
  • Ramo a ramo: os escritórios ligados à VPN regional têm de conseguir comunicar entre si e os sites HQ/DC ligados ao ExpressRoute.
  • Branch-to-Hub to Hub-to-branch: os escritórios ligados à VPN separados globalmente têm de conseguir comunicar entre si e com quaisquer sites hq/DC ligados ao ExpressRoute.
  • Branch-to-Internet: os sites ligados têm de conseguir comunicar com a Internet. Este tráfego tem de ser filtrado e registado.
  • VNet a VNet: as redes virtuais spoke na mesma região têm de conseguir comunicar entre si.
  • VNet-to-Hub para Hub-to-VNet: as redes virtuais spoke nas diferentes regiões têm de conseguir comunicar entre si.
• Forneça a capacidade para os utilizadores de roaming da Contoso (portátil e telemóvel) acederem aos recursos da empresa enquanto não estão na rede empresarial.

Arquitetura de WAN Virtual do Azure

A figura seguinte mostra uma vista de alto nível da topologia de destino atualizada com o Azure WAN Virtual para cumprir os requisitos detalhados na secção anterior.

Figura : arquitetura de WAN Virtual do Azure

Resumo:

• O HQ na Europa continua ligado ao ExpressRoute, o DC no local da Europa está totalmente migrado para o Azure e agora desativado.
• Asia DC e HQ permanecem ligados à WAN Privada. O Azure WAN Virtual agora utilizado para aumentar a rede da operadora local e fornecer conectividade global.
• Os hubs WAN Virtual do Azure implementados nas regiões europa ocidental e Sudeste Asiático do Azure para fornecer hub de conectividade para dispositivos ligados ao ExpressRoute e VPN.
• Os hubs também fornecem a terminação de VPN para utilizadores de roaming em vários tipos de cliente através da conectividade OpenVPN à rede de malha global, permitindo o acesso não só a aplicações migradas para o Azure, mas também a quaisquer recursos restantes no local.
• Conectividade à Internet para recursos numa rede virtual fornecida pelo Azure WAN Virtual.

A conectividade à Internet para sites remotos também é fornecida pelo Azure WAN Virtual. Fuga de internet local suportada através da integração de parceiros para acesso otimizado a serviços SaaS, como o Microsoft 365.

Migrar para WAN Virtual

Esta secção mostra os vários passos para migrar para o Azure WAN Virtual.

Passo 1: Hub-and-spoke gerido pelo cliente de uma região única

A seguinte figura mostra uma topologia de região única para a Contoso antes da implementação do Azure WAN Virtual:

Figura 1: hub-and-spoke manual de região única

De acordo com a abordagem hub-and-spoke, a rede virtual do hub gerido pelo cliente contém vários blocos de funções:

• Serviços partilhados (qualquer função comum exigida por múltiplos spokes). Exemplo: a Contoso utiliza controladores de domínio do Windows Server em máquinas virtuais Infraestrutura como serviço (IaaS).
• Os serviços de firewall de IP/Encaminhamento são fornecidos por uma aplicação virtual de rede de terceiros, ativando o encaminhamento IP da camada spoke-to-spoke-3.
• Serviços de entrada/saída da Internet, incluindo Gateway de Aplicação do Azure para pedidos HTTPS de entrada e serviços proxy de terceiros em execução em máquinas virtuais para acesso de saída filtrado aos recursos da Internet.
• Gateway de rede virtual do ExpressRoute e VPN para conectividade a redes no local.

Passo 2: Implementar hubs de WAN Virtual

Implementar um hub WAN Virtual em cada região. Configure o hub WAN Virtual com a funcionalidade VPN e ExpressRoute, conforme descrito nos seguintes artigos:

• Tutorial: Criar uma ligação site a site com a WAN Virtual do Azure
• Tutorial: Criar uma associação do ExpressRoute com o Azure WAN Virtual

Nota

O Azure WAN Virtual tem de utilizar o SKU Standard para ativar alguns dos caminhos de tráfego apresentados neste artigo.

Figura 2: Hub-and-spoke gerido pelo cliente para migração de WAN Virtual

Passo 3: ligar sites remotos (ExpressRoute e VPN) a WAN Virtual

Ligue o hub WAN Virtual aos circuitos do ExpressRoute existentes e configure VPNs site a site através da Internet a quaisquer ramos remotos.

Figure 3: Hub-and-spoke gerido pelo cliente à migração de WAN Virtual

Neste momento, os equipamentos de rede no local começarão a receber rotas que refletem o espaço de endereços IP atribuído à VNet do hub gerido WAN Virtual. Nesta fase, os ramos ligados à VPN remota verão dois caminhos para quaisquer aplicações existentes nas redes virtuais spoke. Estes dispositivos devem ser configurados para continuar a utilizar o túnel para o hub gerido pelo cliente para garantir o encaminhamento simétrico durante a fase de transição.

Passo 4: Testar a conectividade híbrida através de WAN Virtual

Antes de utilizar o hub de WAN Virtual gerido para conectividade de produção, recomendamos que configure uma rede virtual test spoke e WAN Virtual ligação À VNet. Valide se as ligações a este ambiente de teste funcionam através do ExpressRoute e da VPN Site a Site antes de continuar com os passos seguintes.

Figure 4: Hub-and-spoke gerido pelo cliente para migração de WAN Virtual

Nesta fase, é importante reconhecer que a rede virtual original gerida pelo cliente e o novo Hub WAN Virtual estão ligados ao mesmo circuito do ExpressRoute. Devido a isto, temos um caminho de tráfego que pode ser utilizado para permitir que os spokes em ambos os ambientes comuniquem. Por exemplo, o tráfego de um spoke anexado à rede virtual do hub gerido pelo cliente irá percorrer os dispositivos MSEE utilizados para o circuito do ExpressRoute para alcançar qualquer spoke ligado através de uma ligação VNet ao novo hub de WAN Virtual. Isto permite uma migração faseada de spokes no Passo 5.

Passo 5: Transição da conectividade para o hub da WAN virtual

Figura 5: hub-and-spoke gerido pelo cliente para migração de WAN Virtual

a. Elimine as ligações de peering existentes das redes virtuais Spoke para o antigo hub gerido pelo cliente. O acesso a aplicações em redes virtuais spoke não está disponível até que os passos a-c estejam concluídos.

b. Ligue as redes virtuais spoke ao hub de WAN Virtual através de ligações VNet.

c. Remova todas as rotas definidas pelo utilizador (UDR) utilizadas anteriormente em redes virtuais spoke para comunicações spoke-to-spoke. Este caminho está agora ativado pelo encaminhamento dinâmico disponível no hub WAN Virtual.

d. Os Gateways de ExpressRoute e VPN existentes no hub gerido pelo cliente estão agora desativados para permitir o próximo passo (e).

e. Ligue o antigo hub gerido pelo cliente (rede virtual do hub) ao hub de WAN Virtual através de uma nova ligação VNet.

Passo 6: Hub antigo torna-se serviços partilhados spoke

Redesenhámos agora a nossa rede do Azure para tornar o hub WAN Virtual o ponto central da nossa nova topologia.

: Hub-and-spoke gerido pelo cliente para WAN Virtual migração

Uma vez que o hub de WAN Virtual é uma entidade gerida e não permite a implementação de recursos personalizados, como máquinas virtuais, o bloco de serviços partilhados existe agora como uma rede virtual spoke e aloja funções como a entrada na Internet através de Gateway de Aplicação do Azure ou aplicação virtualizada de rede. O tráfego entre o ambiente dos serviços partilhados e as máquinas virtuais de back-end transita agora para o hub gerido WAN Virtual.

Passo 7: Otimizar a conectividade no local para utilizar totalmente WAN Virtual

Nesta fase, a Contoso concluiu principalmente as migrações de aplicações empresariais para a Microsoft Cloud, com apenas algumas aplicações legadas no DC no local.

Figure 7: Hub-and-spoke gerido pelo cliente para migração de WAN Virtual

Para tirar partido de todas as funcionalidades do Azure WAN Virtual, a Contoso decide desativar as ligações VPN no local legadas. Quaisquer ramos que continuem a aceder às redes HQ ou DC podem transitar a rede global da Microsoft através do encaminhamento de trânsito incorporado do Azure WAN Virtual.

Nota

O Alcance Global do ExpressRoute é necessário para os clientes que pretendem tirar partido do backbone da Microsoft para fornecer o ExpressRoute para o trânsito do ExpressRoute (não apresentado na Figura 7).

Arquitetura de estado final e caminhos de tráfego

Arquitetura Figura: Região dupla WAN Virtual

Esta secção fornece um resumo de como esta topologia cumpre os requisitos originais ao analisar alguns fluxos de tráfego de exemplo.

Caminho 1

O caminho 1 mostra o fluxo de tráfego de um ramo ligado da VPN S2S na Ásia para uma VNet do Azure na região Sudeste Asiático.

O tráfego é encaminhado da seguinte forma:

• O ramo Asiático está ligado através de túneis S2S BGP resilientes ativados para o Sudeste Asiático WAN Virtual hub.

• O hub da Ásia WAN Virtual encaminha o tráfego localmente para a VNet ligada.

Caminho 2

O caminho 2 mostra o fluxo de tráfego da Sede Europeia ligada ao ExpressRoute para uma VNet do Azure na região Sudeste Asiático.

O tráfego é encaminhado da seguinte forma:

• A HQ europeia está ligada através do circuito ExpressRoute ao hub de WAN Virtual europa ocidental.

• WAN Virtual conectividade global hub a hub permite o trânsito de tráfego para a VNet ligada na região remota.

Caminho 3

O caminho 3 mostra o fluxo de tráfego do DC no local da Ásia ligado à WAN Privada para um Ramo Ligado S2S europeu.

O tráfego é encaminhado da seguinte forma:

• A Asia DC está ligada à operadora da WAN Privada local.

• O circuito do ExpressRoute termina localmente na WAN Privada e liga-se ao hub de WAN Virtual sudeste asiático.

• WAN Virtual conectividade global hub a hub permite o trânsito de tráfego.

Caminho 4

O caminho 4 mostra o fluxo de tráfego de uma VNet do Azure na região Sudeste Asiático para uma VNet do Azure na região Europa Ocidental.

O tráfego é encaminhado da seguinte forma:

• WAN Virtual conectividade global hub a hub permite o trânsito nativo de todas as VNets do Azure ligadas sem mais configurações de utilizador.

Caminho 5

O caminho 5 mostra o fluxo de tráfego de utilizadores de VPN de roaming (P2S) para uma VNet do Azure na região Europa Ocidental.

O tráfego é encaminhado da seguinte forma:

• Os utilizadores de portáteis e dispositivos móveis utilizam o cliente OpenVPN para conectividade transparente no gateway de VPN P2S na Europa Ocidental.

• A Europa Ocidental WAN Virtual hub encaminha o tráfego localmente para a VNet ligada.

Segurança e controlo de políticas através de Azure Firewall

A Contoso validou agora a conectividade entre todos os ramos e VNets de acordo com os requisitos abordados anteriormente neste artigo. Para cumprirem os requisitos de controlo de segurança e isolamento de rede, têm de continuar a separar e registar o tráfego através da rede do hub. Anteriormente, esta função era executada por uma aplicação virtual de rede (NVA). A Contoso também quer desativar os serviços proxy existentes e utilizar serviços nativos do Azure para filtragem de Internet de saída.

Figure: Azure Firewall no WAN Virtual (Hub Virtual Seguro)

Os seguintes passos de alto nível são necessários para introduzir Azure Firewall nos hubs de WAN Virtual para ativar um ponto unificado de controlo de política. Para obter mais informações sobre este processo e o conceito de Hubs Virtuais Seguros, veja Gestor de Azure Firewall.

1. Criar Azure Firewall política.
2. Ligue a política de firewall ao hub WAN Virtual do Azure. Este passo permite que o hub de WAN Virtual existente funcione como um hub virtual seguro e implementa os recursos de Azure Firewall necessários.

Nota

Existem restrições relacionadas com a utilização de hubs virtuais protegidos, incluindo o tráfego entre regiões. Para obter mais informações, veja Gestor de Firewall – problemas conhecidos.

Os seguintes caminhos mostram os caminhos de conectividade ativados com os hubs virtuais protegidos pelo Azure:

Caminho 6

O caminho 6 mostra o fluxo de tráfego seguro entre VNets na mesma região.

O tráfego é encaminhado da seguinte forma:

• As Redes Virtuais ligadas ao mesmo Hub Virtual Seguro encaminham agora o tráfego para através do Azure Firewall.

• Azure Firewall pode aplicar política a estes fluxos.

Caminho 7

O caminho 7 mostra o fluxo de tráfego de uma VNet do Azure para a Internet ou serviço de segurança de terceiros.

O tráfego é encaminhado da seguinte forma:

• As Redes Virtuais ligadas ao Hub Virtual Seguro podem enviar tráfego para destinos públicos e na Internet, utilizando o Hub Seguro como ponto central de acesso à Internet.

• Este tráfego pode ser filtrado localmente com Azure Firewall regras FQDN ou enviado para um serviço de segurança de terceiros para inspeção.

Caminho 8

O caminho 8 mostra o fluxo de tráfego de ramo para Internet ou serviço de segurança de terceiros.

O tráfego é encaminhado da seguinte forma:

• Os ramos ligados ao Hub Virtual Seguro podem enviar tráfego para destinos públicos na Internet através do Hub Seguro como ponto central de acesso à Internet.

• Este tráfego pode ser filtrado localmente com Azure Firewall regras FQDN ou enviado para um serviço de segurança de terceiros para inspeção.

Passos seguintes

• Saiba mais sobre o Azure WAN Virtual.
• Configurar WAN Virtual para Azure NetApp Files