¿El registro de depuración de L2TP está vacío? El error probablemente esté en el journal

Inicias el asistente de L2TP con depuración, observas la terminal y se detiene sin nada útil en pantalla. Eso no es un indicador de depuración roto. Una conexión L2TP de NetworkManager son cuatro procesos que cooperan, y solo algunos de ellos escriben en la terminal que estás mirando. El resto de las pruebas está en el journal, a un filtro de distancia.

Cuatro procesos, dos destinos de registro

La conexión empieza con IPsec, que es libreswan o strongSwan según la instalación. Después el demonio L2TP, tradicionalmente xl2tpd y en algunas compilaciones kl2tpd, ejecuta el túnel. Por último pppd gestiona la autenticación y el direccionamiento dentro de él.

El servicio auxiliar coordina esas piezas e imprime su propio progreso. El demonio IPsec y pppd suelen informar a través del journal del sistema, y por eso la terminal muestra una conexión que falla mientras la razón está en un archivo que no has abierto.

Esa división también explica por qué un error de PSK y un error de contraseña se ven iguales desde el escritorio: ambos producen una desconexión genérica, y la etapa que falló solo se ve en la salida de cada proceso. Esa es toda la razón por la que el journal importa aquí. Un mensaje genérico en el escritorio, cuatro autores posibles detrás.

Reúna un intento y después lea el orden

Reproduce una vez, con un perfil conocido y una hora conocida, y luego lee una ventana estrecha en lugar de todo el arranque. Repetir intentos mientras cambias ajustes convierte el registro en una mezcla que no se puede interpretar.

Estos comandos seleccionan los procesos participantes del arranque actual, y conviene confirmar la ruta del complemento en tu distribución:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Los campos repetidos en una invocación seleccionan la unión de esos procesos, lo que mantiene la secuencia en orden temporal. En un sistema basado en Debian la consulta equivalente es dpkg -L; la cuestión es encontrar dónde vive realmente el asistente antes de intentar ejecutarlo a mano.

Tres condiciones que deciden el siguiente paso

Lee la primera etapa que falla y elige en consecuencia. Si IPsec informa de un fallo de propuesta o de autenticación del par, el túnel nunca se formó, y cambiar la contraseña PPP no puede ayudar.

Si el túnel se formó y pppd rechazó el inicio de sesión, el secreto compartido ya era correcto y el problema de credenciales está una capa más arriba. Si pppd negoció una dirección y el fallo aparece más tarde, ambos funcionan y el problema restante es el enrutamiento, DNS o la política propia del servidor.

Esas tres ramas cubren casi toda desconexión genérica, y las decide qué proceso registró el último error, no qué mensaje de error parece más alarmante.

También conviene confirmar qué backend de IPsec está instalado antes de tocar un ajuste de depuración. Una opción de registro escrita para strongSwan no hace nada cuando se ejecuta libreswan, y la conexión seguirá fallando en el mismo punto mientras editas un archivo que nadie lee.

El modo de depuración deja archivos

El flujo de depuración original ejecuta el servicio a mano con un indicador de depuración, y ese modo puede dejar archivos de configuración de ejecución generados en su sitio cuando la conexión termina.

Esos archivos contienen material de autenticación: la clave precompartida, credenciales o ambas. Una configuración generada copiada en una ventana de chat es una revelación de credenciales, no un extracto del registro. Elimina las líneas secretas antes de compartir nada y borra el directorio cuando termine la investigación. Trátalos como secretos, extrae las líneas concretas que necesites para un informe y bórralos después, en lugar de pegar un directorio en un ticket.

La instancia manual también debe coordinarse con la normal. Lanzar una copia de depuración mientras el servicio ya posee el complemento produce dos propietarios y un registro que mezcla ambos, lo cual es peor que no tener ninguna salida de depuración.

Después restaura el asistente normal

Cuando termine la investigación, detén la instancia manual, elimina los archivos de ejecución retenidos y vuelve a conectar por la ruta normal para que la siguiente persona vea una configuración que coincida con la realidad.

Luego verifica el resultado en la capa que falló, no en el icono del escritorio:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Una sesión que se autentica, recibe una dirección y enruta hacia el destino previsto es el resultado que estabas depurando. Una terminal silenciosa durante un intento fallido solo te dice dónde no se escribió la salida.