Migrar para a WAN Virtual do Azure

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

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

Figura: WAN Virtual do Azure

O modelo de conectividade hub e spoke foi adotado por milhares de clientes para aproveitar o comportamento de roteamento transitivo padrão da Rede do Azure para criar redes de nuvem simples e escalonáveis. A WAN Virtual do Azure baseia-se nesses conceitos e introduz novas funcionalidades que permitem topologias de conectividade global, não apenas entre unidades locais e o Azure, mas também permitindo aos clientes aproveitar a escala da rede Microsoft a fim de ampliar seus redes globais existentes.

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

Cenário

Contoso é uma organização financeira global com escritórios na Europa e na Ásia. Eles planejam migrar seus aplicativos existentes de um data center local para o Azure e criaram um design estruturado com base na arquitetura hub e spoke gerenciada pelo cliente, incluindo redes virtuais de hub regionais para conectividade híbrida. Como parte da migração para as tecnologias baseadas em nuvem, a equipe de rede ficou encarregada de garantir que a conectividade seja otimizada para os negócios de agora em diante.

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

Figura: Topologia de rede existente da Contoso

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

• Uma topologia hub e spoke é usada em várias regiões, incluindo circuitos do ExpressRoute para conectividade de volta para uma WAN (Wide Area Network) privada comum.

• Alguns desses sites também têm túneis VPN ligados diretamente ao Azure para alcançar aplicativos hospedados dentro da nuvem.

Requisitos

A equipe de rede ficou encarregada de fornecer um modelo de rede global capaz de dar suporte à migração da Contoso para a nuvem e de otimizar as áreas de custo, escala e desempenho. Em resumo, os seguintes requisitos devem ser atendidos:

• Fornecer à sede social (HQ) e às branches um caminho otimizado para aplicativos hospedados na nuvem.
• Remover a dependência dos DCs (data centers locais) existentes para o término da VPN e ao mesmo tempo manter os seguintes caminhos de conectividade:
  • Ramificação para VNet: os escritórios conectados à VPN devem ser capazes de acessar aplicativos migrados para a nuvem na região do Azure local.
  • De Ramificação para hub para hub para VNet: os escritórios conectados à VPN devem ser capazes de acessar aplicativos migrados para a nuvem na região do Azure remoto.
  • Ramificação para ramificação: os escritórios regionais conectados à VPN devem ser capazes de se comunicar entre si e com os sites da HQ/DC conectados ao ExpressRoute.
  • De Ramificação para hub para hub para ramificação: os escritórios separados globalmente conectados à VPN devem ser capazes de se comunicar entre si e com todos os sites da HQ/DC conectados ao ExpressRoute.
  • Ramificação para internet: sites conectados devem ser capazes de se comunicar com a internet. Esse tráfego deve ser filtrado e registrado.
  • VNet para VNet: as redes virtuais spoke da mesma região devem ser capazes de se comunicar entre si.
  • De VNet para hub para Hub para VNet: as redes virtuais spoke de diferentes regiões devem ser capazes de se comunicar entre si.
• Forneça aos usuários móveis da Contoso (laptop e telefone) a capacidade de acessar os recursos da empresa quando não estão na rede corporativa.

Arquitetura da 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 da WAN Virtual do Azure

Resumo:

• a HQ na Europa permanece conectada ao ExpressRoute, os DCs locais da Europa são totalmente migrados ao Azure e agora desativados.
• Os DCs e a HQ da Ásia permanecem conectados à WAN Particular. A WAN Virtual do Azure agora é usada para aumentar a rede da operadora local e fornecer conectividade global.
• Implantados hubs da WAN Virtual do Azure nas regiões do Azure Oeste da Europa e Sudeste da Ásia para fornecer o hub de conectividade aos dispositivos conectados por VPN e pelo ExpressRoute.
• Os hubs também fornecem a terminação de VPN para usuários móveis em vários tipos de clientes, usando a conectividade OpenVPN com a rede da malha global, permitindo acesso não apenas aos aplicativos migrados para o Azure, mas também a todos os recursos restantes 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 remoto também fornecida pela WAN Virtual do Azure. Análise de Internet local com suporte por meio da integração de parceiro para acesso otimizado a serviços SaaS, como o Microsoft 365.

