Conectar uma rede local ao Azure

Este artigo compara as três opções principais para conectar uma rede local a uma rede virtual Azure: Gateway de VPN do Azure, Azure ExpressRoute e soluções IPsec ou SD-WAN não Microsoft hospedadas em Azure. Para cada opção, ela resume o modelo de conectividade, quando a opção é apropriada, os principais benefícios e compensações e links para uma arquitetura de referência detalhada.

Este artigo tem como destino arquitetos de rede e nuvem que avaliam a conectividade site a site entre uma rede corporativa ou de datacenter e uma ou mais redes virtuais Azure. A documentação separada aborda a conectividade VPN ponto a site e Vnet para Vnet, que estão fora do escopo aqui.

Azure conectividade VPN

Um gateway de VPN Azure é um tipo de gateway de rede virtual que envia tráfego criptografado entre uma rede virtual Azure e um local, normalmente pela Internet pública.

Essa arquitetura atende a aplicativos híbridos em que o tráfego entre o local e o Azure é leve ou onde a latência mais alta é aceitável em troca de flexibilidade e escalabilidade na nuvem.

Diagrama que mostra uma arquitetura de conectividade VPN de vários sites em que dois sites locais se conectam a um único gateway de VPN Azure por meio de túneis VPN IPsec separados site a site. À esquerda, há dois sites locais, cada um com um ícone de roteador no limite. Os roteadores são rotulados como dispositivo de rede local, endereço IP público 1 e endereço IP público do dispositivo de rede local 2. Uma linha de cada roteador passa por um túnel VPN IPsec S2S. As linhas de ambos os túneis convergem e se conectam a um gateway de VPN em uma região Azure à direita. Um rótulo entre os dois túneis e o gateway lê Gateway de VPN endereço IP público, indicando que ambos os túneis terminam no mesmo ponto de extremidade público no lado Azure. A região Azure contém uma rede virtual e um ícone de Gateway de VPN.

Azure VPN é mais comumente usada para conectividade VPN S2S (site a site), que fornece conectividade criptografada e roteada entre uma rede local e redes virtuais Azure em túneis IPsec/IKE. Azure VPN também dá suporte a cenários P2S (ponto a site) e VNet para VNet, mas esses cenários abordam o acesso remoto do usuário e a conectividade entre VNets, respectivamente, e não são o foco principal aqui.

Benefícios

Os recursos a seguir tornam Azure VPN uma boa opção para cenários híbridos que não exigem conectividade dedicada.

• Configuração mais simples. A instalação é mais simples do que as opções de conectividade dedicadas, como o ExpressRoute, porque a conexão viaja pela Internet pública e não requer um provedor de conectividade ou um fluxo de trabalho de provisionamento de circuito.
• Criptografado em trânsito. As conexões site a site usam túneis IPsec/IKE, portanto, o tráfego entre o dispositivo VPN local e o gateway de VPN Azure é criptografado na camada de rede por padrão.
• Largura de banda agregada alta. Gateway de VPN dá suporte à agregação de até 10 Gbps em topologias de hub e spoke padrão. Com WAN Virtual do Azure, cada hub virtual dá suporte à agregação de até 20 Gbps. A taxa de transferência agregada e a redundância de zona dependem do SKU Gateway de VPN que você escolher, portanto, dimensione o SKU para a taxa de transferência e a resiliência necessárias. (Consulte Confiabilidade.) Para obter detalhes, consulte Gateway de VPN perguntas frequentes sobre topologia e design e WAN Virtual.

Challenges

Considere as seguintes restrições antes de escolher Azure VPN para uma carga de trabalho híbrida.

• Dispositivo VPN local necessário. Você opera e mantém um dispositivo VPN local compatível, que está localizado fora do limite gerenciado por Azure.
• O SLA abrange somente o gateway. Microsoft oferece um SLA de disponibilidade de 99,9% para Gateway de VPN. O SLA de maior disponibilidade depende do SKU. Para obter detalhes no nível de SKU, consulte Confiabilidade em Azure gateways de rede virtual. O SLA abrange apenas o gateway de VPN e não abrange o caminho público da Internet entre o local e o gateway.

