Migrar una subred a un nuevo túnel VPN sin cortes

Levante el túnel nuevo, mueva una subred y esa subred ahora falla de forma intermitente mientras todo lo demás funciona perfectamente. Las VPN migradas a medias fallan exactamente así, porque el túnel nunca fue la parte difícil. La ruta también incluye qué ruta gana, qué selectores coinciden, qué permiten las reglas de acceso, cómo vuelven las respuestas y cualquier traducción que aplicara el diseño antiguo. Mueva solo el túnel y no habrá movido nada de eso.

El túnel es la mitad fácil de la ruta

Los fallos intermitentes tras una migración parcial suelen significar que dos rutas son ambas plausibles. Algunos flujos eligen el túnel nuevo, otros se quedan con el viejo, y un dispositivo que recuerda el estado ve entonces llegar una respuesta por una ruta que la petición nunca usó. Dos rutas no son automáticamente más seguras que una; son dos cosas que pueden discrepar. Mire los informes de oscilación y no los contadores del túnel, porque los contadores se verán sanos todo el tiempo.

La primera pregunta útil no es qué túnel es mejor. Es qué flujos eligen qué ruta hoy y si la petición y la respuesta obtienen la misma respuesta.

Construya el destino antes de preferirlo

Confirme que los pares son compatibles y que el túnel nuevo lleva el ámbito de direcciones que pretende. Añada el reenvío y los permisos de servicio que necesita mientras sigue siendo la ruta no preferida, para que el corte en sí solo cambie la selección y nada más.

Pregunte al sitio remoto cómo devolverá el tráfico. Si las respuestas aún salen por el túnel viejo, una ruta local nueva produce asimetría o falla en un filtro que recuerda el estado. La traducción también pertenece al diseño por la misma razón: una dirección de origen cambiada también cambia la ruta de vuelta.

Corte de forma estrecha y conozca el camino de vuelta

Nombre la subred exacta y el mecanismo soportado por la plataforma que prefiere su ruta o selector nuevo. Las definiciones basadas en políticas no siempre se comportan como métricas de ruta, así que lea las reglas de políticas solapadas de su implementación antes de suponer que gana la coincidencia más específica.

Mueva una subred, no un sitio. Mantenga el acceso de gestión en una ruta que no toque, y escriba la reversión antes de aplicar nada: qué ruta o política revierte, quién lo hace y cómo siguen conectados mientras lo hacen.

Asimetría y estado obsoleto

Los cortafuegos y los dispositivos NAT recuerdan la interfaz que usó un flujo. Cuando la petición y la respuesta toman túneles distintos, el dispositivo puede descartar la respuesta aunque cada ruta funcione por sí sola. Pruebe con un flujo que abra después del cambio, porque una sesión establecida puede seguir usando la ruta vieja durante horas.

Si la dirección de origen observada se movió, busque cada política que nombre la vieja. Una migración que cambia el origen en silencio rompe reglas que nadie clasificó como parte del diseño de la VPN.

Demuestre ambas respuestas y luego retire la política vieja

Desde un host corriente en la subred migrada, llegue al servicio previsto y compruebe el origen observado y la interfaz de respuesta. Luego pruebe una red que debe quedarse en el túnel viejo, porque una migración solo termina cuando ambas respuestas son correctas. La segunda prueba es la que la gente se salta, y es la que atrapa un selector más amplio de lo que quería.

Retire la política obsoleta solo cuando ninguna subred restante dependa de ella, y registre la ruta final con su dueño en el inventario de selectores. Terminar no es que el túnel nuevo informe que está arriba; es que cada red siga la ruta que le corresponde.