Tiempo de espera L2TP en Ubuntu 22.04: el fallo del túnel de xl2tpd

El escritorio muestra una conexión en curso, IPsec informa de éxito y la interfaz PPP nunca aparece. En syslog el mismo número de túnel se repite hasta que el intento agota el tiempo en UDP 1701. Antes de editar la clave precompartida o la configuración del servidor, reconozca esta forma: en Ubuntu 22.04 suele ser una regresión de empaquetado en xl2tpd, y el servidor era correcto todo el tiempo.

Qué le dice el par de líneas repetido de syslog

Una sesión fallida imprime un par de líneas a intervalos regulares: el demonio no encuentra un túnel para un mensaje de control entrante y luego vuelca los identificadores de llamada y de túnel que recibió. Más tarde el contador de reintentos llega a su límite y la conexión se cierra con un tiempo de espera en el puerto 1701. Las direcciones y los identificadores son accidentales; la forma es lo que importa. IKE se completó, llegó el tráfico de control L2TP y el demonio no pudo asociarlo con un túnel que ya había creado.

Por tanto, el fallo se sitúa entre el control L2TP y PPP. Todavía no se ha probado nada del secreto, las opciones PPP ni la subred remota.

Confirme que IPsec ha tenido éxito de verdad

Dos comprobaciones separan esto de un problema de credenciales, y ambas van antes de cualquier cambio de paquete.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

La salida de estado lista la conexión y su estado, y un túnel establecido significa que la fase uno y la fase dos se completaron. Una línea del registro sobre una clave compartida ausente apunta solo al secreto, así que deténgase y arréglelo primero. Cuando IPsec está establecido y el tiempo de espera L2TP sigue apareciendo, el demonio es el sospechoso restante. Guarde las líneas exactas de un intento en lugar de un día entero de reintentos.

Compruebe la compilación de xl2tpd, no el nombre de la versión

La compilación jammy de xl2tpd 1.3.16 de Ubuntu activó la optimización en tiempo de enlace, lo que rompió el análisis del identificador de túnel en la respuesta SCCRP del servidor. El demonio entonces descarta los paquetes de control de un túnel que creó él mismo. La cadena de versión importa más que el nombre de la distribución.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

El paquete corregido es 1.3.16-1ubuntu0.1, así que una compilación sin ese sufijo es anterior a la corrección. La salida de políticas muestra qué candidato instalaría una actualización, y la lista de retenidos explica por qué no ha llegado una corrección. Donde el paquete está disponible, actualícelo y vuelva a conectarse por el perfil normal en lugar de editar archivos a mano. No reconstruya módulos ni cambie el secreto mientras la compilación antigua siga instalada.

Verifique PPP después del cambio

Una actualización correcta se demuestra en la capa que estaba rota. Compruebe que PPP subió, no solo que el icono cambió.

ip -4 addr show ppp0
ip route | grep ppp

El listado de interfaces debería mostrar una dirección local y una de par, y la tabla de rutas debería llevar los prefijos del túnel. Syslog debería mostrar el túnel aceptado y pppd informando ambas direcciones, sin líneas repetidas de túnel no encontrado. Si PPP está activo y el tráfico sigue fallando, mire después el enrutamiento o la MTU, porque la etapa L2TP ya ha terminado su trabajo. Anote la versión de paquete que funciona en las notas de la máquina, para que una futura reinstalación no restaure la compilación rota.

Donde el paquete corregido no está disponible, las alternativas documentadas son una compilación local del código fuente 1.3.16 o 1.3.17, un cambio a kl2tpd o una degradación fijada. Cada una conlleva un coste de mantenimiento que merece anotarse.