Ligue uma rede local ao Azure

Este artigo compara as três principais opções para ligar 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 alojadas em Azure. Para cada opção, resume o modelo de conectividade, quando a opção é apropriada, os principais benefícios e compromissos, e liga a uma arquitetura de referência detalhada.

Este artigo dirige-se a arquitetos de redes e cloud que avaliam a conectividade site-to-site entre uma rede corporativa ou de datacenter e uma ou mais redes virtuais Azure. A documentação separada cobre a conectividade VPN-a-ponto e Vnet-para-Vnet, que estão fora do âmbito aqui.

Conectividade Azure VPN

Um gateway VPN Azure é um tipo de gateway de rede virtual que envia tráfego encriptado entre uma rede virtual Azure e uma localização local, normalmente através da internet pública.

Esta arquitetura adequa-se a aplicações híbridas onde o tráfego entre on-premises e o Azure é reduzido, ou onde uma latência mais elevada é aceitável em troca de flexibilidade e escalabilidade na cloud.

Diagrama que mostra uma arquitetura de conectividade VPN multi-site, onde dois sites on-premises se ligam cada um a um único gateway VPN Azure através de túneis VPN IPsec site-to-site separados. À esquerda, existem dois locais locais, cada um com um ícone de router no seu limite. Os routers 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 router passa por um túnel VPN IPsec S2S. As linhas de ambos os túneis convergem e ligam-se a um gateway VPN numa região do Azure à direita. Um rótulo entre os dois túneis e o gateway indica o endereço IP público do Gateway de VPN, indicando que ambos os túneis terminam no mesmo ponto final público do lado Azure. A região Azure contém uma rede virtual e um ícone de Gateway de VPN.

A VPN Azure é mais frequentemente utilizada para conectividade VPN site-to-site (S2S), que fornece conectividade encriptada e encaminhada entre uma rede local e redes virtuais Azure através de túneis IPsec/IKE. O Azure VPN também suporta cenários point-to-site (P2S) e VNet-to-VNet, mas esses cenários abordam o acesso remoto do utilizador e a conectividade entre VNet, respetivamente, e não são o foco principal aqui.

Benefits

As seguintes capacidades tornam o Azure VPN uma boa opção para cenários híbridos que não requerem conectividade dedicada.

• Configuração mais simples. A configuração é mais simples do que opções de conectividade dedicadas como o ExpressRoute, porque a ligação viaja pela internet pública e não requer um fornecedor de conectividade nem um fluxo de trabalho de provisão de circuitos.
• Encriptado em trânsito. As ligações site-to-site utilizam túneis IPsec/IKE, pelo que o tráfego entre o dispositivo VPN on-premises e o gateway VPN do Azure é encriptado na camada de rede por defeito.
• Largura de banda agregada elevada. O Gateway de VPN suporta até 10 Gbps agregados em topologias padrão de hub e speak. Com o WAN Virtual do Azure, cada hub virtual suporta até 20 Gbps agregados. Tanto o throughput agregado como a redundância de zonas dependem do SKU Gateway de VPN que escolheres, por isso dimensiona o SKU para o throughput e resiliência de que precisas. (Ver Fiabilidade.) Para mais detalhes, consulte topologia e design do Gateway de VPN e WAN Virtual FAQ.

Challenges

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

• É necessário dispositivo VPN on-local. Opera e mantém um dispositivo VPN local compatível, localizado fora dos limites geridos pelo Azure.
• O SLA cobre apenas o gateway. Microsoft oferece um SLA de disponibilidade de 99,9% para Gateway de VPN. A maior disponibilidade de SLA depende do SKU. Para detalhes ao nível do SKU, veja Fiabilidade em gateways de rede virtual do Azure. O SLA cobre apenas o gateway VPN e não cobre o caminho público da internet entre o local e o gateway.

Arquitetura de referência

Para um guia completo de implementação desta opção, consulte a seguinte arquitetura de referência.

• Ligue uma rede local usando o Gateway de VPN do Azure

Conectividade Azure ExpressRoute

O ExpressRoute é uma ligação privada, redundante e dedicada entre a sua rede local e o Azure. Um fornecedor de conectividade não Microsoft fornece o circuito, ou usa o ExpressRoute Direct para uma ligação cruzada direta entre a Microsoft e a sua rede. Para uma visão geral de como o circuito pode ser entregue, veja modelos de conectividade ExpressRoute.

O ExpressRoute adequa-se a aplicações híbridas que executam cargas de trabalho de grande escala, críticas para a missão, que requerem alta largura de banda e desempenho previsível.

