Projete conectividade de gateway altamente disponível para conexões entre locais e VNet-to-VNet

  • Artigo

Este artigo ajuda você a entender como projetar conectividade de gateway altamente disponível para conexões entre locais e VNet-to-VNet.

Sobre a redundância de gateway VPN

Todos os Gateways de VPN do Azure consistem em duas instâncias numa configuração ativa-em espera. Caso ocorra uma manutenção planeada ou uma interrupção não planeada na instância ativa, a instância em espera assume o controlo (ativação pós-falha) automaticamente e retoma as ligações VPN S2S ou VNet a VNet. A mudança causará uma breve interrupção. Nas manutenções planeadas, a conectividade deve ser restabelecida ao fim de 10 a 15 segundos. Para problemas não planejados, a recuperação da conexão é mais longa, cerca de 1 a 3 minutos na pior das hipóteses. Para conexões de cliente VPN P2S para o gateway, as conexões P2S são desconectadas e os usuários precisam se reconectar das máquinas cliente.

O diagrama mostra um site local com sub-redes I P privadas e V P N local conectado a um gateway ativo do Azure V P N para se conectar a sub-redes hospedadas no Azure, com um gateway em espera disponível.

Altamente disponível entre instalações

Para fornecer melhor disponibilidade para suas conexões entre locais, há algumas opções disponíveis:

  • Vários dispositivos VPN no local
  • Gateway de VPN do Azure ativo-ativo
  • Uma combinação de ambos

Vários dispositivos VPN locais

Pode utilizar vários dispositivos VPN da sua rede no local para ligar ao Gateway de VPN do Azure, conforme mostrado no diagrama seguinte:

O diagrama mostra vários sites locais com sub-redes IP privadas e VPN local conectada a um gateway de VPN do Azure ativo para se conectar a sub-redes hospedadas no Azure, com um gateway em espera disponível.

Esta configuração fornece vários túneis ativos do mesmo gateway de VPN do Azure para os dispositivos no local na mesma localização. Existem alguns requisitos e limitações:

  1. Tem de criar várias ligações VPN S2S dos dispositivos VPN para o Azure. Quando você conecta vários dispositivos VPN da mesma rede local ao Azure, precisa criar um gateway de rede local para cada dispositivo VPN e uma conexão do gateway de VPN do Azure para cada gateway de rede local.
  2. Os gateways de rede local correspondentes aos dispositivos VPN têm de ter endereços IP públicos exclusivos na propriedade "GatewayIpAddress".
  3. O BGP é necessário para esta configuração. Cada gateway de rede local que representa um dispositivo VPN tem de ter um endereço IP de elemento de rede BGP especificado na propriedade “BgpPeerIpAddress”.
  4. Deve utilizar o BGP para anunciar os mesmos prefixos dos mesmos prefixos da rede no local ao gateway de VPN do Azure e o tráfego será encaminhado através destes túneis simultaneamente.
  5. Você deve usar o ECMP (Roteamento de vários caminhos de custo igual).
  6. Cada conexão é contada em relação ao número máximo de túneis para seu gateway de VPN do Azure. Consulte a página Configurações do Gateway VPN para obter as informações mais recentes sobre túneis, conexões e taxa de transferência.

Nesta configuração, o gateway de VPN do Azure continua no modo ativo-em espera, pelo que o mesmo comportamento de ativação pós-falha e a breve interrupção ainda vão ocorrer, conforme descrito anteriormente. Contudo, esta configuração protege de falhas ou interrupções na sua rede no local e nos seus dispositivos VPN.

Gateways VPN ativos-ativos

Você pode criar um gateway de VPN do Azure em uma configuração ativa-ativa, onde ambas as instâncias das VMs de gateway estabelecem túneis VPN S2S para seu dispositivo VPN local, conforme mostrado no diagrama a seguir:

O diagrama mostra um site local com sub-redes I P privadas e V P N local conectadas a dois gateway ativos do Azure V P N para se conectar a sub-redes hospedadas no Azure.

