Fase de design 1: conectividade com sites locais
A conectividade com datacenters locais é a área de design mais crítica para a rede da Solução VMware do Azure. Os principais requisitos que devem ser abordados incluem:
- Alta taxa de transferência: as migrações de ambientes vSphere locais e soluções de recuperação de desastres exigem a movimentação rápida de grandes volumes de dados entre sites locais e nuvens privadas da Solução VMware do Azure.
- Baixa latência: aplicativos distribuídos podem exigir baixa latência para conexões entre máquinas virtuais da Solução VMware do Azure e sistemas locais.
- Previsibilidade de desempenho: para obter taxa de transferência e latência previsíveis, os aplicativos essenciais para os negócios implantados na Solução VMware do Azure podem exigir serviços de conectividade dedicados (Rota Expressa do Azure) entre sites locais e a rede da Microsoft.
Este artigo descreve as opções suportadas pela Solução VMware do Azure para conectividade com sites locais:
As opções são apresentadas em ordem decrescente de capacidade de atender aos principais requisitos listados anteriormente. Uma opção deve ser descartada, e a próxima considerada, somente se entrar em conflito com as restrições inegociáveis de um cenário específico.
Este fluxograma resume o processo de escolha de uma opção de conectividade híbrida para a Solução VMware do Azure:
Alcance Global do ExpressRoute
O ExpressRoute Global Reach é a opção de conectividade híbrida padrão suportada pela Solução VMware do Azure. Ele fornece, com complexidade mínima, conectividade de Camada 3 entre uma nuvem privada da Solução VMware do Azure e um site remoto conectado a um circuito de Rota Expressa gerenciado pelo cliente. Você também pode usar o circuito de Rota Expressa gerenciado pelo cliente para se conectar aos serviços nativos do Azure. Para melhorar a segurança ou reservar largura de banda, você também pode implantar um circuito separado gerenciado pelo cliente que é exclusivamente dedicado ao tráfego da Solução VMware do Azure.
O diagrama a seguir mostra uma topologia de rede que usa o Alcance Global para conectividade com sites locais. O tráfego entre nuvens privadas da Solução VMware do Azure e sites locais não atravessa as redes virtuais do Azure.
Observação
Para obter a máxima resiliência, dois circuitos de Rota Expressa gerenciados pelo cliente em locais de emparelhamento diferentes devem ser usados para conectar datacenters locais ao backbone da Microsoft. Nesse caso, cada circuito de Rota Expressa gerenciado pelo cliente deve ter uma conexão de Alcance Global com a nuvem privada da Solução VMware do Azure (e com as Redes Virtuais do Azure). Analise este artigo para obter orientação sobre implementações resilientes do ExpressRoute.
Para obter instruções sobre como conectar uma nuvem privada da Solução VMware do Azure a um circuito de Rota Expressa gerenciado pelo cliente usando o Alcance Global, consulte Ambientes locais de mesmo nível para a Solução VMware do Azure.
A conectividade Global Reach atende totalmente aos três principais requisitos:
- Alta taxa de transferência: a Rota Expressa permite que você se conecte à rede da Microsoft a partir de suas instalações por linhas dedicadas (até 10 Gbps para a Rota Expressa baseada em provedor ou 100 Gbps para a Rota Expressa Direta).
- Baixa latência: o Global Reach permite rotear o tráfego diretamente da borda da rede Microsoft para clusters do Azure VMware Solution vSphere. O Alcance Global minimiza o número de saltos de rede entre sites locais e nuvens privadas.
- Desempenho previsível: quando você usa o ExpressRoute Global Reach, o tráfego é roteado por links que não apresentam problemas de congestionamento (até a capacidade máxima provisionada). Portanto, o tempo de ida e volta (RTT) entre máquinas virtuais em execução na Solução VMware do Azure e hosts locais permanece constante ao longo do tempo.
Não é possível usar o Alcance Global em cenários em que uma ou mais das seguintes restrições se aplicam:
O ExpressRoute Global Reach não está disponível na região Azure da nuvem privada da Solução VMware do Azure ou no local de encontro do circuito da Rota Expressa gerenciado pelo cliente. Não existem soluções alternativas para essa limitação. Consulte Sobre o Alcance Global da Rota Expressa para obter informações atualizadas sobre a disponibilidade do Alcance Global.
Existem requisitos de segurança de rede inegociáveis. Se um dispositivo de firewall não puder ser implantado no local do circuito da Rota Expressa gerenciado pelo cliente, o uso do Alcance Global expõe todos os segmentos de rede da Solução VMware do Azure, incluindo redes de gerenciamento (vCenter Server e gerenciamento NSX-T), a toda a rede conectada ao circuito. O cenário mais típico em que esse problema surge é quando os circuitos de Rota Expressa gerenciados pelo cliente são implementados sobre os serviços de rede MPLS (também conhecido como modelo de conectividade de qualquer tipo para qualquer da Rota Expressa). Esse cenário é mostrado aqui:
Quando a conectividade da Rota Expressa é implementada sobre as IPVPNs MPLS, é impossível implantar firewalls em um único local para inspecionar todo o tráfego de e para a Solução VMware do Azure. Normalmente, as organizações que usam redes MPLS implantam firewalls em grandes datacenters, não em todos os seus sites (que podem ser pequenas filiais, escritórios ou armazenamentos).
IPSec VPNs
Você pode implementar a conectividade entre nuvens privadas da Solução VMware do Azure e sites locais roteando o tráfego por meio de uma rede virtual de trânsito no Azure. A rede de trânsito está conectada à nuvem privada da Solução VMware do Azure por meio do circuito gerenciado da Rota Expressa. A rede virtual de trânsito é conectada ao site local por meio de uma VPN IPSec, conforme mostrado aqui:
Você pode impor políticas de segurança para conexões entre sites locais e a nuvem privada da Solução VMware do Azure (a linha tracejada no diagrama) roteando o tráfego por meio de um firewall, se o dispositivo VPN não fornecer recursos de firewall. Essa configuração requer a WAN Virtual do Azure com intenção de roteamento, conforme discutido na seção Decidir onde hospedar os dispositivos virtuais no Azure deste artigo.
Antes de implementar a conectividade IPSec entre sites locais e redes virtuais de trânsito, você precisa tomar três decisões de design:
- Determine qual serviço de rede usar como base para o túnel IPSec. As opções disponíveis são conectividade com a Internet, emparelhamento Microsoft da Rota Expressa e emparelhamento privado da Rota Expressa.
- Determine onde hospedar os dispositivos virtuais que encerram o túnel IPSec no lado do Azure. As opções disponíveis incluem redes virtuais gerenciadas pelo cliente e hubs de WAN virtual.
- Determine qual dispositivo virtual encerra o túnel IPSec no lado do Azure. A escolha do dispositivo também determina a configuração necessária do Azure para rotear o tráfego entre o túnel IPSec e o circuito gerenciado da Solução VMware do Azure. As opções disponíveis são o Gateway de VPN do Azure nativo e NVAs (dispositivos virtuais de rede) IPSec de terceiros.
Este fluxograma resume o processo de tomada de decisão:
Os critérios para tomar essas decisões estão descritos nas seções a seguir.
Escolher um serviço de rede subjacente
É altamente recomendável que você considere as três opções para a base VPN na ordem apresentada aqui:
Conexão com a Internet. O endereço IP público atribuído ao dispositivo VPN hospedado na rede virtual de trânsito serve como ponto de extremidade remoto do túnel IPSec. Devido à sua baixa complexidade e custo, você deve sempre testar e avaliar a conectividade com a Internet para desempenho (taxa de transferência IPSec alcançável). Você deve descartar essa opção somente quando o desempenho observado for muito baixo ou inconsistente. O diagrama a seguir ilustra essa opção.
Emparelhamento da Microsoft da Rota Expressa. Essa opção fornece conectividade de Camada 3 para pontos de extremidade públicos do Azure por meio de links dedicados. Como as conexões de Internet, ele permite que você alcance o IP público de um dispositivo VPN que serve como ponto de extremidade remoto do túnel IPSec e está hospedado na rede virtual de trânsito. Você deve descartar essa opção somente quando os requisitos de roteamento do emparelhamento da Microsoft não puderem ser atendidos. O diagrama a seguir ilustra essa opção.
Emparelhamento privado do ExpressRoute. Essa opção fornece conectividade de Camada 3 entre um site local e redes virtuais do Azure por meio de links dedicados. Portanto, ele permite que você estabeleça um túnel IPSec do site local para o endereço IP privado de um dispositivo VPN hospedado em uma rede virtual. O emparelhamento privado da Rota Expressa pode introduzir limitações de largura de banda porque o gateway da Rota Expressa está no caminho de dados. Você pode usar o ExpressRoute FastPath para resolver esse problema. O emparelhamento privado também requer uma configuração de roteamento mais complexa no local. Para obter mais informações, consulte Configurar uma conexão VPN Site a Site por meio de emparelhamento privado da Rota Expressa. O diagrama a seguir ilustra essa opção.
Decidir onde hospedar os dispositivos virtuais no Azure
As opções disponíveis incluem redes virtuais gerenciadas pelo cliente e hubs de WAN virtual. Para tomar essa decisão, considere as características do ambiente do Azure pré-existente, se houver, e como você deseja priorizar a redução do esforço de gerenciamento versus sua capacidade de adaptar a configuração a necessidades específicas. A seguir estão algumas considerações importantes.
- Você deve usar a infraestrutura de rede do Azure pré-existente para conectividade da Solução VMware do Azure. Se já existir uma rede hub-spoke gerenciada pelo cliente na mesma região que a nuvem privada da Solução VMware do Azure, você deverá implantar os dispositivos de terminação IPSec no hub existente. Se existir uma rede hub-spoke baseada em WAN Virtual na mesma região que a nuvem privada da Solução VMware do Azure, você deverá usar o hub de WAN Virtual para terminação IPSec.
- Em uma rede hub-spoke gerenciada pelo cliente, para rotear o tráfego entre um túnel IPSec e o circuito gerenciado da Rota Expressa, você precisa implantar uma instância do Servidor de Rotas do Azure na rede virtual de hub e configurá-la para permitir o tráfego de ramificação para filial. Não é possível rotear o tráfego entre nuvens privadas da Solução VMware do Azure e sites locais por meio de dispositivos de firewall implantados na rede virtual.
- Os hubs de WAN virtual dão suporte nativo ao tráfego de roteamento entre o túnel IPSec conectado ao site local e o circuito de Rota Expressa gerenciado pela Solução VMware do Azure.
- Se você usar a WAN Virtual, poderá configurar a intenção de roteamento e as políticas de roteamento para inspeção de tráfego. Você pode usar o Firewall do Azure ou soluções de segurança de terceiros com suporte na WAN Virtual. Recomendamos que você analise a disponibilidade regional e as limitações da intenção de roteamento.
Decidir qual dispositivo virtual encerra o túnel IPSec
O túnel IPSec que fornece conectividade ao site local pode ser encerrado pelo Gateway de VPN do Azure ou por NVAs de terceiros. Para tomar essa decisão, considere as características do ambiente do Azure pré-existente, se houver, e como você deseja priorizar a redução do esforço de gerenciamento versus sua capacidade de adaptar a configuração a necessidades específicas. A seguir estão algumas considerações importantes.
Em ambas as redes hub-spoke que são gerenciadas pelo cliente e redes hub-spoke baseadas em WAN Virtual, você pode usar o Gateway de VPN do Azure para encerrar túneis IPSec conectados a sites locais. Como são gerenciados por plataforma, os gateways de VPN do Azure exigem um esforço mínimo de gerenciamento. Você pode usar gateways pré-existentes, mesmo que eles ofereçam suporte a outros cenários de conectividade. Você deve revisar estes artigos para obter informações sobre as configurações com suporte e o desempenho esperado:
Os NVAs de terceiros são normalmente usados para encerrar túneis de sites locais nas seguintes situações:
- O NVA é o CPE (equipamento local do cliente) de uma solução SDWAN implantada no Azure e no site local.
- O NVA é um firewall que impõe a política de segurança necessária para conexões entre o site local e a Solução VMware do Azure.
O uso de dispositivos de terceiros pode fornecer mais flexibilidade e acesso a funções de rede avançadas que não são suportadas por gateways VPN nativos, mas aumenta a complexidade. A alta disponibilidade torna-se sua responsabilidade. Você deve implantar várias instâncias.
Trânsito sobre emparelhamento privado da Rota Expressa
O emparelhamento privado da Rota Expressa é a opção mais comum para conectar um site local a uma rede virtual do Azure (ou rede hub-spoke) em cenários corporativos. A rede virtual do Azure, ou a rede virtual de hub em topologias hub-spoke, contém um gateway de Rota Expressa configurado com uma conexão com o circuito de Rota Expressa. Essa configuração fornece conectividade de Camada 3 entre a rede virtual (ou toda a rede hub-spoke) e a rede do site local. No entanto, ele não fornece nativamente conectividade de Camada 3 para nuvens privadas da Solução VMware do Azure que estão conectadas à mesma rede virtual (ou rede virtual de hub) por meio de um circuito gerenciado da Rota Expressa. (Veja Nuvens privadas do ExpressRoute Global Reach e da Solução VMware do Azure.)
Você pode contornar essa limitação implantando mais dispositivos de roteamento na rede virtual do Azure. Isso permite rotear o tráfego por meio de NVAs de firewall hospedados na rede virtual.
O trânsito pelo emparelhamento privado da Rota Expressa pode parecer desejável, mas adiciona complexidade e afeta o desempenho. Você deve considerá-lo somente quando as VPNs ExpressRoute Global Reach e IPSec (descritas nas seções anteriores) não forem aplicáveis.
Há duas opções de implementação:
- Rede virtual única. Quando você usa essa opção, os circuitos gerenciados pelo cliente e a Solução VMware do Azure são conectados ao mesmo gateway da Rota Expressa.
- Rede virtual de trânsito auxiliar. Quando você usa essa opção, o circuito de Rota Expressa gerenciado pelo cliente que fornece conectividade ao site local é conectado ao gateway de Rota Expressa (normalmente pré-existente) na rede virtual de hub. O circuito gerenciado da Solução VMware do Azure está conectado a um gateway de Rota Expressa diferente implantado em uma rede virtual de trânsito auxiliar.
As seções a seguir fornecem detalhes sobre as duas opções de implementação, incluindo:
- Compensações entre desempenho, custo (recursos necessários do Azure) e sobrecarga de gerenciamento.
- Implementação do plano de controle (como as rotas são trocadas entre o site local e a nuvem privada).
- Implementação do plano de dados (como os pacotes de rede são roteados entre o site local e a nuvem privada).
Rede virtual única
Quando você usa a abordagem de rede virtual única, o circuito gerenciado da nuvem privada da Solução VMware do Azure e o circuito de propriedade do cliente são conectados ao mesmo gateway da Rota Expressa, normalmente a rede de hub. O tráfego entre a nuvem privada e o site local pode ser roteado por meio de NVAs de firewall implantados na rede de hub. A arquitetura de rede virtual única é mostrada aqui:
O plano de controle e o plano de dados são implementados conforme descrito aqui:
Painel de controle. Um gateway de Rota Expressa implantado na rede virtual do Azure não pode propagar rotas entre o circuito gerenciado da Solução VMware do Azure e o circuito da Rota Expressa gerenciado pelo cliente. O Servidor de Rotas do Azure, com a configuração de ramificação para filial habilitada, é usado para injetar, em ambos os circuitos, rotas para super-redes que incluem o espaço de endereço da nuvem privada da Solução VMware do Azure (redes de gerenciamento e segmentos de carga de trabalho) e o espaço de endereço local.
As super-redes, em vez dos prefixos exatos que compõem esses espaços de endereço, devem ser anunciadas, porque os prefixos exatos já são anunciados na direção oposta pela nuvem privada do Azure VMware Solution e pelo site local. Você pode usar super-redes tão grandes quanto prefixos RFC 1918 se elas forem compatíveis com a configuração de rede dos sites locais. Na maioria dos casos, você deve usar as menores super-redes que incluem o espaço de endereço da nuvem privada da Solução VMware do Azure e o espaço de endereço local. Isso minimiza os riscos de conflitos com a configuração de roteamento dos sites locais.
As rotas para as super-redes são originadas por NVAs compatíveis com BGP. Os NVAs são configurados para estabelecer uma sessão BPG com o Servidor de Rotas do Azure. Os NVAs são apenas parte do plano de controle e não roteiam o tráfego real entre o site local e a nuvem privada da Solução VMware do Azure. A implementação do plano de controle é representada pelas linhas tracejadas na figura anterior.
Plano de dados. A implementação do plano de controle descrita anteriormente atrai o seguinte tráfego para o gateway da Rota Expressa:
- Tráfego do site local destinado à nuvem privada da Solução VMware do Azure.
- Tráfego da nuvem privada da Solução VMware do Azure destinada ao site local.
Se nenhum UDR for aplicado ao GatewaySubnet, o tráfego fluirá diretamente entre o site local e a nuvem privada da Solução VMware do Azure. Você pode rotear o tráfego para um próximo salto intermediário aplicando UDRs ao GatewaySubnet. NVAs de firewall que impõem políticas de segurança de rede em conexões entre sites locais e nuvens privadas são um exemplo típico. A implementação do plano de dados é representada pela linha sólida na figura anterior.
Rede virtual auxiliar
Você pode usar uma rede virtual auxiliar para hospedar um segundo gateway de Rota Expressa conectado apenas ao circuito gerenciado da nuvem privada da Solução VMware do Azure. Se você usar essa abordagem, o circuito gerenciado da nuvem privada e o circuito gerenciado pelo cliente se conectam a diferentes gateways da Rota Expressa. Duas instâncias do Servidor de Rotas do Azure são usadas para anunciar as rotas adequadas para cada circuito e para controlar a propagação de rotas entre a nuvem privada e o site local. Você não precisa anunciar super-redes, como faz para a opção de rede virtual única descrita na seção anterior. A sobrecarga de gerenciamento para UDRs no GatewaySubnet também é reduzida. Essa abordagem permite rotear o tráfego entre a nuvem privada e o site local por meio de NVAs de firewall na rede virtual de hub. A implementação de rede virtual auxiliar é mostrada no diagrama a seguir:
O plano de controle e o plano de dados são implementados conforme descrito aqui:
Painel de controle. Para habilitar a propagação de rota entre o circuito gerenciado da nuvem privada da Solução VMware do Azure e o circuito de propriedade do cliente, você precisa de uma instância do Servidor de Rotas do Azure em cada rede virtual. Como as duas instâncias do Servidor de Rotas do Azure não podem estabelecer uma adjacência BGP, NVAs compatíveis com BGP são necessários para propagar rotas entre elas. Para alta disponibilidade, você deve implantar pelo menos duas instâncias NVA. Você pode adicionar mais instâncias para aumentar a taxa de transferência. Os NVAs compatíveis com BGP devem ter duas NICs conectadas a sub-redes diferentes. As sessões BGP para os dois servidores de rota (na rede virtual auxiliar e na rede virtual de hub) devem ser estabelecidas em NICs diferentes.
As rotas originadas pela nuvem privada da Solução VMware do Azure e pelo site local são aprendidas nos circuitos da Rota Expressa. Seus caminhos AS contêm ASN 65515 (um ASN reservado pelo Azure que é usado por gateways de Rota Expressa) e ASN 12076 (um ASN de propriedade da Microsoft que é usado pelos roteadores de borda Microsoft Enterprise em todos os locais de emparelhamento). Os NVAs compatíveis com BGP devem remover os caminhos AS para evitar que as rotas sejam descartadas pela detecção de loop BGP. Para obter mais informações sobre a configuração BGP necessária, consulte Implementar conectividade de rota expressa para AVS sem alcance global. A implementação do plano de controle é representada pelas linhas tracejadas no diagrama anterior.
Plano de dados. Na rede virtual auxiliar, o tráfego entre a nuvem privada da Solução VMware do Azure e o site local é roteado por meio dos NVAs compatíveis com BGP. O tráfego de e para a nuvem privada da Solução VMware do Azure sai ou entra nos NVAs por meio da NIC usada para a sessão BGP com o servidor de rotas da rede virtual auxiliar. O tráfego de e para o site local sai ou entra nos NVAs por meio da NIC usada para a sessão BGP com o servidor de rotas da rede virtual do hub. Essa NIC é anexada a uma sub-rede associada a uma tabela de rotas personalizada que:
- Desativa o aprendizado de rotas BGP a partir do servidor de rotas (para evitar loops).
- Insere o firewall da rede de hub no caminho de dados.
Para garantir que o tráfego seja roteado simetricamente por meio do firewall do hub, os UDRs para todos os prefixos usados na nuvem privada da Solução VMware do Azure devem ser configurados na GatewaySubnet do hub. Para obter mais informações, consulte Implementar conectividade de rota expressa para AVS sem alcance global. A implementação do plano de dados é representada pela linha sólida no diagrama anterior.
Próximas etapas
Saiba mais sobre a conectividade entre a Solução VMware do Azure e as redes virtuais do Azure.