Pular para o conteúdo principal

Challenge 15: Alta disponibilidade de VPN S2S e vários sites

Tempo e custo estimados

75-120 minutos | ~$0,55/h (SKU VpnGw2AZ) | Peso no exame: 20-25%

Tempo de implantação

O provisionamento do VPN Gateway active-active leva 30-45 minutos. Use --no-wait e continue com o aprendizado conceitual enquanto o gateway é implantado.

Cenário

A VPN site a site da Contoso estabelecida no Challenge 14 usa uma única instância de VPN gateway, criando um ponto único de falha. Durante um evento recente de manutenção do Azure, o túnel VPN ficou inativo por 15 minutos, causando uma interrupção nos negócios. A equipe de rede deve implementar alta disponibilidade para o VPN gateway usando configuração active-active com SKUs com redundância de zona, conectar-se a vários sites locais e configurar BGP para troca dinâmica de rotas. Além disso, a equipe precisa entender o Azure Extended Network para um projeto futuro de migração Layer 2.

Arquitetura:

Challenge 15 - Topologia de Rede

Objetivos de aprendizagem

Após concluir este desafio, você será capaz de:

  • Projetar e implementar uma conexão VPN site a site com alta disponibilidade
  • Implantar um VPN gateway active-active com SKUs com redundância de zona
  • Configurar BGP em VPN gateways para roteamento dinâmico
  • Conectar vários sites locais a um único VPN gateway (vários sites)
  • Explicar a finalidade e o caso de uso do Azure Extended Network

Pré-requisitos

  • Conclusão do Challenge 14 (ou compreensão dos conceitos básicos de VPN S2S)
  • Uma assinatura do Azure com acesso de Contributor
  • Azure CLI instalado e autenticado (az login)
  • PowerShell com o módulo Az instalado

Conceitos-chave para o AZ-700

ConceitoDetalhe
Gateway active-activeDuas instâncias de gateway, cada uma com seu próprio IP público; ambos os túneis ativos simultaneamente
Gateway com redundância de zonaSKUs terminados em "AZ" (ex.: VpnGw2AZ) implantam instâncias em zonas de disponibilidade
BGP (Border Gateway Protocol)Protocolo de roteamento dinâmico; anuncia rotas automaticamente em vez de local-address-prefixes estáticos
ASN (Autonomous System Number)Identificador único para um speaker BGP; o padrão do Azure é 65515
VPN de vários sitesVários gateways de rede local conectados a um único VPN gateway (uma conexão por site)
Azure Extended NetworkOverlay Layer 2 que estende uma sub-rede local para o Azure para migração ao vivo sem re-IP

Active-active vs active-standby

RecursoActive-standby (padrão)Active-active
Instâncias do gateway2 (uma ativa, uma em standby)2 (ambas ativas)
IPs públicos12 (um por instância)
Tempo de failover60-90 segundosQuase instantâneo (outro túnel já ativo)
Túneis por site12 (um para cada instância)
Configuração on-premisesTúnel único para um IPDois túneis para dois IPs
ThroughputLargura de banda de instância únicaLargura de banda agregada de ambas as instâncias

Nomenclatura de SKU com redundância de zona

SKU padrãoEquivalente com redundância de zona
VpnGw1VpnGw1AZ
VpnGw2VpnGw2AZ
VpnGw3VpnGw3AZ
VpnGw4VpnGw4AZ
VpnGw5VpnGw5AZ

SKUs com redundância de zona exigem IPs públicos de SKU Standard (não Basic) com alocação com redundância de zona.


Tarefa 1: Implantar um VPN gateway active-active com redundância de zona

Etapa 1: Criar o grupo de recursos e a VNet

az group create \
--name rg-vpn-ha-lab \
--location eastus

az network vnet create \
--resource-group rg-vpn-ha-lab \
--name vnet-hub \
--location eastus \
--address-prefixes 10.1.0.0/16 \
--subnet-name snet-workloads \
--subnet-prefixes 10.1.1.0/24

az network vnet subnet create \
--resource-group rg-vpn-ha-lab \
--vnet-name vnet-hub \
--name GatewaySubnet \
--address-prefixes 10.1.255.0/27

