Un flujo de la sucursal a Azure puede enrutarse correctamente en ambos sentidos y aun así fallar, porque los dos sentidos toman dispositivos distintos. La petición sale de la sucursal por la VPN, aterriza en NVA A y llega a la carga de trabajo. La respuesta sale de la carga de trabajo, coincide con una ruta que apunta a NVA B y muere allí. Todas las rutas de esa imagen son válidas, y la sesión TCP sigue rota.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Ese hueco es todo el tema aquí: la convergencia de enrutamiento y la propiedad del estado de sesión son problemas distintos que en un diagrama parecen idénticos.

Qué programa realmente Route Server

Azure Route Server establece peering con los hablantes BGP admitidos, aprende sus rutas y las programa en las rutas efectivas de la red virtual. Es un trabajo de plano de control. No lee la tabla de sesiones de un firewall de proveedor y no tiene idea de qué dispositivo admitió una conexión concreta. Dos saltos siguientes de igual coste son, para este tejido, simplemente dos formas de alcanzar el mismo prefijo, y usará cualquiera de las dos.

Aprender una ruta demuestra, por tanto, accesibilidad. No demuestra nada sobre si el dispositivo del otro extremo ha visto antes este flujo.

Lea ambos sentidos antes de diseñar

Empiece por anotar el direccionamiento que realmente tiene en cada sentido, no el que pretendía. Las rutas BGP más específicas, las rutas definidas por el usuario y el comportamiento de la puerta de enlace compiten todas, y el ganador se decide por destino, no por sesión. Una ruta predeterminada en la NVA no significa que todos los prefijos privados pasen por ella.

Una comprobación útil es preguntar, para una IP concreta de carga de trabajo, a qué salto siguiente resuelve cada sentido. Si la respuesta son dos dispositivos distintos, tiene un problema de asimetría tanto si ya ha aparecido como si no.

Dónde vive el estado

Un firewall con estado admite una conexión y mantiene una entrada de tabla con clave de la quíntupla. La respuesta debe llegar al dispositivo que tiene esa entrada, o ese dispositivo debe obtener el estado de otra forma. Nada en el plano de datos de Azure reenvía la entrada entre dispositivos. O el tráfico se dirige de vuelta al propietario, o los dispositivos comparten estado mediante un mecanismo del proveedor, o el diseño no funciona.

Por eso dos NVA sanas no son una comprobación de salud para la inspección. La salud trata de la accesibilidad; la inspección trata de qué instancia tiene la sesión.

Modelos de HA admitidos y qué promete cada uno

Microsoft's guidance on la intención de enrutamiento de Virtual WAN describe un comportamiento limitado para la conectividad de doble rol y las NVA de firewall, donde el enrutamiento directo puede eludir la aplicación simétrica normal del concentrador. Lea esas notas como restricciones a la topología elegida, no como una prohibición de los diseños activo-activo. Un par de proveedor que sincroniza estado o direcciona por flujo puede admitirse. Un par de igual coste que no hace ninguna de las dos cosas no lo es.

Después defina qué ocurre con las sesiones existentes cuando falla un nodo. La convergencia de rutas restaura la accesibilidad para los flujos nuevos en segundos, mientras que el estado antiguo del firewall simplemente desaparece. La reconexión del cliente puede ser el resultado documentado, y esa es una decisión que se toma antes del incidente, no durante.

Qué probar antes de confiar en ello

Test with inspection enabled and la política de acceso de la carga de trabajo en su sitio, porque cualquiera de las dos puede ocultar la asimetría. Envíe un flujo autorizado nuevo en ambos sentidos y confirme que el mismo dispositivo vio las dos mitades. Luego ejecute tráfico sostenido y active la conmutación por error aprobada, observando si las sesiones establecidas sobreviven o se reconectan.

Correlacione cada flujo con el dispositivo que lo gestionó. Una captura de paquetes en una NVA no le dice casi nada si la respuesta nunca volvió a ella.

Por último, escriba el plan en tres líneas separadas: propiedad de las rutas, direccionamiento del tráfico y propiedad del estado de sesión. Los diseños se rompen cuando las dos primeras están resueltas y la tercera se da por supuesta.

Artículos relacionados