Qué capa del perfil L2TP se rompió en realidad

Baje por la pila en lugar de recorrer la página de ajustes: Negociación IPsec, después control L2TP, después autenticación PPP y, por último, asignación de dirección y DNS. Cada capa tiene su propia firma de error y su propia causa probable. Un perfil que falla en la autenticación de usuario ya ha superado tres comprobaciones a las que un perfil que caducó antes nunca llegó. Ese orden es lo primero que hay que establecer.

El mismo nombre de protocolo esconde cuatro conversaciones distintas.

Nombre la capa antes de cambiar ajustes

Si falla la configuración de IPsec, apunta al secreto compartido, a los algoritmos o a la identidad del par. Si después falla el control L2TP, sugiere la propia capa de túnel, que es un problema más acotado. Los fallos de autenticación PPP nombran la cuenta o el método de autenticación. Un fallo de dirección o de DNS después de la autenticación significa que el transporte funcionó y el intercambio de configuración no.

Anote la versión del cliente, la versión del sistema operativo y la configuración documentada del operador. Sin esas tres cosas, cada cambio es una conjetura que podría arreglar por accidente otra cosa.

Compare el perfil con el cliente actual

Un perfil guardado puede contener un secreto compartido, una opción de autenticación o un extremo que el cliente actual ya no acepta. Algunas plataformas han retirado o eliminado por completo el soporte de L2TP/IPsec, y un cliente actualizado puede abandonar el comportamiento antiguo de IKE sin ningún cambio en el servidor. Compare sus valores guardados con los requisitos documentados actuales del operador, no con lo que funcionaba hace un año. La diferencia entre esos dos documentos suele ser donde está la respuesta.

Un secreto en caché o una cuenta renombrada normalmente no necesitan más que una actualización ordinaria del perfil, y ambos merecen comprobarse antes de rediseñar nada. Esas son las correcciones baratas y deberían descartarse antes de cualquier trabajo arquitectónico.

Las opciones heredadas no vuelven por activarlas

Desactivar la validación no repara un problema de cadena de confianza, y activar un algoritmo solo porque lo menciona un hilo de foro no demuestra nada sobre lo que acepta el servidor. Las propuestas IKE débiles suelen retirarse de los clientes por buenos motivos, y volver a activar una crea una conexión peor que la que se rompió. Un túnel más débil no es una reparación, es un problema nuevo con el mismo síntoma. La pregunta correcta es qué admite ahora el operador.

La reparación de activarlo todo cambia mucho más que el fallo real y le deja sin poder decir qué lo arregló.

Plantee la migración como un proyecto

Si el despliegue ya no admite el cliente necesario, planifique un reemplazo con el operador en lugar de conservar una excepción no documentada. Traslade el requisito de acceso, las identidades, las entradas DNS y las rutas, porque un nuevo handshake por sí solo no recrea ninguno de esos permisos. Son las piezas de las que dependía en silencio una conexión funcional. Guarde el perfil antiguo en un lugar seguro hasta que se confirme la recuperación y, después, retire las credenciales obsoletas allí donde realmente se administran. Dejarlas en su sitio es la forma en que un camino antiguo sigue siendo utilizable mucho después de que todos crean que se cerró.

Una migración es también el momento de anotar para qué servía el perfil. Si no, la siguiente persona hereda una conexión funcional sin ninguna explicación.

Revise la capa, la versión del cliente y los requisitos actuales del operador. Después decida si esto es una reparación o un reemplazo.