¿La actualización de Ubuntu rompió L2TP/IPsec? Compare las propuestas de IKEv1

La conexión funcionaba el jueves, la actualización se ejecutó el viernes, y el lunes el cliente gira en “connecting” y se rinde. Mismo portátil, mismo servidor, misma cuenta, misma clave precompartida. No se editó nada del perfil, y por eso los sospechosos obvios, la contraseña y el cortafuegos, le hacen perder el tiempo.

Lo que cambió es la lista de transformaciones que su máquina está dispuesta a ofrecer. Ambas pilas IPsec usadas en Ubuntu, strongSwan y Libreswan, eliminan algoritmos que ya no consideran seguros, y el complemento de NetworkManager que las precede tiene su propia lista, que se mueve con otro calendario. Un servidor fijado a 3DES, SHA1 y un grupo Diffie-Hellman de 1024 bits puede acabar sin oír nada que acepte.

Qué cambió realmente la actualización

Dos capas alimentan la propuesta de IKEv1. El demonio incluye un conjunto de propuestas predeterminado compilado, y el complemento L2TP o bien confía en él o bien proporciona su propia lista. Antes de NetworkManager-l2tp 1.2.16 el complemento confiaba en él, así que su propuesta era lo que el demonio instalado consideraba razonable. A partir de 1.2.16 el complemento envía una lista documentada inspirada en los clientes de Windows y Apple, y esa lista es más amplia que el valor predeterminado antiguo pero ya no contiene todas las combinaciones heredadas al frente de la cola.

Esa división explica un modo de fallo que a la gente le resulta confuso: dos máquinas en la misma versión de Ubuntu pueden comportarse de forma distinta porque una tiene el paquete de la distribución y la otra tiene un backport, y la versión del demonio en ambas parece idéntica en un informe de error. Compruebe la versión del complemento, no solo la del demonio, antes de concluir que la actualización no cambió nada relevante.

Hay una trampa más pequeña en la misma zona. Los dos demonios escriben de forma distinta los grupos Diffie-Hellman de curva elíptica, uno escribe ecp384 y el otro ecp_384. Pegue la ortografía incorrecta en el diálogo Avanzado y el demonio rechazará el ajuste como no analizable, lo que en el registro aparece como un problema de negociación y no como una errata de configuración.

Lea el fallo antes de cambiar nada

Empiece por qué backend está ejecutando, porque la respuesta decide tanto la sintaxis como la ubicación del registro.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Después lea el intercambio en sí. En strongSwan el demonio registra en el journal en una versión actual y en /var/log/syslog en una más antigua, y la parte interesante es la propuesta que envía, no la línea final. Busque texto sobre ninguna propuesta coincidente, que es un problema de algoritmo; un fallo de autenticación, que apunta a la clave o a la cuenta; o un tiempo de espera simple, que apunta a la accesibilidad.

Estos tres resultados se tratan como un solo síntoma con demasiada frecuencia. Un tiempo de espera con un registro de demonio vacío significa que los paquetes no llegan. Un rechazo de la propuesta significa que llegaron y fueron rechazados. Si su registro está silencioso, suba el nivel de depuración del complemento para un intento y bájelo después, porque la salida detallada llena un journal rápidamente.

La fase 1 y la fase 2 son apuestas separadas

IKEv1 negocia dos veces. El modo principal construye la asociación de seguridad IKE a partir de un algoritmo de cifrado, un algoritmo de integridad, un grupo Diffie-Hellman y un método de autenticación. El modo rápido construye después la asociación ESP que transportará L2TP. Un servidor es libre de aceptar la primera y rechazar la segunda, así que un perfil medio correcto falla más tarde de lo que espera y parece un error distinto.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

El signo de exclamación es sintaxis de strongSwan para una entrada estricta: ofrezca esta única combinación y nada más. Sin él la entrada se une a una lista de reserva, lo que está bien cuando el par es moderno y es contraproducente cuando es un aparato con una sola política codificada. Trate el par anterior como una ilustración de la forma, no como una recomendación para nada de lo que esté construyendo hoy.

Cambie un campo y repita la prueba

En un complemento actual, la primera prueba más rápida es borrar por completo ambos campos de propuestas y reconectar, porque la lista predeterminada incluida ya contiene las combinaciones habituales de Windows y Apple. En un complemento más antiguo, borrarlos devuelve el control a un demonio que puede haber descartado el algoritmo que su servidor exige, y el fallo empeora.

Si borrarlos no ayuda, establezca el par estricto que documenta su servidor, una fase cada vez. Cambie la fase 1, reconecte y lea el registro antes de tocar la fase 2. Cuando una combinación por fin funcione, anótela junto al modelo del servidor y a la versión del complemento, porque los valores predeterminados volverán a moverse y esa nota es lo que convierte la próxima actualización en una comprobación de cinco minutos.