Uso de VPN S2S como copia de seguridad para el emparejamiento privado de ExpressRoute
En el artículo titulado Diseño para la recuperación ante desastres con el emparejamiento privado de ExpressRoute, se describe la necesidad de una solución de conectividad de copia de seguridad al usar una conectividad de emparejamiento privado de ExpressRoute. También se ha explicado cómo usar circuitos ExpressRoute con redundancia geográfica para lograr una alta disponibilidad. En este artículo, vamos a explicar cómo usar y mantener la VPN de sitio a sitio (S2S) como copia de seguridad para el emparejamiento privado de ExpressRoute.
Nota:
No se recomienda usar una VPN de sitio a sitio como solución de copia de seguridad para la conectividad de ExpressRoute cuando se trabaja con cargas de trabajo críticas, con un uso intensivo de ancho de banda o sensibles a la latencia. En esos casos, es aconsejable diseñar para la recuperación ante desastres con resistencia multisitio de ExpressRoute a fin de garantizar la máxima disponibilidad.
A diferencia de los circuitos ExpressRoute con redundancia geográfica, solo puede usar la combinación de recuperación ante desastres de ExpressRoute-VPN en la configuración activa-pasiva. Un desafío importante del uso de cualquier conectividad de red de copia de seguridad en el modo pasivo es que la conexión pasiva a menudo falla junto con la conexión principal. El motivo común de los errores de la conexión pasiva es la falta de mantenimiento activo. Por lo tanto, en este artículo nos centraremos en cómo comprobar y mantener activamente la conectividad VPN S2S que realiza la copia de seguridad de un emparejamiento privado de ExpressRoute.
Nota
Cuando se anuncia una ruta determinada a través de ExpressRoute y VPN, Azure prefiere el enrutamiento a través de ExpressRoute.
En este artículo, también aprende a verificar la conectividad desde la perspectiva de Azure y desde el perímetro de red en el entorno local. La capacidad de validar desde cualquier extremo le ayuda, independientemente de si administra o no los dispositivos de red en el entorno local que se encuentran en el mismo nivel que las entidades de red de Microsoft.
Topología de ejemplo
En nuestra configuración, tenemos una red local conectada a una red virtual de la red virtual a través de un circuito ExpressRoute y una conexión VPN S2S. La red virtual del centro de Azure se empareja a su vez con una red virtual de radio, como se muestra en el diagrama:
En la instalación, el circuito ExpressRoute finaliza en un par de enrutadores de tipo "perimetral de cliente" (CE) en el entorno local. La LAN local se conecta a los enrutadores de CE a través de un par de firewalls que funcionan en modo líder-seguidor. La VPN S2S finaliza directamente en los firewalls.
En la tabla siguiente se enumeran los prefijos IP clave de la topología:
| Entidad | Prefijo |
|---|---|
| LAN local | 10.1.11.0/25 |
| Red virtual de Azure Hub | 10.17.11.0/25 |
| Red virtual de radios de Azure | 10.17.11.128/26 |
| Servidor de prueba local | 10.1.11.10 |
| Máquina virtual de prueba de red virtual de radio | 10.17.11.132 |
| Subred P2P de conexión principal de ExpressRoute | 192.168.11.16/30 |
| Subred P2P de conexión secundaria de ExpressRoute | 192.168.11.20/30 |
| IP del par BGP principal de VPN Gateway | 10.17.11.76 |
| IP del par BGP secundario de VPN Gateway | 10.17.11.77 |
| IP del par BGP de VPN del firewall local | 192.168.11.88 |
| I/f del enrutador de CE principal hacia la IP del firewall | 192.168.11.0/31 |
| I/f del firewall hacia la IP del enrutador de CE principal | 192.168.11.1/31 |
| I/f del enrutador de CE secundario hacia la IP del firewall | 192.168.11.2/31 |
| I/f del firewall hacia la IP del enrutador de CE secundario | 192.168.11.3/31 |
En la tabla siguiente se enumeran los ASN de la topología:
| Sistema autónomo | ASN |
|---|---|
| Local | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Virtual Network GW (ExR) | 65515 |
| Virtual Network GW (VPN) | 65515 |
Alta disponibilidad sin asimetría
Configuración para lograr alta disponibilidad
En el artículo Configuración de conexiones coexistentes de ExpressRoute y de sitio a sitio se explica cómo configurar conexiones VPN de ExpressRoute y S2S coexistentes. Como se mencionó en Diseño para alta disponibilidad con ExpressRoute, nuestra configuración garantiza la redundancia de red para eliminar cualquier único punto de error hasta los puntos de conexión, lo que mejora la alta disponibilidad de ExpressRoute. Además, las conexiones principales y secundarias de los circuitos ExpressRoute están activas y anuncian los prefijos locales de la misma manera a través de ambas conexiones.
A continuación, se muestra el anuncio de ruta local del enrutador de CE principal a través de la conexión principal del circuito ExpressRoute (comandos de Juno):
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
A continuación, se muestra el anuncio de ruta local del enrutador de CE secundario a través de la conexión secundaria del circuito ExpressRoute (comandos de Juno):
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 mejorar la alta disponibilidad de la conexión de copia de seguridad, VPN S2S también se configura en el modo activo-activo. La configuración de Azure VPN Gateway se muestra a continuación. Observe que, como parte de la configuración de VPN, también se enumeran las direcciones IP del par BGP de la puerta de enlace: 10.17.11.76 y 10.17.11.77.
La ruta local se anuncia mediante el firewall en los elementos del mismo nivel de BGP principal y secundario de la puerta de enlace de VPN. A continuación, se muestran los anuncios de ruta (Juno):
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
La configuración de VPN S2S en modo activo-activo no solo proporciona alta disponibilidad a la conectividad de red de copia de seguridad de recuperación ante desastres, sino que también proporciona un mayor rendimiento a la conectividad de copia de seguridad. Es decir, se recomienda la configuración de VPN S2S en modo activo-activo porque fuerza la creación de varios túneles subyacentes.
Configuración del flujo de tráfico simétrico
Hemos observado que, cuando una determinada ruta local se anuncia a través de ExpressRoute y VPN S2S, Azure prefiere la ruta de acceso de ExpressRoute. Para hacer que Azure prefiera una ruta de acceso de VPN S2S en lugar de la de ExpressRoute coexistente, debe anunciar rutas más específicas (prefijo más largo con máscara de subred mayor) a través de la conexión VPN. Nuestro objetivo es usar las conexiones VPN como copia de seguridad solamente. Por lo tanto, el comportamiento de la selección de la ruta de acceso predeterminada de Azure está en línea con nuestro objetivo.
Es nuestra responsabilidad asegurarnos de que el tráfico destinado a Azure desde el entorno local también prefiera la ruta de acceso de ExpressRoute en vez de la VPA de sitio a sitio. La preferencia local predeterminada de los enrutadores de CE y firewalls de la instalación local es 100. Por lo tanto, al configurar la preferencia local de las rutas recibidas a través de los emparejamientos privados de ExpressRoute mayores que 100, podemos hacer que el tráfico destinado a Azure prefiera el circuito ExpressRoute.
A continuación, se muestra la configuración de BGP del enrutador de CE principal que finaliza la conexión principal del circuito ExpressRoute. Tenga en cuenta que el valor de la preferencia local de las rutas anunciadas en la sesión de iBGP está configurado para que sea 150. Del mismo modo, debemos asegurarnos de que la preferencia local del enrutador de CE secundario que finaliza la conexión secundaria del circuito ExpressRoute también está configurada para que sea 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;
}
}
}
La tabla de enrutamiento de los firewalls locales confirma que, para el tráfico local destinado a Azure, la ruta de acceso preferida es a través de ExpressRoute en el estado estable.
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
En la tabla de rutas anterior, para las rutas de red virtual de concentrador y radio (10.17.11.0/25 y 10.17.11.128/26), vemos que se prefiere el circuito ExpressRoute a través de las conexiones VPN. 192.168.11.0 y 192.168.11.2 son direcciones IP de la interfaz de firewall hacia los enrutadores de CE.
Validación de intercambio de ruta a través de VPN S2S
Anteriormente en este artículo, comprobamos el anuncio de la ruta local de los firewalls a los pares BGP principal y secundario de VPN Gateway. Además, vamos a confirmar las rutas de Azure recibidas por los firewalls desde los pares BGP principal y secundario de VPN Gateway.
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
Del mismo modo, vamos a comprobar los prefijos de ruta de red locales recibidos por Azure VPN Gateway.
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 se indicó antes, VPN Gateway tiene rutas que han recibido los pares BGP principal y secundario de VPN Gateway. También tiene visibilidad sobre las rutas recibidas a través de las conexiones ExpressRoute principal y secundaria (las que tienen AS-path con el prefijo 12076). Para confirmar las rutas recibidas a través de conexiones VPN, debemos conocer la IP de las conexiones del par BGP local. En nuestra configuración en cuestión, la IP es 192.168.11.88 y vemos las rutas recibidas desde ella.
A continuación, vamos a comprobar las rutas anunciadas por Azure VPN Gateway en el par BGP del firewall (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
Si no se pueden ver los intercambios de ruta significa que hay un error de conexión. Vea Solución de problemas: la conexión VPN de sitio a sitio de Azure no puede conectarse y deja de funcionar para obtener ayuda en la solución de problemas con la conexión VPN.
Prueba de la conmutación por error
Ahora que confirmamos que los intercambios de ruta son correctos a través de la conexión VPN (plano de control), estamos listos para cambiar el tráfico (plano de datos) desde la conectividad de ExpressRoute a la conectividad de VPN.
Nota:
En entornos de producción, la prueba de conmutación por error debe realizarse durante la ventana de trabajo de mantenimiento de la red programada, ya que puede interrumpir el servicio.
Antes de llevar a cabo el cambio de tráfico, vamos a realizar un seguimiento de la ruta de acceso actual en nuestra instalación, desde el servidor de prueba local hasta la máquina virtual de prueba en la red virtual de radio.
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.
Las subredes de conexión punto a punto de ExpressRoute principal y secundaria de la instalación son, respectivamente, 192.168.11.16/30 y 192.168.11.20/30. En la ruta de seguimiento anterior, en el paso 3 vemos que estamos llegando a 192.168.11.18, que es la dirección IP de la interfaz de MSEE principal. La presencia de la interfaz de MSEE confirma que, como se esperaba, la ruta de acceso actual es a través de ExpressRoute.
Como se indica en Restablecimiento de emparejamientos de circuitos ExpressRoute, vamos a usar los siguientes comandos de PowerShell para deshabilitar el emparejamiento principal y secundario del circuito ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
El tiempo de cambio de la conmutación por error depende del tiempo de convergencia de BGP. En nuestra instalación, el cambio de conmutación por error tarda unos segundos (menos de 10). Después del cambio, la repetición de traceroute muestra la siguiente ruta de acceso:
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.
El resultado de traceroute confirma que la conexión de copia de seguridad a través de VPN S2S está activa y puede proporcionar continuidad de servicio si se produce un error en las conexiones de ExpressRoute principal y secundaria. Para completar las pruebas de conmutación por error, vuelva a habilitar las conexiones de ExpressRoute y normalice el flujo de tráfico con el siguiente conjunto de comandos.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Para confirmar que el tráfico se cambia de nuevo a ExpressRoute, repita el comando traceroute y asegúrese de que pasa por el emparejamiento privado de ExpressRoute.
Pasos siguientes
ExpressRoute está diseñado para ofrecer alta disponibilidad sin ningún punto único de error dentro de la red de Microsoft. Aun así, un circuito ExpressRoute se limita a una única región geográfica y a un proveedor de servicios. VPN S2S puede ser una buena solución de copia de seguridad pasiva de recuperación ante desastres para un circuito ExpressRoute. En el caso de una solución de conexión de copia de seguridad pasiva, es importante realizar un mantenimiento regular de la configuración pasiva y una validación periódica de la conexión. Es esencial no dejar que la configuración de VPN quede obsoleta y repetir de forma periódica (por ejemplo, cada trimestre) los pasos de prueba de validación y conmutación por error que se describen en este artículo durante la ventana de mantenimiento.
Para habilitar la supervisión y las alertas basadas en métricas de VPN Gateway, consulte Configuración de alertas en métricas de VPN Gateway.
Para agilizar la convergencia de BGP después de un error de ExpressRoute, consulte Configuración de BFD a través de ExpressRoute.