Arquitetura de referência

Para obter um passo a passo de implementação completa dessa opção, consulte a arquitetura de referência a seguir.

• Conectar uma rede local usando Gateway de VPN do Azure

conectividade Azure ExpressRoute

O ExpressRoute é uma conexão privada, redundante e dedicada entre sua rede local e Azure. Um provedor de conectividade não Microsoft fornece o circuito ou você usa o ExpressRoute Direct para uma conexão cruzada direta entre Microsoft e sua rede. Para obter uma visão geral de como o circuito pode ser entregue, consulte os modelos de conectividade do ExpressRoute.

O ExpressRoute atende a aplicativos híbridos que executam cargas de trabalho críticas em larga escala que exigem alta largura de banda e desempenho previsível.

Diagrama que mostra como um circuito do ExpressRoute dá suporte a dois tipos de emparelhamento que roteiam o tráfego para destinos diferentes. À esquerda há uma caixa rotulada como rede local. Uma linha se estende da rede local para uma borda de parceiro rotulada por caixa, que se conecta a uma caixa rotulada Microsoft borda. Há duas conexões entre a borda do parceiro e a borda Microsoft: um link primário e um link secundário. Juntos, esses dois links formam um único circuito do ExpressRoute e cada link carrega o emparelhamento privado do ExpressRoute e Microsoft tráfego de emparelhamento. Na borda Microsoft, os dois caminhos divergem. O caminho de emparelhamento Microsoft leva a uma caixa rotulada Microsoft 365, Dynamics 365 e Azure serviços públicos, que contém oito ícones de serviço: Copilot, serviços do Kubernetes, contas de armazenamento, Azure Cosmos DB, Dynamics 365, Microsoft Entra ID, máquinas virtuais e gateways de aplicativo. O Azure caminho de emparelhamento privado leva a uma caixa separada rotulada Azure região. A região contém um gateway do ExpressRoute em uma rede virtual.

Note

No contexto do ExpressRoute, o Microsoft Enterprise Edge (MSEE) refere-se aos roteadores de borda no lado Microsoft do circuito do ExpressRoute. Esses roteadores são o ponto de entrada na rede Microsoft.

O ExpressRoute é mais comumente usado com o emparelhamento privado do ExpressRoute, que fornece conectividade privada com redes virtuais Azure. Ele também dá suporte ao emparelhamento Microsoft para conectividade com Microsoft serviços públicos, como pontos de extremidade de serviço público Microsoft 365 e Azure. Este artigo se concentra no emparelhamento privado.

Benefícios

Os recursos a seguir tornam o ExpressRoute uma boa opção para cargas de trabalho híbridas que precisam de conectividade dedicada e previsível.

• Largura de banda alta. O ExpressRoute fornece até 10 Gbps por circuito por meio de provedores de conectividade e opções de porta dupla de 10 Gbps, 100 Gbps ou 400 Gbps com o ExpressRoute Direct. A taxa de transferência Azure também é fechada pela SKU do gateway de rede virtual do ExpressRoute, que tem seu próprio teto de largura de banda por SKU, portanto, a taxa de transferência da carga de trabalho é o mínimo do circuito, do SKU do gateway e dos dispositivos de borda locais.
• Latência previsível. Um circuito dedicado evita a variabilidade do caminho da Internet pública e a sobrecarga de processamento de IPsec por pacote de um túnel VPN. Esse design torna a latência de ida e volta menor e mais consistente do que as conexões baseadas na Internet.
• Dimensionamento dinâmico de largura de banda. Você pode aumentar a largura de banda do circuito sem remover a conexão, quando esse recurso é compatível com o provedor de conectividade.
• Acesso à nuvem nacional. O ExpressRoute dá suporte ao acesso direto às nuvens nacionais, dependendo do provedor de conectividade.
• SLA no nível do circuito. O ExpressRoute fornece um SLA de alta disponibilidade no circuito dedicado do ExpressRoute entre a borda de rede Microsoft e o provedor de conectividade ou a infraestrutura de parceiro. O SLA não abrange o caminho local para o provedor ou o gateway de rede virtual do ExpressRoute no Azure.

