O rexistro de depuración de L2TP está baleiro? O erro probablemente está no journal

Inicias o asistente de L2TP con depuración, observas o terminal e detense sen nada útil na pantalla. Iso non é un indicador de depuración roto. Unha conexión L2TP de NetworkManager son catro procesos que cooperan, e só algúns deles escriben no terminal que estás mirando. O resto das probas está no journal, a un filtro de distancia.

Catro procesos, dous destinos de rexistro

A conexión comeza con IPsec, que é libreswan ou strongSwan segundo a instalación. Despois o daemon L2TP, tradicionalmente xl2tpd e nalgunhas compilacións kl2tpd, executa o túnel. Por último pppd xestiona a autenticación e o direccionamento dentro del.

O servizo auxiliar coordina esas pezas e imprime o seu propio progreso. O daemon IPsec e pppd adoitan informar a través do journal do sistema, e por iso o terminal mostra unha conexión que falla mentres a razón está nun ficheiro que non abriches.

Esa división tamén explica por que un erro de PSK e un erro de contrasinal se ven iguais desde o escritorio: ambos producen unha desconexión xenérica, e a etapa que fallou só se ve na saída de cada proceso. Esa é toda a razón pola que o journal importa aquí. Unha mensaxe xenérica no escritorio, catro autores posibles detrás.

Reunide un intento e despois lede a orde

Reproduce unha vez, cun perfil coñecido e unha hora coñecida, e despois le unha xanela estreita en lugar de todo o arranque. Repetir intentos mentres cambias axustes converte o rexistro nunha mestura que non se pode interpretar.

Estes comandos seleccionan os procesos participantes do arranque actual, e convén confirmar a ruta do complemento na túa 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

Os campos repetidos nunha invocación seleccionan a unión deses procesos, o que mantén a secuencia en orde temporal. Nun sistema baseado en Debian a consulta equivalente é dpkg -L; a cuestión é atopar onde vive realmente o asistente antes de tentar executalo a man.

Tres condicións deciden o seguinte paso

Le a primeira etapa que falla e escolle en consecuencia. Se IPsec informa dun fallo de proposta ou de autenticación do par, o túnel nunca se formou, e cambiar o contrasinal PPP non pode axudar.

Se o túnel se formou e pppd rexeitou o inicio de sesión, o segredo compartido xa era correcto e o problema de credenciais está unha capa máis arriba. Se pppd negociou un enderezo e o fallo aparece máis tarde, ambos funcionan e o problema restante é o encamiñamento, DNS ou a política propia do servidor.

Esas tres ramas cobren case toda desconexión xenérica, e decídeas que proceso rexistrou o último erro, non que mensaxe de erro parece máis alarmante.

Tamén convén confirmar que backend de IPsec está instalado antes de tocar un axuste de depuración. Unha opción de rexistro escrita para strongSwan non fai nada cando se executa libreswan, e a conexión seguirá fallando no mesmo punto mentres editas un ficheiro que ninguén le.

O modo de depuración deixa ficheiros

O fluxo de depuración orixinal executa o servizo a man cun indicador de depuración, e ese modo pode deixar ficheiros de configuración de execución xerados no seu sitio cando a conexión remata.

Eses ficheiros conteñen material de autenticación: a clave precompartida, credenciais ou ambas. Unha configuración xerada copiada nunha xanela de chat é unha revelación de credenciais, non un extracto do rexistro. Elimina as liñas secretas antes de compartir nada e borra o directorio cando remate a investigación. Trátaos como segredos, extrae as liñas concretas que necesites para un informe e bórraos despois, en lugar de pegar un directorio nun ticket.

A instancia manual tamén debe coordinarse coa normal. Lanzar unha copia de depuración mentres o servizo xa posúe o complemento produce dous propietarios e un rexistro que mestura ambos, o cal é peor que non ter ningunha saída de depuración.

Despois restaura o asistente normal

Cando remate a investigación, detén a instancia manual, elimina os ficheiros de execución retidos e volve conectar pola ruta normal para que a seguinte persoa vexa unha configuración que coincida coa realidade.

Logo verifica o resultado na capa que fallou, non na icona do escritorio:

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

Unha sesión que se autentica, recibe un enderezo e encamiña cara ao destino previsto é o resultado que estabas depurando. Un terminal silencioso durante un intento fallido só che di onde non se escribiu a saída.