ExpressRoute más VPN: ¿qué dominios de fallo cubre usted?

Un túnel IPsec que se ejecuta sobre el emparejamiento privado de ExpressRoute añade cifrado a un transporte que ya existe. Un segundo túnel mejora la disponibilidad del extremo y no hace absolutamente nada por la ruta del operador que hay debajo de ambos. Esa distinción se pierde con facilidad cuando los paneles muestran dos túneles verdes y la revisión de diseño plantea otra pregunta: ¿qué fallos debe sobrevivir esta conexión? Responda eso primero y luego cuente túneles, porque el número de indicadores verdes es una propiedad de la capa de cifrado y el número de dominios de fallo es una propiedad del camino completo.

Empiece por los fallos, no por los túneles verdes

Escriba cuatro filas antes de dibujar nada: el fallo de un extremo de VPN o de una instancia de par, el fallo de un enrutador local o de una conexión de primera milla, el fallo del camino compartido de ExpressRoute y la indisponibilidad de IPsec mientras el emparejamiento privado sigue transportando tráfico. Cada fila nombra lo que el diseño debe preservar, y a cada una responde un mecanismo distinto.

Microsoft documenta la VPN de sitio a sitio con IP privadas sobre el emparejamiento privado de ExpressRoute, y la coexistencia admitida con conexiones de sitio a sitio basadas en internet. Esa coexistencia es un diseño distinto de la capa inferior y no aparece solo porque haya añadido otro extremo de túnel privado.

Dominio de fallo 1: el extremo de VPN

Dos túneles en una puerta de enlace suelen ser parejas activo-activo que terminan en el mismo recurso del lado de Azure. Protegen frente a un problema de un solo túnel o instancia, y no protegen frente a que ese recurso quede no disponible, se reconfigure o se quede sin capacidad. La redundancia de extremo significa un segundo extremo admitido, con su propio camino y su propia configuración, más una ruta que pueda alcanzarlo.

Compruebe qué ha desplegado realmente y no qué dice el diagrama, porque el portal agrupa estos recursos de formas que ocultan su relación:

az network vpn-connection show -g rg-connectivity -n vpn-to-hub   --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub   --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'

Si ambos túneles apuntan a una puerta de enlace con una IP pública, tiene una redundancia de extremo de un tipo concreto y limitado. Puede que sea exactamente lo que pide el requisito, y debería decirse así en lugar de describirlo como una conexión redundante.

Dominio de fallo 2: el camino local y el operador

Bajo el cifrado hay una realidad física y comercial: un dispositivo de borde del cliente, una interconexión, una red de proveedor y una ubicación de emparejamiento. las directrices de disponibilidad de ExpressRoute son explícitas en que la redundancia de extremo a extremo incluye los segmentos del cliente y del proveedor de servicios, no solo el lado de Microsoft. Dos caminos lógicos que comparten un enrutador, una alimentación eléctrica o una conexión de primera milla siguen compartiendo esa dependencia.

Aquí es donde un diseño suele suspender una revisión honesta. Dos circuitos del mismo proveedor, que terminan en el mismo edificio, sobre equipos del mismo pedido de compra, no son dos dominios de fallo. Son un dominio de fallo con dos facturas.

Pregunte al operador por escrito: cuáles de estos caminos divergen, dónde, y cuál es el comportamiento documentado cuando falla el segmento compartido. Una garantía verbal durante una llamada de diseño no sobrevive a la caída para la que está diseñando.

Dominio de fallo 3: la ruta que sobrevive sin IPsec

El emparejamiento privado e IPsec pueden ofrecer rutas competidoras hacia el mismo prefijo de aplicación. Si la ruta protegida desaparece, una ruta directa de ExpressRoute superviviente todavía puede ser utilizable, sin la capa de cifrado que proporcionaba el túnel. Si eso es aceptable es una decisión de política, y es la decisión que más a menudo se deja implícita.

Los requisitos de cifrado y los de disponibilidad pueden entrar aquí en conflicto real. «Cualquier ruta superviviente cuenta como éxito» es una afirmación de disponibilidad que responde en voz baja a la pregunta del cifrado con un «no». Anote cuál gana, para qué prefijos y quién lo aprobó.

az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table

Compare las rutas aprendidas con los prefijos que esperaba. Una ruta alternativa que transporta una carga administrativa pequeña puede ser perfectamente adecuada para esa carga y quedar muy lejos de la capacidad que necesita la demanda de producción, así que anote la suposición de capacidad junto a la ruta.

Anote tres filas separadas, no un solo veredicto

Mantenga la redundancia de extremo, la redundancia de transporte y la recuperación ante desastres como entradas separadas en el registro de diseño, cada una con su propio mecanismo, su propia verificación y su propio responsable. Cuando una revisión de incidente pregunta por qué la conexión sobrevivió a un reinicio de puerta de enlace pero no a un corte de fibra, tres filas responden en una frase; una sola casilla de «redundante» no puede.

Después pruebe las filas que pueda probar barato. Haga fallar un túnel y confirme que el tráfico se mueve y se vuelve a cifrar. Retire una ruta y confirme que el camino superviviente es el que pretendía, y luego confirme si sigue cifrado. Documente los fallos que no pudo simular, porque una fila no probada es una suposición y debería etiquetarse como tal.

La salida útil es una tabla corta más una frase por fila. Si una fila no tiene mecanismo, ese es el hallazgo, y es mucho más barato descubrirlo en una revisión de diseño que durante una caída del operador que ninguno de los dos túneles habría sobrevivido.