Migrar para a WAN Virtual

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

Etapa 1: Hub e spoke gerenciado pelo cliente de região única

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

Figura 1: hub e spoke manual de região individual

Ao manter a abordagem de hub e spoke, a rede virtual de Hub gerenciada pelo cliente contém vários blocos de função:

• Serviços compartilhados (qualquer função comum exigida por vários spokes). 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 de IP/roteamento são fornecidos por uma solução de virtualização de rede de terceiros que permite o roteamento de IP de camada 3 spoke para spoke.
• 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 aos recursos da Internet.
• Gateway de rede virtual de ExpressRoute e VPN para conectividade com redes locais.

Etapa 2: Implantar hubs da WAN Virtual

Implante um hub de WAN Virtual em cada região. Configure o hub da WAN Virtual com funcionalidades de VPN e Express Route, conforme descrito nos seguintes artigos:

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

Figura 2: hub e spoke gerenciado pelo cliente para migração da WAN Virtual

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

Conecte o hub da WAN Virtual aos circuitos do ExpressRoute existentes e configure VPNs site a site pela Internet para todas as ramificações remotas.

Figura 3: hub e spoke gerenciado pelo cliente para migração da WAN Virtual

Neste ponto, o equipamento de rede local começará a receber rotas que refletem o espaço de endereços IP atribuído à VNet do hub gerenciado da WAN Virtual. As filiais conectadas à VPN remota nesta fase verão dois caminhos para todos os aplicativos existentes nas redes virtuais spoke. 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 por meio da WAN Virtual

Antes de usar o hub gerenciado da WAN Virtual para conectividade de produção é recomendável configurar uma rede virtual spoke de teste e uma conexão VNet da WAN Virtual. Valide se as conexões com esse ambiente de teste funcionam por meio do ExpressRoute e da VPN site a site antes de continuar com as próximas etapas.

Figura 4: hub e spoke gerenciado pelo cliente para migração da WAN Virtual

Nesse estágio, é importante reconhecer que a rede virtual do hub gerenciado pelo cliente original e o novo hub da WAN Virtual estão conectados ao mesmo circuito do ExpressRoute. Devido a isso, existe um caminho de tráfego que pode ser usado para habilitar spokes nos dois ambientes para se comunicar. Por exemplo, o tráfego de um spoke que está anexado à rede virtual do Hub gerenciado pelo cliente percorrerá os dispositivos MSEE usados para o circuito do ExpressRoute para alcançar qualquer spoke conectado por meio de uma conexão VNet ao novo hub da WAN Virtual. Isso permite uma migração em etapas de spokes na etapa 5.

Etapa 5: Conectividade de transição para o hub da WAN Virtual

Figura 5: hub e spoke gerenciado pelo cliente para migração da WAN Virtual

a. Exclua as conexões de emparelhamento existentes das redes virtuais Spoke para o hub gerenciado pelo cliente antigo. O acesso aos aplicativos nas redes virtuais spoke fica indisponível até que as etapas de a-c sejam concluídas.

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

c. Remova todas as UDR (rotas definidas pelo usuário) usadas anteriormente em redes virtuais spoke para comunicações spoke a spoke. Agora esse caminho está habilitado pelo roteamento dinâmico disponível no hub da WAN Virtual.

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

e. Conectar o antigo Hub gerenciado pelo cliente (hub de rede virtual) ao hub da WAN Virtual por meio de uma nova conexão VNet.

Etapa 6: O Hub antigo se torna o spoke de serviços compartilhados

Agora, reprojetamos nossa rede do Azure para tornar o Hub da WAN Virtual o ponto central em nossa nova topologia.

Figura 6: hub e spoke gerenciado pelo cliente para migração da WAN Virtual

