Usando a VPN S2S como um backup para o emparelhamento privado do ExpressRoute
No artigo intitulado Como projetar a recuperação de desastre com o emparelhamento privado do ExpressRoute, discutimos a necessidade de solução de conectividade de backup ao usar o emparelhamento privado do ExpressRoute. Também discutimos como usar circuitos do ExpressRoute com redundância geográfica para obter alta disponibilidade. Nesse artigo, vamos explicar como usar e manter a VPN S2S (site a site) como um backup para o emparelhamento privado do ExpressRoute.
Observação
O uso da VPN site a site como uma solução de backup para conectividade do ExpressRoute não é recomendado ao lidar com cargas de trabalho com uso intensivo de latência, críticas ou largura de banda. Nesses casos, é recomendável ter um design para recuperação de desastre com a resiliência de vários sites do ExpressRoute a fim de garantir a disponibilidade máxima.
Diferentemente dos circuitos do ExpressRoute com redundância geográfica, você pode usar a combinação do ExpressRoute e da VPN para recuperação de desastre somente no modo ativo-passivo. Um grande desafio de usar qualquer conectividade de rede de backup no modo passivo é que a conexão passiva geralmente falhará junto com a conexão primária. O motivo comum para as falhas da conexão passiva é a falta de manutenção ativa. Portanto, neste artigo, o foco é como verificar e manter ativamente a conectividade da VPN S2S que está fazendo backup de um emparelhamento privado do ExpressRoute.
Observação
Quando uma determinada rota é anunciada por meio do ExpressRoute e da VPN, o Azure prefere o roteamento pelo ExpressRoute.
Nesse artigo, também vamos aprender a verificar a conectividade da perspectiva do Azure e do lado da borda da rede local. A capacidade de validação por meio de uma dessas opções pode ajudar, mesmo que você não gerencie os dispositivos de rede do lado do cliente que são emparelhados com as entidades de rede da Microsoft.
Exemplo de topologia
Em nossa configuração, temos uma rede local conectada a uma rede virtual do Hub do Azure por meio de um circuito do ExpressRoute e de uma conexão VPN S2S. A rede virtual do Hub do Azure, por sua vez, é emparelhada com uma rede virtual spoke, conforme mostrado no diagrama:
Na configuração, o circuito do ExpressRoute é encerrado em um par de roteadores de CE (borda do cliente) no ambiente local. A LAN local é conectada aos roteadores de CE por meio de um par de firewalls que operam no modo seguidor-líder. A VPN S2S é encerrada diretamente nos firewalls.
A seguinte tabela lista os prefixos IP de chave da topologia:
| Entidade | Prefix |
|---|---|
| LAN local | 10.1.11.0/25 |
| Rede virtual do Hub do Azure | 10.17.11.0/25 |
| Rede virtual spoke do Azure | 10.17.11.128/26 |
| Servidor de teste local | 10.1.11.10 |
| VM de teste de rede virtual spoke | 10.17.11.132 |
| Sub-rede P2P de conexão primária do ExpressRoute | 192.168.11.16/30 |
| Sub-rede P2P de conexão secundária do ExpressRoute | 192.168.11.20/30 |
| IP do par no nível de protocolo BGP primário do gateway de VPN | 10.17.11.76 |
| IP do par no nível de protocolo BGP secundário do gateway de VPN | 10.17.11.77 |
| IP de par no nível de protocolo BGP da VPN de firewall local | 192.168.11.88 |
| i/f do roteador CE primário em relação ao IP do firewall | 192.168.11.0/31 |
| i/f do firewall em relação ao IP do roteador CE primário | 192.168.11.1/31 |
| i/f do roteador CE secundário em relação ao IP do firewall | 192.168.11.2/31 |
| i/f do firewall em relação ao IP do roteador CE secundário | 192.168.11.3/31 |
A seguinte tabela lista os ASNs da topologia:
| Sistema autônomo | ASN |
|---|---|
| Local | 65020 |
| Microsoft Enterprise Edge | 12076 |
| GW de Rede Virtual (ExR) | 65515 |
| GW de Rede Virtual (VPN) | 65515 |
Alta disponibilidade sem assimetria
Como configurar para alta disponibilidade
O artigo Configurar as conexões coexistentes do ExpressRoute e site a site discute como configurar o circuito do ExpressRoute e as conexões VPN S2S coexistentes. Como mencionamos em Design para alta disponibilidade com o ExpressRoute, nossa configuração garante a redundância de rede para eliminar qualquer ponto único de falha até os pontos de extremidade, o que melhora a alta disponibilidade do ExpressRoute. Além disso, as conexões primárias e secundárias dos circuitos do ExpressRoute estão ativas e anunciam os prefixos locais da mesma maneira por meio das duas conexões.
O anúncio de rota local do roteador de CE primário por meio da conexão primária do circuito do ExpressRoute é mostrado abaixo (comandos Junos):
user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18
Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
O anúncio de rota local do roteador de CE secundário por meio da conexão secundária do circuito do ExpressRoute é mostrado abaixo (comandos Junos):
user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22
Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Para aprimorar a alta disponibilidade da conexão de backup, a VPN S2S também é configurada no modo ativo-ativo. A configuração do gateway de VPN do Azure é mostrada abaixo. Observe que, como parte da VPN de configuração de VPN, os endereços IP do par no nível de protocolo BGP do gateway – 10.17.11.76 e 10.17.11.77 – também estão listados.
A rota local é anunciada pelos firewalls para os pares de BGP primários e secundários do gateway de VPN. Os anúncios de rota são mostrados abaixo (Junos):
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Observação
A configuração da VPN S2S no modo ativo-ativo fornece alta disponibilidade à conectividade de rede de backup de recuperação de desastre e também uma taxa de transferência maior para a conectividade de backup. Portanto, é recomendável configurar a VPN S2S no modo ativo-ativo, pois isso criará vários túneis subjacentes.
Como configurar para fluxo de tráfego simétrico
Observamos que, quando uma determinada rota local é anunciada por meio do ExpressRoute e da VPN S2S, o Azure prefere o caminho do ExpressRoute. Para forçar o Azure a preferir o caminho da VPN S2S em vez do ExpressRoute coexistente, você precisa anunciar rotas mais específicas (prefixo mais longo com maior máscara de sub-rede) por meio da conexão VPN. Nosso objetivo é usar as conexões VPN somente como backup. Portanto, o comportamento de seleção de caminho padrão do Azure está de acordo com nosso objetivo.
É nossa responsabilidade garantir que o tráfego do ambiente local destinado ao Azure também prefira o caminho do ExpressRoute em vez da VPN site a site. A preferência local padrão dos roteadores e firewalls CE em nossa configuração local é 100. Portanto, ao configurar a preferência local das rotas recebidas por meio dos emparelhamentos privados do ExpressRoute maiores que 100, podemos fazer com que o tráfego destinado ao Azure prefira o circuito do ExpressRoute.
A configuração de BGP do roteador de CE primário que encerra a conexão primária do circuito do ExpressRoute é mostrada abaixo. Observe que o valor da preferência local das rotas anunciadas pela sessão iBGP está configurado para ser 150. Da mesma forma, precisamos garantir que a preferência local do roteador secundário do CE que termina a conexão secundária do circuito de ExpressRoute também esteja configurada para ser 150.
user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
bgp {
group ibgp {
type internal;
local-preference 150;
neighbor 192.168.11.1;
}
group ebgp {
peer-as 12076;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
}
neighbor 192.168.11.18;
}
}
}
A tabela de roteamento dos firewalls locais confirma que, para o tráfego local destinado ao Azure, o caminho preferencial é pelo ExpressRoute no estado estável.
user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.17.11.0/25 *[BGP/170] 2d 00:34:04, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.0 via reth1.11
to 192.168.11.2 via reth2.11
[BGP/170] 2d 00:34:01, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.2 via reth2.11
[BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
AS path: 65515 I, validation-state: unverified
> via st0.118
[BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
AS path: 65515 I, validation-state: unverified
> via st0.119
10.17.11.76/32 *[Static/5] 2d 21:12:16
> via st0.118
10.17.11.77/32 *[Static/5] 2d 00:41:56
> via st0.119
10.17.11.128/26 *[BGP/170] 2d 00:34:04, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.0 via reth1.11
to 192.168.11.2 via reth2.11
[BGP/170] 2d 00:34:01, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.2 via reth2.11
[BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
AS path: 65515 I, validation-state: unverified
> via st0.118
[BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
AS path: 65515 I, validation-state: unverified
> via st0.119
Na tabela de rotas acima, para as rotas de VNet de hub e spoke – 10.17.11.0/25 e 10.17.11.128/26 – vemos que o circuito do ExpressRoute é preferencial em conexões VPN. O 192.168.11.0 e o 192.168.11.2 são IPs na interface de firewall em direção aos roteadores CE.
Validação da troca de rota pela VPN S2S
Anteriormente neste artigo, verificamos o anúncio de rota local dos firewalls para os pares de BGP primários e secundários do gateway de VPN. Além disso, vamos confirmar as rotas do Azure recebidas pelos firewalls dos pares de BGP primários e secundários do gateway de VPN.
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.17.11.0/25 10.17.11.76 65515 I
10.17.11.128/26 10.17.11.76 65515 I
{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.17.11.0/25 10.17.11.77 65515 I
10.17.11.128/26 10.17.11.77 65515 I
Da mesma forma, vamos verificar prefixos de rota de rede local recebidos pelo gateway de VPN do Azure.
PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight
Network NextHop AsPath Weight
------- ------- ------ ------
10.1.11.0/25 192.168.11.88 65020 32768
10.1.11.0/25 10.17.11.76 65020 32768
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 192.168.11.88 65020 32768
10.1.11.0/25 10.17.11.77 65020 32768
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 10.17.11.69 12076-65020 32769
Como já visto, o Gateway de VPN tem rotas recebidas pelos pares BGP primário e secundário do Gateway de VPN. Ele também tem visibilidade sobre as rotas recebidas por meio de conexões primárias e secundárias do ExpressRoute (aquelas com caminho AS precedido por 12076). Para confirmar as rotas recebidas por meio de conexões VPN, precisamos saber o IP do par no nível de protocolo BGP local das conexões. Na configuração em questão, o IP é 192.168.11.88 e vemos as rotas recebidas dele.
Em seguida, vamos verificar as rotas anunciadas pelo gateway de VPN do Azure para o par no nível de protocolo BGP do firewall local (192.168.11.88).
PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | select Network, NextHop, AsPath, Weight
Network NextHop AsPath Weight
------- ------- ------ ------
10.17.11.0/25 10.17.11.76 65515 0
10.17.11.128/26 10.17.11.76 65515 0
10.17.11.0/25 10.17.11.77 65515 0
10.17.11.128/26 10.17.11.77 65515 0
Falha ao ver as trocas de rota indica falha de conexão. Confira Solucionar problemas: uma conexão VPN site a site do Azure não pode se conectar e para de funcionar para obter ajuda com a solução de problemas de conexão de VPN.
Como testar um failover
Agora que confirmamos as trocas de rota bem-sucedidas na conexão VPN (plano de controle), estamos prontos para mudar o tráfego (plano de dados) da conectividade do ExpressRoute para a conectividade da VPN.
Observação
Em ambientes de produção, o teste de failover deve ser feito durante a janela de trabalho de manutenção de rede agendada, pois pode causar interrupções no serviço.
Antes de fazer a alternância de tráfego, vamos rastrear a rota do caminho atual em nossa configuração do servidor de teste local para a VM de teste na VNet do spoke.
C:\Users\PathLabUser>tracert 10.17.11.132
Tracing route to 10.17.11.132 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.1.11.1
2 <1 ms <1 ms 11 ms 192.168.11.0
3 <1 ms <1 ms <1 ms 192.168.11.18
4 * * * Request timed out.
5 6 ms 6 ms 5 ms 10.17.11.132
Trace complete.
As sub-redes de conexão ponto a ponto primária e secundária do ExpressRoute de nossa configuração são, respectivamente, 192.168.11.16/30 e 192.168.11.20/30. Na rota de rastreamento acima, na etapa 3, vemos que estamos atingindo 192.168.11.18, que é o IP da interface do MSEE primário. A presença da interface MSEE confirma que, conforme o esperado, o caminho atual é pelo ExpressRoute.
Conforme relatado em Redefinir emparelhamentos de circuito do ExpressRoute, vamos usar os comandos do PowerShell a seguir para desabilitar os emparelhamentos primário e secundário do circuito do ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
O tempo de alternância de failover depende do tempo de convergência de BGP. Em nossa configuração, a opção de failover leva alguns segundos (menos de 10). Após a mudança, a repetição do rastreamento de rota mostra o seguinte caminho:
C:\Users\PathLabUser>tracert 10.17.11.132
Tracing route to 10.17.11.132 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.1.11.1
2 * * * Request timed out.
3 6 ms 7 ms 9 ms 10.17.11.132
Trace complete.
O resultado do rastreamento de rota confirma que a conexão de backup via VPN S2S está ativa e poderá fornecer continuidade de serviço se as conexões primárias e secundárias do ExpressRoute falharem. Para concluir o teste de failover, vamos reabilitar as conexões do ExpressRoute e normalizar o fluxo de tráfego usando o conjunto de comandos a seguir.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Para confirmar se o tráfego é revertido para o ExpressRoute, repita o rastreamento de rota e verifique se ele está passando pelo emparelhamento privado do ExpressRoute.
Próximas etapas
O ExpressRoute foi projetado para alta disponibilidade sem ponto único de falha na rede da Microsoft. Ainda assim, um circuito do ExpressRoute é restrito a uma só região geográfica e a um provedor de serviços. A VPN S2S pode ser uma boa solução de backup passivo de recuperação de desastre para um circuito do ExpressRoute. Para uma solução de conexão de backup passiva confiável, a manutenção regular da configuração passiva e a validação periódica da conexão são importantes. É essencial não permitir que a configuração de VPN fique obsoleta e, periodicamente (digamos, a cada trimestre) repetir as etapas de teste de validação e de failover descritas neste artigo durante a janela de manutenção.
Para habilitar o monitoramento e alertas com base em métricas de Gateway de VPN, consulte Configurar alertas em métricas de Gateway de VPN.
Para agilizar a convergência de BGP após uma falha do ExpressRoute, Configure o BFD no ExpressRoute.