Etapa 2: Criar dois IPs públicos com redundância de zona (necessário para active-active)

az network public-ip create \
--resource-group rg-vpn-ha-lab \
--name pip-vgw-hub-1 \
--location eastus \
--allocation-method Static \
--sku Standard \
--zone 1 2 3

az network public-ip create \
--resource-group rg-vpn-ha-lab \
--name pip-vgw-hub-2 \
--location eastus \
--allocation-method Static \
--sku Standard \
--zone 1 2 3
IPs públicos com redundância de zona

Ao usar SKUs de gateway com redundância de zona (terminados em AZ), os IPs públicos devem ser de SKU Standard. Especificar --zone 1 2 3 torna o IP com redundância de zona, o que significa que ele sobrevive à falha de qualquer zona de disponibilidade individual.

Etapa 3: Criar o VPN gateway active-active

az network vnet-gateway create \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--vnet vnet-hub \
--gateway-type Vpn \
--vpn-type RouteBased \
--sku VpnGw2AZ \
--public-ip-addresses pip-vgw-hub-1 pip-vgw-hub-2 \
--active-active \
--no-wait

Azure PowerShell

# Create public IPs
$pip1 = New-AzPublicIpAddress `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "pip-vgw-hub-1" `
-Location "eastus" `
-AllocationMethod Static `
-Sku Standard `
-Zone 1, 2, 3

$pip2 = New-AzPublicIpAddress `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "pip-vgw-hub-2" `
-Location "eastus" `
-AllocationMethod Static `
-Sku Standard `
-Zone 1, 2, 3

# Get subnet reference
$vnet = Get-AzVirtualNetwork -ResourceGroupName "rg-vpn-ha-lab" -Name "vnet-hub"
$gwSubnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet

# Create two IP configurations (one per public IP)
$ipConfig1 = New-AzVirtualNetworkGatewayIpConfig `
-Name "gwIpConfig1" `
-SubnetId $gwSubnet.Id `
-PublicIpAddressId $pip1.Id

$ipConfig2 = New-AzVirtualNetworkGatewayIpConfig `
-Name "gwIpConfig2" `
-SubnetId $gwSubnet.Id `
-PublicIpAddressId $pip2.Id

# Create active-active VPN gateway
New-AzVirtualNetworkGateway `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "vgw-hub-ha" `
-Location "eastus" `
-IpConfigurations $ipConfig1, $ipConfig2 `
-GatewayType Vpn `
-VpnType RouteBased `
-GatewaySku VpnGw2AZ `
-EnableActiveActiveFeature `
-AsJob

Tarefa 2: Conectar vários sites locais (VPN de vários sites)

Etapa 1: Criar gateways de rede local para cada site

# Site A: Dallas datacenter
az network local-gateway create \
--resource-group rg-vpn-ha-lab \
--name lgw-dallas \
--gateway-ip-address 203.0.113.10 \
--local-address-prefixes 10.10.0.0/16 \
--location eastus

# Site B: Chicago datacenter
az network local-gateway create \
--resource-group rg-vpn-ha-lab \
--name lgw-chicago \
--gateway-ip-address 198.51.100.25 \
--local-address-prefixes 10.20.0.0/16 \
--location eastus

Etapa 2: Criar conexões VPN para cada site

# Connection to Dallas
az network vpn-connection create \
--resource-group rg-vpn-ha-lab \
--name conn-to-dallas \
--vnet-gateway1 vgw-hub-ha \
--local-gateway2 lgw-dallas \
--shared-key "DallasKey!2024Secure"

# Connection to Chicago
az network vpn-connection create \
--resource-group rg-vpn-ha-lab \
--name conn-to-chicago \
--vnet-gateway1 vgw-hub-ha \
--local-gateway2 lgw-chicago \
--shared-key "ChicagoKey!2024Secure"

Azure PowerShell

# Create local gateways
$lgwDallas = New-AzLocalNetworkGateway `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "lgw-dallas" `
-Location "eastus" `
-GatewayIpAddress "203.0.113.10" `
-AddressPrefix "10.10.0.0/16"

