Migrar para a WAN Virtual do Azure

A WAN Virtual do Azure permite que as empresas simplifiquem a sua conectividade global para beneficiarem da escala da rede global da Microsoft. Este artigo fornece detalhes técnicos para empresas que desejam migrar de uma topologia hub-and-spoke gerenciada pelo cliente existente para um design que aproveita hubs WAN virtuais gerenciados pela Microsoft.

Para obter informações sobre os benefícios que a WAN Virtual do Azure permite para empresas que adotam uma rede global empresarial moderna centrada na nuvem, consulte Arquitetura de rede de trânsito global e WAN Virtual.

Figura: WAN Virtual do Azure

O modelo de conectividade hub-and-spoke do Azure foi adotado por milhares de nossos clientes para aproveitar o comportamento de roteamento transitivo padrão da Rede do Azure para criar redes de nuvem simples e escaláveis. A WAN Virtual do Azure baseia-se nestes conceitos e introduz novas capacidades que permitem topologias de conectividade global, não só entre localizações locais e o Azure, mas também permitindo que os clientes tirem partido da escala da rede Microsoft para aumentar as suas redes globais existentes.

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

Cenário

A Contoso é uma organização financeira global com escritórios na Europa e na Ásia. Eles estão planejando mover seus aplicativos existentes de um data center local para o Azure e criaram um design básico baseado na arquitetura hub-and-spoke gerenciada pelo cliente, incluindo redes virtuais de hub regional para conectividade híbrida. Como parte da mudança para tecnologias baseadas em nuvem, a equipe de rede foi encarregada de garantir que sua conectividade seja otimizada para o negócio no futuro.

A figura a seguir mostra uma exibição de alto nível da rede global existente, incluindo conectividade com várias regiões do Azure.

Figura: topologia de rede existente da Contoso

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

• Uma topologia hub-and-spoke é usada em várias regiões, incluindo circuitos de Rota Expressa para conectividade com uma WAN (Wide Area Network) privada comum.

• Alguns desses sites também têm túneis VPN diretamente no Azure para alcançar aplicativos hospedados na nuvem.

Requisitos

A equipe de rede foi encarregada de fornecer um modelo de rede global que possa dar suporte à migração da Contoso para a nuvem e deve otimizar nas áreas de custo, escala e desempenho. Em resumo, devem ser cumpridos os seguintes requisitos:

• Forneça à sede (HQ) e filiais um caminho otimizado para aplicativos hospedados na nuvem.
• Remova a dependência de centros de dados (DC) locais existentes para terminação VPN, mantendo os seguintes caminhos de conectividade:
  • Branch-to-VNet: os escritórios conectados à VPN devem ser capazes de acessar aplicativos migrados para a nuvem na região local do Azure.
  • Branch-to-Hub to Hub-to-VNet: escritórios conectados por VPN devem ser capazes de acessar aplicativos migrados para a nuvem na região remota do Azure.
  • Filial-a-filial: Os escritórios regionais conectados à VPN devem ser capazes de se comunicar entre si e com os sites HQ/DC conectados à Rota Expressa.
  • Branch-to-Hub to Hub-to-branch: escritórios conectados VPN separados globalmente devem ser capazes de se comunicar entre si e com qualquer site HQ/DC conectado à Rota Expressa.
  • Ramificação para Internet: Os sites conectados devem ser capazes de se comunicar com a Internet. Esse tráfego deve ser filtrado e registrado.
  • VNet-to-VNet: Redes virtuais faladas na mesma região devem ser capazes de se comunicar entre si.
  • VNet-to-Hub to Hub-to-VNet: As redes virtuais spoke nas diferentes regiões devem ser capazes de se comunicar entre si.
• Forneça a capacidade para os usuários móveis da Contoso (laptop e telefone) acessarem os recursos da empresa enquanto não estiverem na rede corporativa.

Arquitetura WAN Virtual do Azure

A figura a seguir mostra uma exibição de alto nível da topologia de destino atualizada usando a WAN Virtual do Azure para atender aos requisitos detalhados na seção anterior.

Figura: Arquitetura WAN Virtual do Azure

Resumo:

• A sede na Europa permanece conectada à Rota Expressa, o DC local da Europa é totalmente migrado para o Azure e agora desativado.
• Asia DC e HQ permanecem conectados à WAN privada. A WAN Virtual do Azure agora é usada para aumentar a rede da operadora local e fornecer conectividade global.
• Hubs WAN Virtual do Azure implantados nas regiões do Azure da Europa Ocidental e Sudeste Asiático para fornecer hub de conectividade para dispositivos conectados à Rota Expressa e VPN.
• Os Hubs também fornecem terminação VPN para usuários em roaming em vários tipos de cliente usando a conectividade OpenVPN para a rede mesh global, permitindo o acesso não apenas aos aplicativos migrados para o Azure, mas também a quaisquer recursos que permaneçam no local.
• Conectividade com a Internet para recursos dentro de uma rede virtual fornecida pela WAN Virtual do Azure.

