Usando o S2S VPN como backup para emparelhamento privado da Rota Expressa
No artigo intitulado Projetando para recuperação de desastres com emparelhamento privado da Rota Expressa, discutimos a necessidade de uma solução de conectividade de backup ao usar o emparelhamento privado da Rota Expressa. Também discutimos como usar circuitos de Rota Expressa com redundância geográfica para alta disponibilidade. Neste artigo, explicamos como usar e manter uma VPN site a site (S2S) como backup para emparelhamento privado da Rota Expressa.
Nota
O uso de VPN site a site como uma solução de backup para conectividade de Rota Expressa não é recomendado ao lidar com cargas de trabalho sensíveis à latência, de missão crítica ou que consomem muita largura de banda. Nesses casos, é aconselhável projetar para recuperação de desastres com a resiliência multissite do ExpressRoute para garantir a máxima disponibilidade.
Ao contrário dos circuitos de Rota Expressa com redundância geográfica, você só pode usar a combinação de recuperação de desastres ExpressRoute e VPN em uma configuração ativa-passiva. Um grande desafio de usar qualquer conectividade de rede de backup no modo passivo é que a conexão passiva muitas vezes falharia ao lado da conexão principal. A razão comum para as falhas da conexão passiva é a falta de manutenção ativa. Portanto, neste artigo, o foco está em como verificar e manter ativamente uma conectividade VPN S2S que está fazendo backup de um emparelhamento privado da Rota Expressa.
Nota
Quando uma determinada rota é anunciada por meio da Rota Expressa e da VPN, o Azure prefere o roteamento em vez da Rota Expressa.
Neste artigo, você também aprenderá a verificar a conectividade da perspetiva do Azure e do lado da borda da rede local. A capacidade de validar de ambos os lados ajuda, independentemente de você gerenciar ou não os dispositivos de rede locais que fazem par com as entidades de rede da Microsoft.
Exemplo de topologia
Em nossa configuração, temos uma rede local conectada a uma rede virtual de hub do Azure por meio de um circuito ExpressRoute e uma conexão VPN S2S. A rede virtual do hub do Azure, por sua vez, é emparelhada a uma rede virtual falada, conforme mostrado no diagrama:
Na configuração, o circuito ExpressRoute é encerrado em um par de roteadores de borda do cliente (CE) no local. A LAN local está conectada aos roteadores CE com um par de firewalls que operam no modo líder-seguidor. A VPN S2S é encerrada diretamente nos firewalls.
A tabela a seguir lista os principais prefixos IP da topologia:
| Entidade | Prefixo |
|---|---|
| LAN local | 10.1.11.0/25 |
| Rede virtual do Hub do Azure | 10.17.11.0/25 |
| Rede virtual falada 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 da conexão primária da Rota Expressa | 192.168.11.16/30 |
| Sub-rede P2P de conexão secundária de Rota Expressa | 192.168.11.20/30 |
| IP de peer BGP primário do gateway VPN | 10.17.11.76 |
| IP de par BGP secundário do gateway VPN | 10.17.11.77 |
| Firewall local VPN BGP peer IP | 192.168.11.88 |
| Roteador CE primário i / f para firewall IP | 192.168.11.0/31 |
| Firewall i / f para IP primário do roteador CE | 192.168.11.1/31 |
| Roteador CE secundário i / f para firewall IP | 192.168.11.2/31 |
| Firewall i / f para IP secundário do roteador CE | 192.168.11.3/31 |
A tabela a seguir lista os ASNs da topologia:
| Sistema autónomo | ASN |
|---|---|
| No local | 65020 |
| Borda Empresarial da Microsoft | 12076 |
| Rede Virtual GW (ExR) | 65515 |
| Rede Virtual GW (VPN) | 65515 |
Alta disponibilidade sem assimetria
Configuração para alta disponibilidade
O artigo Configurar conexões coexistentes de Rota Expressa e Site a Site explica como configurar conexões coexistentes de Rota Expressa e VPN S2S. Como mencionamos em Projetando para alta disponibilidade com a Rota Expressa, nossa configuração garante redundância de rede para eliminar qualquer ponto único de falha até os pontos de extremidade, o que melhora a alta disponibilidade da Rota Expressa. Além disso, as conexões primária e secundária dos circuitos de Rota Expressa estão ativas e anunciam os prefixos locais da mesma maneira através de ambas as conexões.
O anúncio de rota local do roteador CE primário através da conexão primária do circuito ExpressRoute é mostrado da seguinte forma (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 CE secundário através da conexão secundária do circuito ExpressRoute é mostrado da seguinte forma (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 melhorar 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 da seguinte maneira. Observe que, como parte da VPN de configuração, os endereços IP de mesmo nível BGP do gateway--10.17.11.76 e 10.17.11.77--também estão listados.
A rota local é anunciada pelo firewall para os pares BGP primários e secundários do gateway VPN. Os anúncios de rota são mostrados da seguinte forma (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
Nota
Configurar a VPN S2S no modo ativo-ativo não apenas fornece alta disponibilidade para sua conectividade de rede de backup de recuperação de desastres, mas também fornece maior taxa de transferência para a conectividade de backup. Portanto, a configuração do S2S VPN no modo ativo-ativo é recomendada, pois criará vários túneis subjacentes.
Configuração para fluxo de tráfego simétrico
Observamos que, quando uma determinada rota local é anunciada por meio da Rota Expressa e da VPN S2S, o Azure prefere o caminho da Rota Expressa. Para forçar o Azure a preferir o caminho VPN S2S em vez da Rota Expressa coexistente, você precisa anunciar rotas mais específicas (prefixo mais longo com máscara de sub-rede maior) por meio da conexão VPN. Nosso objetivo é usar as conexões VPN apenas como backup. Portanto, o comportamento de seleção de caminho padrão do Azure está alinhado com nosso objetivo.
É nossa responsabilidade garantir que o tráfego destinado ao Azure a partir do local também prefira o caminho da Rota Expressa em vez da VPN Site a Site. A preferência local padrão dos roteadores CE e firewalls em nossa configuração local é 100. Assim, ao configurar a preferência local das rotas recebidas através dos emparelhamentos privados da Rota Expressa superiores a 100, podemos fazer com que o tráfego destinado ao Azure prefira o circuito da Rota Expressa.
A configuração BGP do roteador CE primário que termina a conexão primária do circuito ExpressRoute é mostrada da seguinte maneira. Observe que o valor da preferência local das rotas anunciadas sobre a sessão iBGP está configurado para ser 150. Da mesma forma, precisamos garantir que a preferência local do roteador CE secundário que encerra a conexão secundária do circuito 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 está sobre a Rota Expressa no estado estacionário.
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 rede virtual hub e spoke - 10.17.11.0/25 e 10.17.11.128/26 - vemos que o circuito ExpressRoute é preferido em relação às conexões VPN. O 192.168.11.0 e 192.168.11.2 são IPs na interface de firewall para roteadores CE.
Validação da troca de rotas através de VPN S2S
No início deste artigo, verificamos o anúncio de rota local dos firewalls para os pares BGP primários e secundários do gateway VPN. Além disso, vamos confirmar as rotas do Azure recebidas pelos firewalls dos pares 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 se há 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 visto anteriormente, o gateway VPN tem rotas recebidas pelos pares BGP primário e secundário do gateway VPN. Ele também tem visibilidade sobre as rotas recebidas através de conexões ExpressRoute primárias e secundárias (aquelas com caminho AS prepended com 12076). Para confirmar as rotas recebidas via conexões VPN, precisamos saber o IP do par BGP local das conexões. Em nossa configuração em consideraçã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 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
A falha em ver as trocas de rotas indica falha de conexão. Consulte Solução de 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 da conexão VPN.
Testando failover
Agora que confirmamos trocas de rotas bem-sucedidas pela conexão VPN (plano de controle), estamos prontos para alternar o tráfego (plano de dados) da conectividade ExpressRoute para a conectividade VPN.
Nota
Em ambientes de produção, o teste de failover deve ser feito durante a janela de trabalho de manutenção programada da rede, pois pode causar interrupções no serviço.
Antes de fazer a troca de tráfego, vamos rastrear o caminho atual em nossa configuração do servidor de teste local para a VM de teste na rede virtual 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árias e secundárias da Rota Expressa 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, como esperado, nosso caminho atual está na Rota Expressa.
Conforme relatado nos emparelhamentos de circuito Reset ExpressRoute, vamos usar os seguintes comandos do PowerShell para desabilitar o emparelhamento primário e secundário do circuito ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
O tempo do comutador de failover depende do tempo de convergência do BGP. Em nossa configuração, o switch de failover leva alguns segundos (menos de 10). Após a opção, a repetição do traceroute 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 traceroute confirma que a conexão de backup via VPN S2S está ativa e pode fornecer continuidade de serviço se as conexões primária e secundária da Rota Expressa falharem. Para concluir o teste de failover, vamos habilitar as conexões de Rota Expressa de volta e normalizar o fluxo de tráfego, usando o seguinte conjunto de comandos.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Para confirmar se o tráfego foi alternado de volta para a Rota Expressa, repita o traceroute e verifique se ele está passando pelo emparelhamento privado da Rota Expressa.
Próximos passos
O ExpressRoute foi projetado para alta disponibilidade sem ponto único de falha na rede Microsoft. Ainda assim, um circuito de Rota Expressa está confinado a uma única região geográfica e a um prestador de serviços. O S2S VPN pode ser uma boa solução de backup passivo de recuperação de desastres para um circuito 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 deixar a configuração da VPN ficar obsoleta e repetir periodicamente (digamos a cada trimestre) as etapas de teste de validação e failover descritas neste artigo durante a janela de manutenção.
Para habilitar o monitoramento e os alertas com base nas métricas do gateway VPN, consulte Configurar alertas nas métricas do gateway VPN.
Para agilizar a convergência de BGP após uma falha de Rota Expressa, configure o BFD sobre a Rota Expressa.