Diagrama que mostra como um circuito ExpressRoute suporta dois tipos de peering que encaminham o tráfego para destinos diferentes. À esquerda encontra-se uma caixa rotulada como Rede local. Uma linha estende-se desde a rede local até uma caixa rotulada como Partner edge, que depois se liga a uma caixa rotulada como Microsoft edge. Existem duas ligações entre a borda do parceiro e a borda da Microsoft: uma ligação primária e uma ligação secundária. Juntas, estas duas ligações formam um único circuito ExpressRoute, e cada uma transporta tanto tráfego de peering privado ExpressRoute como de peering da Microsoft. A partir da Microsoft edge, os dois caminhos divergem. O percurso de peering da Microsoft conduz a uma caixa rotulada como Microsoft 365, Dynamics 365 e serviços públicos Azure, que contém oito ícones de serviço: Copilot, serviços Kubernetes, contas de armazenamento, Azure Cosmos DB, Dynamics 365, Microsoft Entra ID, máquinas virtuais e gateways de aplicação. O caminho de peering privado do Azure conduz a uma caixa separada rotulada como região Azure. A região contém um gateway ExpressRoute numa rede virtual.

Note

No contexto do ExpressRoute, o Microsoft Enterprise Edge (MSEE) refere-se aos routers edge do lado da Microsoft do circuito ExpressRoute. Estes routers são o ponto de entrada para a rede Microsoft.

O ExpressRoute é mais frequentemente utilizado com peering privado ExpressRoute, que fornece conectividade privada a redes virtuais Azure. Também suporta o peering da Microsoft para conectividade a serviços públicos da Microsoft, como os endpoints de serviço público Microsoft 365 e Azure. Este artigo foca-se no peering privado.

Benefits

As seguintes capacidades tornam o ExpressRoute uma boa opção para cargas de trabalho híbridas que necessitam de conectividade dedicada e previsível.

• Largura de banda elevada. O ExpressRoute oferece até 10 Gbps por circuito através de fornecedores de conectividade, e duas opções de porta de 10 Gbps, 100 Gbps ou 400 Gbps com o ExpressRoute Direct. A taxa de transferência em Azure também é limitada pelo SKU de gateway de rede virtual ExpressRoute, que tem o seu próprio teto de largura de banda por SKU, pelo que o débito da carga de trabalho é o mínimo do circuito, do SKU do gateway e dos dispositivos de borda on-premises.
• Latência previsível. Um circuito dedicado evita a variabilidade do caminho da internet pública e a sobrecarga de processamento IPsec por pacote de um túnel VPN. Este design torna a latência de ida e volta mais baixa e mais consistente do que as ligações baseadas na internet.
• Escalonamento dinâmico de largura de banda. Pode aumentar a largura de banda do circuito sem remover a ligação, quando esta funcionalidade é suportada pelo fornecedor de conectividade.
• Acesso nacional à cloud. O ExpressRoute suporta acesso direto a clouds nacionais, dependendo do fornecedor de conectividade.
• SLA ao nível do circuito. O ExpressRoute fornece um SLA de alta disponibilidade no circuito dedicado do ExpressRoute entre a borda da rede Microsoft e a infraestrutura do fornecedor de conectividade ou parceiro. O SLA não cobre o caminho local para o fornecedor nem o gateway virtual da rede ExpressRoute no Azure.

Challenges

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

• É necessária coordenação de prestadores. O provisionamento de um circuito diferente do ExpressRoute Direct requer coordenação com um fornecedor de conectividade, o que adiciona tempo de espera e uma dependência fora do limite gerido pelo Azure.
• Routers locais de alta capacidade. Pode dimensionar os seus dispositivos de borda on-premises para a largura de banda do circuito escolhida, incluindo sessões BGP redundantes para ambos os MSEEs.
• Peering privado não é encriptado por defeito. O peering privado ExpressRoute fornece um circuito privado, mas não encripta o tráfego na camada de rede por defeito. Para cargas de trabalho que requerem encriptação em trânsito, use MACsec no ExpressRoute Direct ou IPsec sobre ExpressRoute para adicionar uma camada de encriptação.

Arquitetura de referência

Para um guia completo de implementação desta opção, consulte a seguinte arquitetura de referência.

• Ligue uma rede local utilizando o Azure ExpressRoute

Conectividade não-Microsoft SD-WAN ou IPsec

Azure suporta o alojamento de soluções não-Microsoft SD-WAN ou IPsec para estender uma arquitetura de rede existente para a cloud. Estas opções não nativas permitem-lhe usar uma tecnologia de conectividade preferida enquanto se integra com o Azure, normalmente executando o appliance do fornecedor como um appliance virtual de rede (NVA) numa rede virtual hub ou ligando-o a um hub WAN Virtual.

Diagrama que mostra uma arquitetura de conectividade SD-WAN multi-site, onde dois locais de clientes on-premises se ligam a uma SD-WAN edge virtual ou hub implementado numa região Azure. À esquerda encontram-se dois locais nas instalações. Cada um contém um router na fronteira. Cada router liga-se a um túnel SD-WAN. As linhas conduzem de cada router através dos túneis até uma SD-WAN edge virtual ou hub numa região Azure que contém uma rede virtual. Uma área de sobreposição sombreada situa-se por baixo dos túneis e abrange os routers e a SD-WAN edge ou hub virtual. A área sombreada é designada como SD-WAN sobreposição que corre sobre uma base pública e/ou privada.

Benefits

As seguintes capacidades tornam uma implementação sem Microsoft SD-WAN ou IPsec uma boa opção quando se pretende manter uma pilha de conectividade existente.