Nessa configuração, cada instância de gateway do Azure tem um endereço IP público exclusivo e cada uma estabelecerá um túnel VPN IPsec/IKE S2S para seu dispositivo VPN local especificado em seu gateway de rede local e conexão. Ambos os túneis VPN são, na verdade, parte da mesma conexão. Você ainda precisará configurar seu dispositivo VPN local para aceitar ou estabelecer dois túneis VPN S2S para esses dois endereços IP públicos do gateway de VPN do Azure.

Como as instâncias de gateway do Azure estão em configuração ativa-ativa, o tráfego da rede virtual do Azure para a rede local será roteado pelos dois túneis simultaneamente, mesmo que seu dispositivo VPN local possa favorecer um túnel em detrimento do outro. Para um único fluxo TCP ou UDP, o Azure tenta usar o mesmo túnel ao enviar pacotes para sua rede local. No entanto, sua rede local pode usar um túnel diferente para enviar pacotes para o Azure.

Quando se verifica um evento de manutenção planeada ou não planeada numa instância do gateway, o túnel IPsec dessa instância para o dispositivo VPN no local será desligado. As rotas correspondentes nos seus dispositivos VPN devem ser removidas ou retiradas automaticamente, para que o tráfego mude para o outro túnel IPsec ativo. Do lado do Azure, a mudança dá-se automaticamente da instância afetada para a ativa.

Redundância dupla: gateways de VPN ativos-ativos para redes do Azure e redes no local

A opção mais confiável é combinar os gateways ativos-ativos em sua rede e no Azure, conforme mostrado no diagrama a seguir.

O diagrama mostra um cenário de redundância dupla.

Aqui você cria e configura o gateway de VPN do Azure em uma configuração ativa-ativa e cria dois gateways de rede local e duas conexões para seus dois dispositivos VPN locais, conforme descrito acima. O resultado é uma conectividade de malha completa de quatro túneis IPsec entre a rede virtual do Azure e a sua rede no local.

Todos os gateways e túneis estão ativos do lado do Azure, portanto, o tráfego é distribuído entre todos os 4 túneis simultaneamente, embora cada fluxo TCP ou UDP siga novamente o mesmo túnel ou caminho do lado do Azure. Não obstante propagar o tráfego, poderá ver um débito ligeiramente superior nos túneis IPsec. O principal objetivo desta configuração é a elevada disponibilidade. E devido à natureza estatística do spreading, é difícil fornecer a medição de como diferentes condições de tráfego de aplicativos afetarão a taxa de transferência agregada.

Essa topologia requer dois gateways de rede local e duas conexões para suportar o par de dispositivos VPN locais, e o BGP é necessário para permitir a conectividade simultânea nas duas conexões com a mesma rede local. Estes requisitos são os mesmos que os indicados acima.

VNet-to-VNet altamente disponível

Também pode aplicar a mesma configuração ativa-ativa a ligações VNet a VNet do Azure. Você pode criar gateways VPN ativos-ativos para ambas as redes virtuais e conectá-los para formar a mesma conectividade de malha completa de 4 túneis entre as duas redes virtuais, conforme mostrado no diagrama a seguir:

O diagrama mostra duas regiões do Azure que hospedam sub-redes I P privadas e dois gateways do Azure V P N através dos quais os dois sites virtuais se conectam.

Desta forma, é garantido que há sempre um par de túneis entre as duas redes virtuais para eventuais eventos de manutenção planeada, proporcionando uma disponibilidade ainda melhor. Apesar de a mesma topologia para conectividade em vários locais precisar de duas ligações, a topologia de VNet a VNet mostrada anteriormente requer apenas uma ligação para cada gateway. Além disso, o BGP é opcional, a não ser que o encaminhamento do trânsito através da ligação VNet a VNet seja um requisito.

Próximos passos

Consulte Configurar gateways ativos-ativos usando o portal do Azure ou o PowerShell.