Challenges

Considere as seguintes restrições antes de escolher o ExpressRoute para uma carga de trabalho híbrida.

• Coordenação do provedor necessária. O provisionamento de um circuito diferente do ExpressRoute Direct requer coordenação com um provedor de conectividade, o que adiciona tempo de entrega e uma dependência fora do limite gerenciado por Azure.
• Roteadores locais de alta capacidade. Você pode dimensionar seus dispositivos de borda locais para a largura de banda de circuito escolhida, incluindo sessões BGP redundantes para ambos os MSEEs.
• Emparelhamento privado não criptografado por padrão. O emparelhamento privado do ExpressRoute fornece um circuito privado, mas não criptografa o tráfego na camada de rede por padrão. Para cargas de trabalho que exigem criptografia em trânsito, use MACsec no ExpressRoute Direct ou IPsec no ExpressRoute para adicionar uma camada de criptografia.

Arquitetura de referência

Para obter um passo a passo de implementação completa dessa opção, consulte a arquitetura de referência a seguir.

• Conectar uma rede local usando Azure ExpressRoute

Conectividade não Microsoft SD-WAN ou IPsec

Azure dá suporte à hospedagem de soluções não Microsoft SD-WAN ou IPsec para estender uma arquitetura de rede existente para a nuvem. Essas opções não nativas permitem que você use uma tecnologia de conectividade preferencial durante a integração com Azure, normalmente executando o dispositivo do fornecedor como uma NVA (solução de virtualização de rede) em uma rede virtual de hub ou anexando-a a um hub de WAN Virtual.

Diagrama que mostra uma arquitetura de conectividade SD-WAN de vários sites em que dois sites de clientes locais se conectam a um hub ou borda virtual SD-WAN implantado em uma região Azure. À esquerda há dois sites locais. Cada um contém um roteador no limite. Cada roteador se conecta a um túnel SD-WAN. As linhas levam de cada roteador pelos túneis para um SD-WAN borda virtual ou hub em uma região Azure que contém uma rede virtual. Uma área de sobreposição sombreada está abaixo dos túneis e abrange os roteadores e o SD-WAN borda virtual ou hub. A área sombreada é rotulada SD-WAN sobreposição em execução em uma subposição pública e/ou privada.

Benefícios

Os recursos a seguir tornam uma implantação não Microsoft SD-WAN ou IPsec uma boa opção quando você deseja manter uma pilha de conectividade existente.

• Continuidade da arquitetura. Estenda uma arquitetura de rede existente para Azure usando tecnologias de conectividade preferenciais, de modo que os lados local e de nuvem compartilhem o mesmo modelo operacional e de roteamento.
• Azure alcance e escala. Mantenha um design de rede consistente, aproveitando o alcance global e a escalabilidade de Azure.

Challenges

Considere as seguintes restrições antes de escolher uma implantação não Microsoft SD-WAN ou IPsec para uma carga de trabalho híbrida.

• Complexidade da implementação. Soluções não nativas exigem mais etapas de design e integração do que as opções de conectividade nativa Azure. Valide as arquiteturas propostas com Microsoft e o parceiro SD-WAN ou IPsec antes da implantação.
• Alta disponibilidade e escala definidas pelo fornecedor. A alta disponibilidade, a taxa de transferência e o comportamento de dimensionamento dependem do design de referência do fornecedor e do dimensionamento de SKU e instância da NVA em Azure. Os SLAs da plataforma para Gateway de VPN e ExpressRoute não se estendem a uma NVA não Microsoft em execução em sua assinatura. O comportamento de runtime, patch e failover desse dispositivo continua sendo sua responsabilidade e responsabilidade do parceiro.

Arquiteturas de referência

Para obter instruções passo a passo de implementação completas dessas opções, consulte as arquiteturas de referência a seguir.

• SD-WAN integração com topologias de rede Azure hub-and-spoke
• Arquitetura de conectividade SD-WAN com WAN Virtual do Azure

Considerations

