Log di debug L2TP vuoto? L’errore è probabilmente nel journal

Avvii l’helper L2TP con il debug, guardi il terminale, e si ferma senza nulla di utile sullo schermo. Non è un flag di debug rotto. Una connessione L2TP di NetworkManager è quattro processi che collaborano, e solo alcuni di essi scrivono nel terminale che stai osservando. Il resto delle prove è nel journal, a un filtro di distanza.

Quattro processi, due destinazioni del log

La connessione inizia con IPsec, che è libreswan o strongSwan a seconda dell’installazione. Poi il demone L2TP, tradizionalmente xl2tpd e in alcune build kl2tpd, gestisce il tunnel. Infine pppd si occupa dell’autenticazione e dell’indirizzamento al suo interno.

Il servizio helper coordina questi pezzi e stampa il proprio avanzamento. Il demone IPsec e pppd di solito riportano attraverso il journal di sistema, ed è per questo che il terminale mostra una connessione che fallisce mentre la ragione è in un file che non hai aperto.

Questa separazione spiega anche perché un errore di PSK e un errore di password sembrano uguali dal desktop: entrambi producono una disconnessione generica, e lo stadio che ha fallito è visibile solo nell’output di ciascun processo. È tutta la ragione per cui il journal conta qui. Un messaggio generico sul desktop, quattro autori possibili dietro.

Raccogli un tentativo, poi leggi l’ordine

Riproduci una volta, con un profilo noto e un orario noto, poi leggi una finestra stretta invece dell’intero avvio. Ripetere i tentativi mentre cambi le impostazioni trasforma il log in una miscela che non si può interpretare.

Questi comandi selezionano i processi partecipanti per l’avvio corrente, e vale la pena confermare il percorso del plugin sulla tua distribuzione:

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

I campi ripetuti in un’unica chiamata selezionano l’unione di quei processi, il che mantiene la sequenza in ordine temporale. Su un sistema basato su Debian la query equivalente è dpkg -L; il punto è trovare dove vive davvero l’helper prima di provare a eseguirlo a mano.

Tre condizioni decidono la mossa successiva

Leggi il primo stadio che fallisce, poi scegli di conseguenza. Se IPsec segnala un errore di proposta o di autenticazione del peer, il tunnel non si è mai formato, e cambiare la password PPP non può aiutare.

Se il tunnel si è formato e pppd ha rifiutato l’accesso, il segreto condiviso era già a posto e il problema delle credenziali è uno strato più in alto. Se pppd ha negoziato un indirizzo e l’errore compare più tardi, entrambi funzionano e il problema rimanente è l’instradamento, il DNS o la politica del server stesso.

Questi tre rami coprono quasi ogni disconnessione generica, e li decide il processo che ha registrato l’ultimo errore, non il messaggio di errore che sembra più allarmante.

Vale anche la pena confermare quale backend IPsec è installato prima di toccare un’impostazione di debug. Un’opzione di log scritta per strongSwan non fa nulla quando gira libreswan, e la connessione continuerà a fallire nello stesso punto mentre modifichi un file che nessuno legge.

La modalità debug lascia file

Il flusso di debug originale avvia il servizio a mano con un flag di debug, e quella modalità può lasciare in posto file di configurazione runtime generati quando la connessione termina.

Questi file contengono materiale di autenticazione: la chiave precondivisa, le credenziali o entrambe. Una configurazione generata copiata in una finestra di chat è una divulgazione di credenziali, non un estratto del log. Rimuovi le righe segrete prima di condividere qualsiasi cosa, ed elimina la directory quando l’indagine termina. Trattali come segreti, estrai le righe specifiche che ti servono per un rapporto, ed eliminane dopo invece di incollare una directory in un ticket.

Anche l’istanza manuale deve essere coordinata con quella normale. Avviare una copia di debug mentre il servizio possiede già il plugin produce due proprietari e un log che mescola entrambi, il che è peggio che nessun output di debug.

Poi ripristina l’helper normale

Quando l’indagine termina, ferma l’istanza manuale, rimuovi i file runtime conservati e riconnettiti attraverso il percorso normale, così la persona successiva vede una configurazione che corrisponde alla realtà.

Poi verifica il risultato allo strato che ha fallito, non all’icona del desktop:

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

Una sessione che si autentica, riceve un indirizzo e instrada verso la destinazione prevista è il risultato che stavi debuggando. Un terminale silenzioso durante un tentativo fallito ti dice solo dove l’output non è stato scritto.