Dos direcciones VPN locales: dos pares de Azure, no uno

El diagrama tiene dos enlaces de internet en la sucursal y una puerta de enlace VPN de Azure, así que la puerta de enlace de red local recibe ambas direcciones públicas. Se ve ordenado y no funciona como el diagrama implica. Cada dispositivo VPN local es una relación de par independiente, y el diseño de varios dispositivos de Microsoft da a cada uno su propio recurso de puerta de enlace de red local y su propia conexión. Añadir una segunda dirección a un solo recurso no crea un segundo par. Crea un recurso que no describe correctamente ninguno de los dos dispositivos.

El mito: una puerta de enlace, dos direcciones

Una puerta de enlace de red local es la descripción de un par remoto: un extremo público y los prefijos privados que hay detrás. No hay forma compatible de hacer que ese recurso signifique «cualquiera de estos dos dispositivos».

La misma confusión va en la otra dirección, donde dos IP públicas de Azure se leen como prueba de que existen dos puertas de enlace de Azure.

Cuente los objetos y luego los túneles

Tome dos dispositivos locales operados de forma independiente, cada uno con su propia dirección pública y acceso a las mismas redes privadas, más una puerta de enlace de Azure basada en rutas en modo activo-activo. La puerta de enlace de Azure tiene dos instancias activas con IP públicas separadas. Cada dispositivo local se conecta a ambas instancias. Esa es la malla completa, y el recuento de objetos se deriva de ella, no del diagrama.

La aritmética es lo bastante corta para pegarla en el documento de diseño:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Un recurso de conexión puede transportar más de un túnel subyacente, así que cuatro túneles no implican cuatro puertas de enlace de red virtual. Dos IP públicas de Azure tampoco son los mismos objetos que las dos puertas de enlace de red local que describen el sitio remoto.

Qué añade el activo-activo en el lado de Azure

El activo-activo cambia la puerta de enlace de Azure de una instancia activa a dos, cada una con su propia IP pública, y es lo que hace posible una malla completa. No duplica el rendimiento de un solo flujo. Tampoco elimina la necesidad de que el lado local admita multipath de igual coste si ambos dispositivos reenvían a la vez. Confirme el modo de la puerta de enlace, la SKU y la capacidad del dispositivo remoto antes de aprovisionar nada.

Una puerta de enlace en espera pasiva es un diseño perfectamente válido; simplemente produce un recuento de túneles distinto.

BGP hace utilizables ambos caminos

Para el diseño de varios dispositivos, ambos dispositivos locales ejecutan BGP. Dé a cada uno una dirección de par BGP única y anuncie los mismos prefijos privados previstos por los caminos relevantes. Los prefijos privados identifican las redes protegidas, mientras que las direcciones públicas identifican dónde terminan las conexiones de transporte cifradas. Confundir ambas produce un diseño en el que todos los túneles están activos y las rutas son incorrectas.

Planifique el enrutamiento de retorno y cualquier inspección con estado que deba tolerar cualquiera de los dos caminos. Una sesión IKE sana en cada extremo no demuestra que una carga de trabajo pueda usar cada ruta anunciada.

La selección por flujo no es agrupación de ancho de banda

Azure selecciona un camino por flujo mediante un hash sobre el direccionamiento y los puertos del flujo. En estado estacionario, los paquetes de un flujo TCP o UDP determinado suelen tomar el mismo túnel, y el lado local puede elegir otro túnel para la dirección de retorno. Por tanto, dos dispositivos y cuatro túneles mejoran la disponibilidad, no la velocidad de una transferencia. Cuando una diapositiva del proveedor promete agregación, describe otra función o un malentendido.

Pruebe con flujos paralelos si quiere ver cómo se reparten los caminos, y con un solo flujo si quiere ver el límite.

Qué redundancia ha eliminado realmente

Dos direcciones WAN en un solo dispositivo mejoran las opciones de enlace de acceso mientras comparten la alimentación, el software y el estado de fallo de ese dispositivo. No son lo mismo que dos dispositivos, y ninguna configuración del lado de Azure lo cambia. Siga el diseño de doble WAN o de clúster compatible del proveedor en lugar de inferir redundancia del número de direcciones. Luego pruébelo: retire un camino cada vez y confirme las rutas restantes más un intercambio real de aplicación en ambos sentidos.

Espere retrasos de detección y convergencia, y espere que algunas sesiones existentes terminen.