• Continuidade da arquitetura. Estenda uma arquitetura de rede existente para o Azure utilizando tecnologias de conectividade preferenciais, de modo a que o lado on-premises e o cloud partilhem o mesmo modelo operacional e de encaminhamento.
• Azure alcance e escala. Mantenha um design de rede consistente, aproveitando o alcance global e a escalabilidade do Azure.

Challenges

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

• Complexidade da implementação. As soluções não nativas requerem mais passos de design e integração do que as opções de conectividade nativas do Azure. Valide as arquiteturas propostas tanto com o Microsoft como com o parceiro SD-WAN ou IPsec antes da implementação.
• Alta disponibilidade e escala definidas pelo fornecedor. A alta disponibilidade, o rendimento e o comportamento de escalabilidade dependem do design de referência do fornecedor e do SKU e do dimensionamento da instância do NVA no Azure. Os SLAs da plataforma para Gateway de VPN e ExpressRoute não se estendem a um NVA que não seja da Microsoft a correr na tua subscrição. O comportamento de execução, patches e failover desse dispositivo continuam a ser da sua responsabilidade e do seu parceiro.

Arquiteturas de referência

Para guias completas de implementação destas opções, consulte as seguintes arquiteturas de referência.

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

Considerations

Estas considerações de fiabilidade aplicam o pilar de Fiabilidade 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 cada um as suas próprias considerações para VPN, ExpressRoute e conectividade não Microsoft. Para uma revisão completa dos pilares, consulte Microsoft Azure Well-Architected Framework.

Reliability

A fiabilidade ajuda a garantir que a sua aplicação cumpre os compromissos que assume para com os seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

A fiabilidade da conectividade híbrida depende da resiliência tanto do gateway ou circuito do lado do Azure como dos caminhos on-premises e de rede que a ele se ligam.

• Gateways redundantes de zona. Quando a região suportar zonas de disponibilidade, implemente gateways Gateway de VPN e ExpressRoute em SKUs redundantes de zona, para que o Azure distribua as VMs do gateway por zonas de disponibilidade e o gateway sobreviva a uma interrupção de zona única. Para mais informações, consulte Fiabilidade em gateways de rede virtual Azure (VPN) e Design and architect Azure ExpressRoute para resiliência.
• Gateways VPN ativo-ativo. Para cargas de trabalho que necessitem de maior resiliência e taxa de processamento agregada a partir de uma ligação VPN, implemente o gateway VPN do Azure em modo ativo-ativo para que ambas as instâncias do gateway transportem tráfego e um túnel de cada instância termine no dispositivo VPN local. Emparelhe esta configuração com dois dispositivos VPN on-premises para remover o ponto único de falha on-local.
• Sessões BGP redundantes para ExpressRoute. O ExpressRoute fornece um par redundante de sessões BGP por peering contra dois routers Microsoft Enterprise Edge (MSEE) numa configuração ativo-ativo. Dimensione dispositivos de borda de cliente on-premises para terminar ambas as sessões e considere a Deteção Bidirecional de Encaminhamento (BFD) para encurtar a deteção de falhas de ligação abaixo do tempo limite padrão do BGP.
• VPN como caminho de failover para o ExpressRoute. Para cargas de trabalho que requerem um caminho secundário, configure uma VPN site-to-site como backup coexistente para um circuito privado de peering ExpressRoute. O circuito ExpressRoute mantém-se como primário, e o tráfego utiliza o caminho VPN apenas quando o circuito não está disponível. Configure o encaminhamento local (por exemplo, preferência local) para preferir o caminho ExpressRoute e evitar o encaminhamento assimétrico.
• Failover regional. Os itens anteriores abordam a resiliência por zonas e caminhos dentro de uma única região Azure. Cargas de trabalho que necessitam de continuidade durante uma interrupção regional necessitam de um segundo gateway ou circuito na região de failover, e de seleção de caminhos ao nível DNS ou de roteamento para direcionar o tráfego para a região sobrevivente. Veja Desenho para recuperação de desastres com peering privado ExpressRoute.
• Componentes que tu geres. O dispositivo VPN on-premiss, os routers de borda on-premises e quaisquer NVAs não Microsoft SD-WAN ou IPsec a correr em Azure estão fora do SLA da plataforma Azure. Planeie redundância, patches e failover ao nível do dispositivo para esses componentes, em linha com o design de referência do fornecedor.

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Cynthia Treger | Engenheiro de Soluções Global Black Belt

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Passos seguintes

Para orientações de implementação sobre a opção de conectividade que selecionar, consulte a arquitetura de referência correspondente:

• Gateway de VPN do Azure conectividade site-to-site para redes híbridas. Topologia detalhada para conectividade VPN site-to-site numa rede hub e spoke do Azure.
• Ligue uma rede local usando Azure ExpressRoute. Topologia detalhada para peering privado ExpressRoute no Azure.

Recursos relacionados

Os artigos seguintes abordam topologias de rede Azure relacionadas que frequentemente acompanham designs de conectividade híbrida:

• Topologia de Rede Hub-Spoke na plataforma Azure
• Topologia de rede hub-spoke que utiliza WAN Virtual do Azure