Conectividade com a Internet para sites remotos também fornecida pela WAN Virtual do Azure. Breakout de internet local suportado via integração de parceiros para acesso otimizado a serviços SaaS, como o Microsoft 365.

Migrar para WAN Virtual

Esta seção mostra as várias etapas para migrar para a WAN Virtual do Azure.

Etapa 1: Hub e spoke gerenciados pelo cliente em uma única região

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

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

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

• Serviços partilhados (qualquer função comum requerida por vários porta-vozes). Exemplo: a Contoso usa controladores de domínio do Windows Server em máquinas virtuais IaaS (infraestrutura como serviço).
• Os serviços de firewall IP/Roteamento são fornecidos por um dispositivo virtual de rede de terceiros, permitindo o roteamento IP de camada 3 de raio a raio.
• Serviços de entrada/saída da Internet, incluindo o Gateway de Aplicativo do Azure para solicitações HTTPS de entrada e serviços de proxy de terceiros em execução em máquinas virtuais para acesso de saída filtrado a recursos da Internet.
• ExpressRoute e gateway de rede virtual VPN para conectividade com redes locais.

Etapa 2: Implantar hubs WAN virtuais

Implante 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 de Rota Expressa usando a WAN Virtual do Azure

Figura 2: Migração de hub-and-spoke gerenciada pelo cliente para WAN virtual

Etapa 3: Conectar sites remotos (ExpressRoute e VPN) à WAN Virtual

Conecte o hub WAN Virtual aos circuitos de Rota Expressa existentes e configure VPNs site a site pela Internet para qualquer filial remota.

Figura 3: Migração de hub-and-spoke para WAN virtual gerenciada pelo cliente

Neste ponto, o equipamento de rede local começará a receber rotas que reflitam o espaço de endereço IP atribuído à VNet do hub gerenciado pela WAN Virtual. As filiais remotas conectadas à VPN neste estágio verão dois caminhos para quaisquer aplicativos existentes nas redes virtuais faladas. Esses dispositivos devem ser configurados para continuar a usar o túnel para o hub gerenciado pelo cliente para garantir o roteamento simétrico durante a fase de transição.

Etapa 4: Testar a conectividade híbrida via WAN Virtual

Antes de usar o hub WAN virtual gerenciado para conectividade de produção, recomendamos que você configure uma rede virtual test spoke e uma conexão VNet WAN virtual. Valide se as conexões com esse ambiente de teste funcionam via ExpressRoute e Site to Site VPN antes de continuar com as próximas etapas.

Figura 4: Migração de hub-and-spoke gerenciado pelo cliente para WAN virtual

Neste estágio, é importante reconhecer que tanto a rede virtual original do hub gerenciado pelo cliente quanto o novo Hub WAN Virtual estão conectados ao mesmo circuito de Rota Expressa. Devido a isso, temos um caminho de tráfego que pode ser usado para permitir que os raios em ambos os ambientes se comuniquem. Por exemplo, o tráfego de um spoke conectado à rede virtual do hub gerenciado pelo cliente atravessará os dispositivos MSEE usados para o circuito ExpressRoute para chegar a qualquer spoke conectado por meio de uma conexão VNet ao novo hub WAN Virtual. Isso permite uma migração em estágios de raios na Etapa 5.

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

Figura 5: Migração de hub-and-spoke para WAN virtual gerenciada pelo cliente

a. Exclua as conexões de emparelhamento existentes das redes virtuais Spoke para o antigo hub gerenciado pelo cliente. O acesso a aplicativos em redes virtuais spoke não está disponível até que as etapas a-c sejam concluídas.

b. Conecte as redes virtuais spoke ao hub WAN Virtual por meio de conexões VNet.

c. Remova todas as rotas definidas pelo usuário (UDR) usadas anteriormente em redes virtuais spoke para comunicações spoke-to-spoke. Esse caminho agora é habilitado pelo roteamento dinâmico disponível no hub WAN Virtual.

d. Os Gateways ExpressRoute e VPN existentes no hub gerenciado pelo cliente agora são desativados para permitir a próxima etapa (e).

e. Conecte o antigo hub gerenciado pelo cliente (rede virtual do hub) ao hub WAN virtual por meio de uma nova conexão VNet.

Etapa 6: O hub antigo se torna serviços compartilhados falados

Agora, redesenhamos nossa rede do Azure para tornar o hub WAN Virtual o ponto central em nossa nova topologia.

Figura 6: Migração de hub-and-spoke para WAN virtual gerenciada pelo cliente

Como o hub WAN Virtual é uma entidade gerenciada e não permite a implantação de recursos personalizados, como máquinas virtuais, o bloco de serviços compartilhados agora existe como uma rede virtual spoke e hospeda funções como entrada na Internet por meio do Gateway de Aplicativo do Azure ou do dispositivo virtualizado de rede. O tráfego entre o ambiente de serviços compartilhados e as máquinas virtuais de back-end agora transita pelo hub gerenciado pela WAN Virtual.

Etapa 7: Otimizar a conectividade local para utilizar totalmente a WAN Virtual

