El registre de depuració de L2TP és buit? L’error és probablement al registre del sistema

Inicieu l’auxiliar L2TP amb depuració, mireu el terminal i s’atura sense res útil a la pantalla. No és un indicador de depuració espatllat. Una connexió L2TP de NetworkManager és quatre processos que cooperen, i només alguns d’ells escriuen al terminal que mireu. La resta de les proves és al registre del sistema, a un filtre de distància.

Quatre processos, dues destinacions de registre

La connexió comença amb IPsec, que és libreswan o strongSwan segons la instal·lació. Després el dimoni L2TP, tradicionalment xl2tpd i en algunes compilacions kl2tpd, executa el túnel. Finalment pppd gestiona l’autenticació i l’adreçament a dins.

El servei auxiliar coordina aquestes peces i imprimeix el seu propi progrés. El dimoni IPsec i pppd normalment informen a través del registre del sistema, i per això el terminal mostra una connexió que falla mentre la raó és en un fitxer que no heu obert.

Aquesta divisió també explica per què un error de PSK i un error de contrasenya semblen iguals des de l’escriptori: tots dos produeixen una desconnexió genèrica, i l’etapa que ha fallat només es veu a la sortida de cada procés. Aquesta és tota la raó per la qual el registre del sistema importa aquí. Un missatge genèric a l’escriptori, quatre autors possibles al darrere.

Recolliu un intent i després llegiu l’ordre

Reproduïu-ho un cop, amb un perfil conegut i una hora coneguda, i després llegiu una finestra estreta en lloc de tot l’arrencada. Repetir intents mentre canvieu la configuració converteix el registre en una barreja que no es pot interpretar.

Aquestes ordres seleccionen els processos participants per a l’arrencada actual, i val la pena confirmar el camí del connector a la vostra distribució:

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

Els camps repetits en una invocació seleccionen la unió d’aquests processos, cosa que manté la seqüència en ordre temporal. En un sistema basat en Debian la consulta equivalent és dpkg -L; el punt és trobar on viu realment l’auxiliar abans de provar d’executar-lo a mà.

Tres condicions que decideixen el següent pas

Llegiu la primera etapa que falla i trieu en conseqüència. Si IPsec informa d’una fallada de proposta o d’autenticació de l’igual, el túnel no s’ha format mai, i canviar la contrasenya PPP no pot ajudar.

Si el túnel s’ha format i pppd ha rebutjat l’inici de sessió, el secret compartit ja era correcte i el problema de credencials és una capa més amunt. Si pppd ha negociat una adreça i la fallada apareix més tard, tots dos funcionen i el problema restant és l’encaminament, DNS o la política pròpia del servidor.

Aquestes tres branques cobreixen gairebé tota desconnexió genèrica, i les decideix quin procés ha registrat l’últim error, no quin missatge d’error sembla més alarmant.

També val la pena confirmar quin rerefons IPsec hi ha instal·lat abans de tocar cap paràmetre de depuració. Una opció de registre escrita per a strongSwan no fa res quan s’executa libreswan, i la connexió continuarà fallant al mateix lloc mentre editeu un fitxer que ningú no llegeix.

El mode de depuració deixa fitxers

El flux de treball de depuració original executa el servei a mà amb un indicador de depuració, i aquest mode pot deixar fitxers de configuració d’execució generats al seu lloc quan la connexió acaba.

Aquests fitxers contenen material d’autenticació: la clau prèviament compartida, les credencials o totes dues. Una configuració generada copiada en una finestra de xat és una revelació de credencials, no un extracte del registre. Traieu les línies secretes abans de compartir res i suprimiu el directori quan acabi la investigació. Tracteu-los com a secrets, extraieu les línies concretes que necessiteu per a un informe i suprimiu-los després, en lloc d’enganxar un directori en un tiquet.

La instància manual també s’ha de coordinar amb la normal. Llançar una còpia de depuració mentre el servei ja posseeix el connector produeix dos propietaris i un registre que barreja tots dos, cosa que és pitjor que no tenir cap sortida de depuració.

Després restaureu l’auxiliar normal

Quan acabi la investigació, atureu la instància manual, elimineu els fitxers d’execució retinguts i torneu a connectar-vos pel camí normal perquè la propera persona vegi una configuració que coincideixi amb la realitat.

Després verifiqueu el resultat a la capa que ha fallat, no a la icona de l’escriptori:

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

Una sessió que s’autentica, rep una adreça i encamina cap a la destinació prevista és el resultat que estàveu depurant. Un terminal silenciós durant un intent fallit només us diu on no s’ha escrit la sortida.