Essas considerações de confiabilidade aplicam o pilar de confiabilidade do Azure Well-Architected Framework à conectividade híbrida. Os outros pilares (Segurança, Otimização de Custos, Excelência Operacional e Eficiência de Desempenho) têm suas próprias considerações para conectividade VPN, ExpressRoute e não Microsoft. Para obter uma revisão completa do pilar, consulte Microsoft Azure Well-Architected Framework.

Reliability

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz com seus clientes. Para obter mais informações, consulte Lista de verificação da revisão de projeto para Confiabilidade.

A confiabilidade da conectividade híbrida depende da resiliência do gateway ou circuito do lado Azure e dos caminhos de rede e locais que se conectam a ele.

• Gateways com redundância de zona. Quando a região dá suporte a zonas de disponibilidade, implante gateways Gateway de VPN e ExpressRoute em SKUs com redundância de zona para que Azure espalhe as VMs do gateway entre zonas de disponibilidade e o gateway sobreviverá a uma interrupção de zona única. Para obter mais informações, consulte Confiabilidade em Azure VPN (gateways de rede virtual) e design e arquiteto Azure ExpressRoute para resiliência.
• Gateways de VPN ativos ativos. Para cargas de trabalho que precisam de maior resiliência e taxa de transferência agregada de uma conexão VPN, implante o gateway de VPN Azure no modo ativo-ativo para que ambas as instâncias de gateway carreguem tráfego e um túnel de cada instância seja encerrado no dispositivo VPN local. Emparelhe essa configuração com dois dispositivos VPN locais para remover o único ponto de falha local.
• Sessões BGP redundantes para ExpressRoute. O ExpressRoute provisiona um par redundante de sessões BGP por emparelhamento em relação a dois roteadores do MSEE (Microsoft Enterprise Edge) em uma configuração ativa-ativa. Dimensione os dispositivos de borda do cliente local para encerrar ambas as sessões e considere a BFD (Detecção de Encaminhamento Bidirecional) para reduzir a detecção de falha de vínculo abaixo do tempo limite padrão do BGP.
• VPN como um caminho de failover para o ExpressRoute. Para cargas de trabalho que exigem um caminho secundário, configure uma VPN site a site como um backup coexistente para um circuito de emparelhamento privado do ExpressRoute. O circuito do ExpressRoute permanece primário e o tráfego usa o caminho VPN somente quando o circuito não está disponível. Configure o roteamento local (por exemplo, preferência local) para preferir o caminho do ExpressRoute e evitar o roteamento assimétrico.
• Failover regional. Os itens anteriores abordam a resiliência no escopo da zona e no escopo do caminho em uma única região Azure. Cargas de trabalho que exigem continuidade durante uma interrupção regional precisam de um segundo gateway ou circuito na região de failover e seleção de caminho no nível de DNS ou roteamento para direcionar o tráfego para a região sobrevivente. Consulte Projetar para recuperação de desastre com emparelhamento privado do ExpressRoute.
• Componentes que você gerencia. O dispositivo VPN local, roteadores de borda locais e quaisquer NVAs não Microsoft SD-WAN ou IPsec em execução em Azure estão fora do SLA da plataforma Azure. Planeje redundância, patch e failover no nível do dispositivo para esses componentes de acordo com o design de referência do fornecedor.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

• Cynthia Treger | Faixa Preta Global do Engenheiro de Soluções

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Próximas Etapas 

Para obter diretrizes de implementação sobre a opção de conectividade selecionada, consulte a arquitetura de referência correspondente:

• Gateway de VPN do Azure conectividade site a site para redes híbridas. Topologia detalhada para conectividade VPN site a site em uma rede Azure hub-and-spoke.
• Conecte uma rede local usando Azure ExpressRoute. Topologia detalhada para emparelhamento privado do ExpressRoute em Azure.

Recursos relacionados

Os artigos a seguir abordam topologias de rede relacionadas Azure que geralmente acompanham designs de conectividade híbrida:

• Topologia de rede Hub-spoke no Azure
• Topologia de rede hub-spoke que usa WAN Virtual do Azure