Neste estágio, a Contoso concluiu principalmente suas migrações de aplicativos de negócios para o Microsoft Cloud, com apenas alguns aplicativos herdados permanecendo no DC local.

Figura 7: Migração hub-and-spoke gerenciada pelo cliente para WAN virtual

Para aproveitar toda a funcionalidade da WAN Virtual do Azure, a Contoso decide encerrar suas conexões VPN locais herdadas. Todas as filiais que continuam a acessar redes HQ ou DC podem transitar pela rede global da Microsoft usando o roteamento de trânsito interno da WAN Virtual do Azure.

Arquitetura de estado final e caminhos de tráfego

Figura: WAN virtual de região dupla

Esta seção fornece um resumo de como essa topologia atende aos requisitos originais, examinando alguns exemplos de fluxos de tráfego.

Caminho 1

O caminho 1 mostra o fluxo de tráfego de uma filial conectada à VPN S2S na Ásia para uma VNet do Azure na região Sudeste Asiático.

O tráfego é encaminhado da seguinte forma:

• A filial da Ásia está conectada por meio de túneis resilientes habilitados para S2S BGP no hub WAN Virtual do Sudeste Asiático.

• O hub WAN virtual da Ásia roteia o tráfego localmente para a rede virtual conectada.

Caminho 2

O caminho 2 mostra o fluxo de tráfego da sede europeia conectada à Rota Expressa para uma VNet do Azure na região Sudeste Asiático.

O tráfego é encaminhado da seguinte forma:

• A sede europeia está conectada via circuito ExpressRoute ao hub WAN virtual da Europa Ocidental.

• A conectividade global de hub a hub da WAN virtual permite o trânsito de tráfego para VNet conectada em região remota.

Caminho 3

O caminho 3 mostra o fluxo de tráfego do DC local da Ásia conectado à WAN privada para uma filial conectada ao S2S europeu.

O tráfego é encaminhado da seguinte forma:

• Asia DC está conectado à operadora WAN privada local.

• O circuito ExpressRoute termina localmente na WAN privada e liga-se ao hub WAN Virtual do Sudeste Asiático.

• A conectividade global de hub a hub da WAN virtual 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 do Sudeste Asiático para uma VNet do Azure na região da Europa Ocidental.

O tráfego é encaminhado da seguinte forma:

• A conectividade global de hub para hub da WAN virtual permite o trânsito nativo de todas as VNets do Azure conectadas sem configuração adicional do usuário.

Caminho 5

O caminho 5 mostra o fluxo de tráfego de usuários de VPN móvel (P2S) para uma VNet do Azure na região da Europa Ocidental.

O tráfego é encaminhado da seguinte forma:

• Os usuários de laptops e dispositivos móveis usam o cliente OpenVPN para conectividade transparente com o gateway VPN P2S na Europa Ocidental.

• O hub WAN virtual da Europa Ocidental roteia o tráfego localmente para a rede virtual conectada.

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

Agora, a Contoso validou a conectividade entre todas as filiais e redes virtuais de acordo com os requisitos discutidos anteriormente neste artigo. Para atender aos seus requisitos de controle de segurança e isolamento de rede, eles precisam continuar a separar e registrar o tráfego através da rede do hub. Anteriormente, esta função era executada por um dispositivo virtual de rede (NVA). A Contoso também deseja encerrar seus serviços de proxy existentes e utilizar serviços nativos do Azure para filtragem de saída da Internet.

Figura: Firewall do Azure na WAN Virtual (hub virtual seguro)

As etapas de alto nível a seguir são necessárias para introduzir o Firewall do Azure nos hubs de WAN Virtual para habilitar um ponto unificado de controle de política. Para obter mais informações sobre esse processo e o conceito de Hubs Virtuais Seguros, consulte Gerenciador de Firewall do Azure.

1. Crie a política do Firewall do Azure.
2. Vincule a política de firewall ao hub WAN Virtual do Azure. Esta etapa permite que o hub WAN Virtual existente funcione como um hub virtual seguro e implanta os recursos necessários do Firewall do Azure.

Os caminhos a seguir mostram os caminhos de conectividade habilitados usando hubs virtuais protegidos do Azure:

Caminho 6

O caminho 6 mostra o fluxo de tráfego seguro entre redes virtuais dentro da mesma região.

O tráfego é encaminhado da seguinte forma:

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

• O Firewall do Azure pode aplicar a política a esses fluxos.

Caminho 7

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

O tráfego é encaminhado da seguinte forma:

• As Redes Virtuais conectadas ao Secure Virtual Hub podem enviar tráfego para destinos públicos na Internet, usando o Secure Hub como um ponto central de acesso à Internet.

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

Caminho 8

O Caminho 8 mostra o fluxo de tráfego da filial para a Internet ou do Serviço de Segurança de terceiros.

O tráfego é encaminhado da seguinte forma:

• As filiais conectadas ao Hub Virtual Seguro podem enviar tráfego para destinos públicos na Internet usando o Hub Seguro como ponto central de acesso à Internet.

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

Próximos passos

• Saiba mais sobre a WAN Virtual do Azure.
• Configurar WAN Virtual para Arquivos NetApp do Azure