Migrar desde una VPN basada en PPP sin copiar sus supuestos

Una migración de VPN termina cuando los usuarios, los destinos, la resolución de nombres y el comportamiento ante fallos siguen siendo correctos, no cuando el cliente nuevo muestra un icono verde. Los despliegues antiguos basados en PPP arrastran supuestos que nunca se escribieron: un secreto compartido que hacía de única comprobación de identidad, un grupo de direcciones fijo que el cortafuegos tiene en la lista blanca, un sufijo DNS que empuja el servidor. Sustituir el protocolo sin inventariar esos supuestos produce un túnel que completa el handshake y una frontera que no existe. El recorrido de abajo es el orden que yo uso, y el último paso es el que los equipos se saltan.

Paso 1: haga inventario de lo que ofrece la conexión antigua

El inventario se escribe, no se recuerda. Anote los clientes admitidos, los roles de autenticación, los grupos de direcciones, las redes protegidas, los requisitos de DNS y los permisos de servicio que necesita cada grupo de usuarios.

Para L2TP/IPsec, separe las dos capas de forma explícita. La identidad del par de IPsec autentica las máquinas; PPP autentica al usuario, normalmente con CHAP o MSCHAPv2.

Es en esa separación donde los despliegues antiguos esconden sus supuestos. Una clave precompartida que comparten todos los clientes autentica un grupo y no un dispositivo, y a menudo es lo único que se ha rotado nunca. Si la cuenta PPP es el control real por usuario, dígalo, porque la sustitución tiene que reproducir ese control con algo que no sea una cadena compartida. Anote también las direcciones de origen fijas y las excepciones de red local, porque esas son las dependencias que nadie documenta hasta que se rompen.

Paso 2: diseñe la sustitución a propósito

Elegir la sustitución es un mapeo requisito por requisito: un protocolo y un cliente mantenido que la organización admita, con cada requisito de identidad y acceso aterrizando en un mecanismo real. Un secreto compartido no equivale automáticamente a una clave o certificado por dispositivo, y una cuenta PPP por usuario no equivale a un certificado de dispositivo.

Coordine los rangos de direcciones antes que nada, porque un grupo de sustitución que se solape con una LAN doméstica o de oficina crea un fallo que no tiene nada que ver con la fuerza del cifrado. Compruebe el grupo contra la misma lista que construyó para el servicio antiguo, más lo que el cliente nuevo asume por defecto. Confirme el enrutamiento de retorno para las redes protegidas y confirme que el cliente nuevo puede empujar o documentar el sufijo DNS que empujaba el antiguo. Esos dos puntos generan más tiques de migración que el cambio de protocolo.

Paso 3: despliéguelo por etapas y verifique tanto el permiso como la denegación

Despliegue con un usuario representativo y una aplicación representativa. Incluya la resolución DNS privada en la prueba, porque un túnel que llega a una dirección pero no puede resolver un nombre interno solo está migrado a medias. Incluya también el estado de indisponibilidad esperado: qué debe ocurrir cuando cae el túnel y si el cliente lo impone.

Después pruebe un destino que debe seguir denegado. Una regla amplia de permiso temporal puede hacer que el túnel nuevo parezca sano mientras retira en silencio la frontera de autorización que aplicaba el servicio antiguo, y nadie lo nota hasta una auditoría. Compare los resultados de permiso y denegación lado a lado, desde el mismo cliente, en la misma sesión. Mantenga el servicio antiguo en marcha hasta que ambas columnas coincidan con el diseño.

Antes de mover el acceso de administrador, confirme que tiene una ruta de recuperación autorizada que no dependa del túnel que está cambiando.

Paso 4: retire la identidad antigua

Retirar bien la identidad antigua significa revocar los usuarios y las credenciales de dispositivo obsoletos a través del servicio que los posee, y luego eliminar perfiles y escuchas antiguos cuando no quede ninguna dependencia. Borrar un archivo local no revoca una copia en otro sitio, y una escucha antigua que todavía acepta el secreto compartido antiguo es una puerta sin vigilancia.

Merece la pena frenar en ese punto. Un perfil de cliente dado de baja en un portátil no es una credencial revocada; la credencial vive en el servidor y sigue siendo válida hasta que el servidor deja de aceptarla. Busque otras copias de la configuración antigua — dispositivos de prueba, un teléfono olvidado, un instalador que alguien guardó — y trate el apagado de la escucha como el momento en que el servicio antiguo termina de verdad. Hasta entonces, la migración tiene dos puertas delanteras.

El registro de aceptación es el inventario del paso uno con una columna añadida: qué hace el diseño nuevo para cada fila y cómo lo verificó. Eso convierte una actualización de protocolo en un requisito de servicio con pruebas.

Mantenga el resultado ligado a lo que necesita el servicio y no al nombre del protocolo, porque un protocolo moderno con los supuestos antiguos copiados dentro es el mismo riesgo con mejor marco. RFC 3193 describe cómo se transporta L2TP sobre IPsec, lo que es un recordatorio útil de que las dos capas siempre fueron decisiones separadas. Si el inventario tiene una fila que no puede explicar, pare y averigüe de qué depende. La migración termina cuando la lista es aburrida.