Cambiar de proveedor sin renumerar las direcciones VPN del sitio

Una sucursal cambia de proveedor de internet y el servidor de archivos conserva su dirección. Ese resultado es normal en una VPN de sitio enrutada y sorprendente para quien supone que la dirección del extremo del túnel es la dirección de la aplicación. Las dos viven en capas distintas del diseño y solo una se movió. Tratarlas como una sola es la forma en que una migración de proveedor se convierte en un proyecto de renumeración.

Dos planes de direcciones que se mueven por separado

El plan interior describe las direcciones privadas que usan las aplicaciones: el servidor de la sucursal en 10.55.8.20, el prefijo de la sede central que enruta hacia él y la ruta de vuelta. El plan exterior describe cómo se alcanzan dos pasarelas: direcciones de par, puertos de escucha y el camino por internet.

Un cambio de proveedor toca el plan exterior. Por sí solo no exige cambiar el plan interior.

Mantener los dos inventarios separados es la razón práctica para ejecutar una superposición incluso cuando la aplicación ya cifra su propio tráfico. La superposición le da una topología interior estable que sobrevive a los cambios exteriores. La aplicación conserva su dirección, sus reglas de cortafuegos y sus registros DNS. Solo cambian las entradas de transporte, y eso es una revisión mucho menor.

El túnel exterior lleva la conversación interior

En un túnel de pasarela a pasarela, la cabecera IP exterior direcciona las dos pasarelas. La cabecera interior sigue nombrando los extremos reales de la aplicación. La descripción de pasarela a pasarela del RFC 7296 lo trata como enrutamiento ordinario que entrega tráfico a través de los extremos del túnel.

Por eso el servidor de la sucursal puede conservar 10.55.8.20 mientras cambia la dirección pública de la pasarela. El paquete interior no contiene en absoluto la dirección del proveedor.

La separación es una propiedad del diseño, no una garantía automática. Si el enlace de reemplazo no puede establecer el túnel admitido, o las rutas interiores no se reinstalan, la aplicación pierde su camino aunque su dirección no cambie.

El traslado de proveedor todavía tiene una lista de comprobación

La lista exterior tiene cinco entradas: la dirección del par o el nombre mantenido, el escucha y cualquier filtrado aguas arriba, la traducción en el camino, la identidad esperada del par y los ajustes permitidos de la otra pasarela. Cada una puede fallar por su cuenta. Mantenga un camino de recuperación aparte mientras cambia el enlace que transporta la administración. Cortar el acceso remoto durante un cambio de enlace es una caída que usted mismo provocó.

Después, compruebe el prefijo de la sucursal, la ruta en ambos sentidos, la política de protección y un flujo real de aplicación. Un túnel recién autenticado no arregla una ruta que apunta a la subred privada antigua.

El solapamiento de direcciones con otro sitio conectado es un problema de planificación aparte. El cambio de proveedor no lo crea, pero una migración suele ser cuando sale a la luz.

Lo que no sobrevive: origen público y sesiones

Una dirección privada de servidor estable no es un origen público estable. Si la navegación sale directamente por el nuevo proveedor, los sitios ven la nueva dirección de cara al proveedor.

Mantener esa dirección estable requiere un diseño de salida deliberado, con su propia disponibilidad y política. No viene gratis con el túnel.

Las sesiones establecidas tampoco sobreviven a un cambio de camino. El túnel puede restablecerse en segundos y aun así romper conexiones de larga duración ancladas al camino antiguo. Planifique el cambio para una ventana en la que las reconexiones sean aceptables. No afirme que una migración será invisible a menos que se hayan probado los clientes concretos y sus tiempos de espera.

Verifique el traslado con cuatro comprobaciones

Tras el cambio, verifique cuatro cosas en orden: el túnel está establecido con el par previsto, la ruta interior al prefijo de la sucursal existe, la política permite el flujo de la aplicación y la aplicación responde. Cada una tiene su propio comando.

En una pasarela Linux, estas tres cubren la mitad de esa lista:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Mantenga las direcciones de transporte en un inventario y las de aplicación en otro. Actualice solo las entradas que de verdad se movieron. Renumerar dependencias internas porque cambió la dirección exterior del túnel es trabajo evitable.