Los circuitos privados son fáciles de describir y difíciles de reemplazar, porque el contrato cubría más que un cable. Llevaba una entrega, un plan de direcciones, una expectativa de latencia y un acuerdo de soporte, y el túnel que lo reemplaza hereda los cuatro, los haya escrito alguien o no. Las migraciones fallan cuando el equipo copia la configuración de enrutamiento y llama al resto un problema de operaciones. Empiece por los requisitos y luego demuestre cada uno en la ruta nueva antes de cancelar la anterior.

Convierta el circuito en una lista de propiedades

La primera pregunta es qué entregó realmente el servicio antiguo: un enlace enrutado con una subred pequeña o un segmento de capa 2 compartido entre sedes. Esa distinción decide si un túnel IP puede reproducirlo siquiera, porque un túnel transporta paquetes entre dos direcciones y no transporta descubrimiento por broadcast ni EtherTypes arbitrarios. Un circuito que se presentaba como un puerto de conmutador es una migración distinta de uno que presentaba una /30.

Anote los prefijos de sede, las direcciones de puerta de enlace, las aplicaciones que incrustan direcciones en su propia configuración y los prefijos que se solapan en otro lugar del entorno. Un plan de direcciones que sobreviva a la migración es un resultado de diseño, no una suposición. Esas cuatro listas también se convierten después en criterios de aceptación, así que guárdelas donde los probadores puedan leerlas.

Enrute la ruta nueva en ambos sentidos

Un túnel que sube es solo medio camino. El lado remoto necesita una ruta de vuelta a cada prefijo local, y el lado local debe preferir el túnel para esos prefijos sin robar tráfico que aún debe salir por internet. El reenvío asimétrico es el síntoma habitual de acertar una de esas mitades. Revise la tabla del lado remoto con el mismo cuidado que la suya, porque la ruta de vuelta es la que nadie configuró.

ip route get 10.20.0.10

El enrutamiento por políticas hace explícita la división: marque el tráfico que pertenece al par de sedes y dele una tabla cuyo valor por defecto sea el túnel. IPsec aporta la asociación protegida y la política que decide qué entra en ella, pero no las rutas a su alrededor, como la arquitectura IPsec describe. Cuando la marca coincide demasiado ampliamente, el tráfico web ordinario de la sede también entra en el túnel y sale por la salida equivocada.

Cambie con una reversión que ya haya probado

Dos rutas vivas con propietarios distintos invitan al reenvío asimétrico, así que levante la nueva dentro de una ventana definida y mueva los prefijos en un orden declarado. Mantenga el circuito antiguo configurado y conserve una vía de gestión fuera de banda que no dependa de ninguno de los dos túneles. Mueva un prefijo cada vez donde las aplicaciones lo permitan y observe la tabla de sesiones entre movimientos.

Decida de antemano qué pruebas autorizan el cambio y qué condición dispara la reversión. Una reversión que exige reparar el VPN nuevo a través de la conexión fallida no es una reversión. Enuncie el disparador como una condición medible y no como una sensación en la sala.

Acepte con el tráfico que el circuito llevaba realmente

Ping demuestra alcanzabilidad y poco más. Pruebe la resolución de nombres, las sesiones de larga duración, los flujos denegados y los tamaños de paquete que la ruta antigua manejaba sin fragmentación. La MTU es donde los túneles más a menudo difieren de un circuito, porque la encapsulación consume bytes que la aplicación daba por disponibles. Mida la carga útil más grande que pasa sin fragmentación en ambos sentidos, no solo hacia el servidor.

ping -M do -s 1400 -c 3 10.20.0.10

Si una carga de 1400 bytes pasa y 1472 no, el máximo de la ruta es menor de lo que esperan las aplicaciones y ha encontrado una regresión real, no cosmética. Compare ese resultado con los requisitos escritos en el primer paso y retire el circuito solo cuando los propietarios de esas aplicaciones acepten la medición. Esa firma es lo que convierte una prueba exitosa en una migración aceptada.

Artículos relacionados