Como o hub da WAN Virtual é uma entidade gerenciada que 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 a entrada da 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 o hub gerenciado da WAN Virtual.

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

Nesta fase, a Contoso já concluiu a maior parte de suas migrações de aplicativos de negócios para dentro do Microsoft Cloud, restando apenas alguns aplicativos herdados dentro do DC local.

Figura 7: hub e spoke gerenciado pelo cliente para migração da WAN Virtual

Para aproveitar a funcionalidade completa da WAN Virtual do Azure, a Contoso decide desativar suas conexões VPN local herdadas. Qualquer branch que continuar a acessar as redes da HQ ou do DC será capaz de transitar a 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 duas regiões

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

Caminho 1

O caminho 1 mostra o fluxo de tráfego de uma ramificação de VPN S2S conectada na Ásia para uma VNet do Azure na região do Sudeste da Ásia.

O tráfego é roteado da seguinte maneira:

• A ramificação da Ásia é conectada por meio de túneis resilientes habilitados com BGP S2S dentro do hub da WAN Virtual do Sudeste da Ásia.

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

Caminho 2

O caminho 2 mostra o fluxo de tráfego da HQ europeia conectada do ExpressRoute para a VNet do Azure na região do Sudeste da Ásia.

O tráfego é roteado da seguinte maneira:

• A HQ europeia é conectada por meio do circuito do ExpressRoute no Hub da WAN Virtual do Oeste da Europa.

• A conectividade global de Hub para Hub da WAN Virtual permite o trânsito de tráfego para a VNet conectada na região remota.

Caminho 3

O caminho 3 mostra o fluxo de tráfego do DC local da Ásia conectado à WAN Particular para uma ramificação europeia S2S conectada site a site.

O tráfego é roteado da seguinte maneira:

• o DC da Ásia está conectado à operadora de WAN Particular local.

• O circuito do ExpressRoute é encerrado localmente na WAN Particular e se conecta ao hub da WAN Virtual do Sudeste da Ásia.

• A conectividade global hub a hub da WAN Virtual permite o trânsito do tráfego.

Caminho 4

O caminho 4 mostra o fluxo de tráfego da VNet do Azure na região do Sudeste da Ásia para uma VNet do Azure na região do Oeste da Europa.

O tráfego é roteado da seguinte maneira:

• A conectividade global hub a Hub da WAN Virtual permite o trânsito nativo de todas as VNets do Azure conectadas sem configurações adicionais do usuário.

Caminho 5

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

O tráfego é roteado da seguinte maneira:

• Usuários de laptop e dispositivos móveis usam o cliente OpenVPN para conectividade transparente no gateway de VPN P2S no Oeste da Europa.

• O hub da WAN Virtual do Oeste da Europa roteia o tráfego localmente para a VNet conectada.

Controle de segurança e políticas por meio do Firewall do Azure

Agora a Contoso validou a conectividade entre todas as ramificações e as VNets em alinhamento aos requisitos discutidos anteriormente neste artigo. Para atender aos requisitos de controle de segurança e isolamento de rede, eles precisam continuar a separar e registrar o tráfego por meio da rede do hub. Anteriormente, essa função era executada por uma solução de virtualização de rede (NVA). A Contoso também deseja desativar seus serviços de proxy existentes e utilizar os serviços nativos do Azure para a filtragem de saída da Internet.

Figura: Azure Firewall na WAN Virtual (Hub virtual protegido)

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íticas. Para obter mais informações sobre esse processo e o conceito de hubs virtuais seguros, consulte Gerenciador de Firewall do Azure.

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

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

Caminho 6

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

O tráfego é roteado da seguinte maneira:

• as Redes Virtuais conectadas ao mesmo Hub Virtual Seguro agora roteiam o tráfego por meio do Firewall do Azure.

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

Caminho 7

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

O tráfego é roteado da seguinte maneira:

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

• Esse tráfego pode ser filtrado localmente usando as 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 ramificação para a Internet ou um Serviço de Segurança de terceiros.

O tráfego é roteado da seguinte maneira:

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

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

Próximas etapas

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