$lgwChicago = New-AzLocalNetworkGateway `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "lgw-chicago" `
-Location "eastus" `
-GatewayIpAddress "198.51.100.25" `
-AddressPrefix "10.20.0.0/16"

# Create connections
$vgw = Get-AzVirtualNetworkGateway -ResourceGroupName "rg-vpn-ha-lab" -Name "vgw-hub-ha"

New-AzVirtualNetworkGatewayConnection `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "conn-to-dallas" `
-Location "eastus" `
-VirtualNetworkGateway1 $vgw `
-LocalNetworkGateway2 $lgwDallas `
-ConnectionType IPsec `
-SharedKey "DallasKey!2024Secure"

New-AzVirtualNetworkGatewayConnection `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "conn-to-chicago" `
-Location "eastus" `
-VirtualNetworkGateway1 $vgw `
-LocalNetworkGateway2 $lgwChicago `
-ConnectionType IPsec `
-SharedKey "ChicagoKey!2024Secure"
Considerações sobre vários sites
  • Cada site local requer seu próprio gateway de rede local e recurso de conexão VPN
  • VPN gateways baseados em rota suportam até 30 túneis S2S (VpnGw1) ou 100 (VpnGw4/5)
  • Os espaços de endereço em todos os gateways de rede local não devem se sobrepor
  • Cada conexão pode ter uma chave compartilhada diferente

Tarefa 3: Configurar BGP no VPN gateway

O BGP permite a troca dinâmica de rotas, eliminando a necessidade de manter manualmente --local-address-prefixes nos gateways de rede local quando as redes locais mudam.

Etapa 1: Habilitar BGP no VPN gateway

az network vnet-gateway update \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--enable-bgp true \
--asn 65010

Etapa 2: Criar um gateway de rede local com BGP habilitado

Ao usar BGP, o gateway de rede local inclui o IP do peer BGP on-premises e o ASN:

az network local-gateway create \
--resource-group rg-vpn-ha-lab \
--name lgw-dallas-bgp \
--gateway-ip-address 203.0.113.10 \
--local-address-prefixes 10.10.0.0/16 \
--bgp-peering-address 10.10.255.254 \
--asn 65020 \
--location eastus

Etapa 3: Criar uma conexão com BGP habilitado

az network vpn-connection create \
--resource-group rg-vpn-ha-lab \
--name conn-to-dallas-bgp \
--vnet-gateway1 vgw-hub-ha \
--local-gateway2 lgw-dallas-bgp \
--shared-key "DallasBGP!2024Key" \
--enable-bgp true

Azure PowerShell

# Update gateway with BGP
$vgw = Get-AzVirtualNetworkGateway -ResourceGroupName "rg-vpn-ha-lab" -Name "vgw-hub-ha"
$vgw.EnableBgp = $true
$vgw.BgpSettings.Asn = 65010
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $vgw

# Create BGP-enabled local gateway
$lgwDallasBgp = New-AzLocalNetworkGateway `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "lgw-dallas-bgp" `
-Location "eastus" `
-GatewayIpAddress "203.0.113.10" `
-AddressPrefix "10.10.0.0/16" `
-BgpPeeringAddress "10.10.255.254" `
-Asn 65020

# Create connection with BGP
New-AzVirtualNetworkGatewayConnection `
-ResourceGroupName "rg-vpn-ha-lab" `
-Name "conn-to-dallas-bgp" `
-Location "eastus" `
-VirtualNetworkGateway1 $vgw `
-LocalNetworkGateway2 $lgwDallasBgp `
-ConnectionType IPsec `
-SharedKey "DallasBGP!2024Key" `
-EnableBgp $true

Etapa 4: Verificar a configuração do BGP

# Show gateway BGP settings
az network vnet-gateway show \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--query "{bgpEnabled:enableBgp, asn:bgpSettings.asn, peerAddress:bgpSettings.bgpPeeringAddress}" \
--output table

# List learned BGP routes
az network vnet-gateway list-learned-routes \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--output table

# List advertised routes to a specific peer
az network vnet-gateway list-advertised-routes \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--peer 10.10.255.254 \
--output table
Regras de ASN do BGP
  • ASN reservado do Azure: 65515 (padrão para VPN gateways do Azure se não especificado)
  • Não use 65515 para dispositivos on-premises
  • Faixa de ASN privado: 64512-65534 e 4200000000-4294967294
  • Cada peer BGP (gateway do Azure e dispositivo on-premises) deve ter um ASN único
  • O --bgp-peering-address no gateway de rede local é o IP interno do peer BGP do dispositivo on-premises (não seu IP público)

Tarefa 4: Verificar as instâncias do gateway active-active

Azure CLI

# Show both public IPs assigned to the active-active gateway
az network vnet-gateway show \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--query "ipConfigurations[].{name:name, publicIP:publicIpAddress.id}" \
--output table

# Show both tunnel IPs
az network public-ip show \
--resource-group rg-vpn-ha-lab \
--name pip-vgw-hub-1 \
--query "ipAddress" \
--output tsv

az network public-ip show \
--resource-group rg-vpn-ha-lab \
--name pip-vgw-hub-2 \
--query "ipAddress" \
--output tsv

Azure PowerShell

# Verify active-active configuration
$vgw = Get-AzVirtualNetworkGateway -ResourceGroupName "rg-vpn-ha-lab" -Name "vgw-hub-ha"
$vgw.ActiveActive
$vgw.IpConfigurations | Format-Table Name, PublicIpAddress

Tarefa 5: Simular failover

Em uma configuração active-active, se uma instância do gateway ficar indisponível, o dispositivo on-premises detecta o peer inativo (via IKE Dead Peer Detection) e faz failover para o túnel ativo restante. Nenhuma ação do lado do Azure é necessária.

Etapas de verificação

# Monitor connection status for both tunnels
az network vpn-connection show \
--resource-group rg-vpn-ha-lab \
--name conn-to-dallas \
--query "{status:connectionStatus, tunnelStatus:tunnelConnectionStatus}" \
--output json

Compreendendo o comportamento de failover

CenárioComportamento active-standbyComportamento active-active
Manutenção planejada60-90 segundos de inatividadeQuase zero inatividade (outro túnel permanece)
Falha de zonaGateway indisponível se na zona afetadaSobrevive se usar SKU AZ entre zonas
Falha de instância única60-90 segundos de failover para standbyUso imediato do outro túnel ativo
Falha do dispositivo on-premisesTúnel inativo até o dispositivo recuperarTúnel inativo até o dispositivo recuperar (igual)

Tarefa 6: Azure Extended Network (conceitual)

O Azure Extended Network é uma tecnologia de overlay Layer 2 que estende uma sub-rede on-premises para uma VNet do Azure, permitindo que VMs mantenham seus endereços IP on-premises quando migradas para o Azure.

Caso de uso

  • Migração ao vivo de VMs do on-premises para o Azure sem alterar endereços IP
  • Evitar re-IP durante projetos de migração em fases
  • Manter dependências de rede (IPs codificados, aplicativos legados) durante a transição

Requisitos e limitações

RequisitoDetalhe
On-premisesWindows Server 2019+ com Hyper-V
AzureVMs com Windows Server 2019+ no Azure
RedeVPN site a site ou ExpressRoute entre on-premises e Azure
Sub-redeMáximo de /24 para a sub-rede estendida
EscopoDestinado apenas para migração, não para uso em produção a longo prazo

Como funciona

  1. Um par de VMs appliance (uma on-premises, uma no Azure) cria um túnel VXLAN sobre a VPN S2S
  2. O tráfego ARP e broadcast é intermediado entre os dois lados
  3. VMs em ambos os lados da sub-rede estendida podem se comunicar na Layer 2
  4. Após a conclusão da migração, o lado on-premises é descomissionado
Nota de exame

O Azure Extended Network é um tópico de nicho no exame. Pontos-chave a lembrar: requer Windows Server 2019+, funciona sobre VPN S2S ou ExpressRoute existente, é limitado a sub-redes /24 e é projetado como um auxílio temporário de migração (não uma arquitetura permanente). Se o exame perguntar sobre estender Layer 2 para o Azure, esta é a resposta.

Comandos de referência (apenas conceitual)

O Azure Extended Network é configurado através do Windows Admin Center, não via Azure CLI ou PowerShell diretamente:

  1. Instale a extensão Azure Extended Network no Windows Admin Center
  2. Conecte-se ao host on-premises
  3. Selecione a sub-rede a ser estendida
  4. Especifique a VNet e a sub-rede do Azure para estender
  5. Implante a VM appliance do Azure

Para detalhes, consulte a documentação do Azure Extended Network.


Cenários de quebra e correção

Cenário 1: Conflito de ASN do BGP

Sintoma: O peering BGP falha ao estabelecer. A conexão mostra Connected, mas nenhuma rota é aprendida.

Causa raiz: Tanto o VPN gateway do Azure quanto o dispositivo on-premises estão configurados com o mesmo ASN (ex.: ambos usando 65515).

Comando de diagnóstico:

az network vnet-gateway show \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--query "bgpSettings.asn" \
--output tsv

az network local-gateway show \
--resource-group rg-vpn-ha-lab \
--name lgw-dallas-bgp \
--query "bgpSettings.asn" \
--output tsv

Correção: Altere um dos lados para um ASN único:

az network vnet-gateway update \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--asn 65010

Cenário 2: Active-active com apenas um IP público

Sintoma: A criação do gateway falha ou volta para o modo active-standby.

Causa raiz: Apenas um IP público foi especificado em --public-ip-addresses ao criar o gateway. O modo active-active requer exatamente dois IPs públicos.

Correção: Recrie o gateway com dois IPs públicos (não é possível adicionar um segundo IP após a criação):

# Delete and recreate (gateway update cannot add active-active after creation)
az network vnet-gateway delete \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--no-wait

# Recreate with two public IPs
az network vnet-gateway create \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--vnet vnet-hub \
--gateway-type Vpn \
--vpn-type RouteBased \
--sku VpnGw2AZ \
--public-ip-addresses pip-vgw-hub-1 pip-vgw-hub-2 \
--active-active \
--no-wait

Cenário 3: SKU não-AZ em configuração com redundância de zona

Sintoma: O gateway é implantado, mas não sobrevive à falha de zona de disponibilidade. A inspeção mostra instâncias em uma única zona.

Causa raiz: Um SKU não-AZ (ex.: VpnGw2 em vez de VpnGw2AZ) foi usado. SKUs não-AZ implantam ambas as instâncias na mesma zona ou sem zona específica.

Comando de diagnóstico:

az network vnet-gateway show \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--query "sku.name" \
--output tsv
# Returns: VpnGw2 (should be VpnGw2AZ)

Correção: Recrie o gateway com um SKU AZ (a alteração de SKU requer exclusão e recriação):

az network vnet-gateway delete \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--no-wait

az network vnet-gateway create \
--resource-group rg-vpn-ha-lab \
--name vgw-hub-ha \
--vnet vnet-hub \
--gateway-type Vpn \
--vpn-type RouteBased \
--sku VpnGw2AZ \
--public-ip-addresses pip-vgw-hub-1 pip-vgw-hub-2 \
--active-active \
--no-wait

Verificação de conhecimento

1. Quantos endereços IP públicos são necessários para um VPN Gateway ativo-ativo?

2. Qual SKU de VPN Gateway fornece implantação com redundância de zona entre zonas de disponibilidade?

3. Qual é o ASN padrão atribuído aos Azure VPN Gateways se nenhum ASN personalizado for especificado?

4. Qual é o principal caso de uso do Azure Extended Network?

5. O que acontece durante a manutenção planejada do Azure em um VPN Gateway ativo-ativo?


Limpeza

Remova todos os recursos criados neste desafio para interromper a cobrança:

az group delete --name rg-vpn-ha-lab --yes --no-wait
Remove-AzResourceGroup -Name "rg-vpn-ha-lab" -Force -AsJob

Referências adicionais