journalctl per i log VPN: quale unità possiede la connessione?

Iniziate dall’unità di systemd che possiede davvero la connessione VPN, non dal comando di log che ricordate. Un servizio OpenVPN diretto, un’unità wg-quick e un profilo NetworkManager collocano i loro messaggi utili in unità diverse, e una query sull’unità sbagliata produce un risultato vuoto che sembra silenzio. Confrontate i tre proprietari comuni, restringete la finestra, poi leggete le fasi in ordine.

Confrontate i tre proprietari comuni

Un servizio client OpenVPN è di solito un’unità di istanza intitolata al profilo, come [email protected]. I suoi messaggi includono il percorso di configurazione, l’analisi delle opzioni, la stretta di mano TLS e l’installazione delle rotte eseguita dal client.

Un’unità wg-quick è più silenziosa per progetto. La configurazione dell’interfaccia avviene all’avvio, la stretta di mano è gestita dal kernel e i rinnovi di chiavi di routine non vengono registrati per impostazione predefinita, quindi wg show è spesso più informativo del log. Questa differenza conta quando confrontate un protocollo che registra la negoziazione con uno che non lo fa.

NetworkManager possiede i profili che ha creato, e i suoi messaggi vivono sotto NetworkManager.service anche quando il plugin sottostante è un assistente VPN. Interrogate sia il gestore sia l’unità di assistenza quando il profilo è gestito in quel modo.

Restringete la query a un’unità e una finestra

Interrogate l’unità che avete identificato e limitate il tempo al tentativo che state esaminando. Un giorno di solito basta, e una finestra più corta è meglio quando la macchina si riconnette spesso.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

Verificate il nome installato prima di fidarvi della query. L’impacchettamento della distribuzione rinomina le unità, e un profilo che esiste come file potrebbe non essere mai stato abilitato come servizio. Se l’unità non esiste, il log vuoto vi parla dell’installazione e non del tunnel.

Leggete la prima fase fallita

Leggete gli eventi nell’ordine in cui accadono: ricerca dell’endpoint, trasporto, identità, autenticazione, installazione delle rotte e il fallimento successivo dell’applicazione. Il primo fallimento concreto è quello che vale la pena indagare, perché tutto ciò che segue è una conseguenza.

Un servizio che si avvia correttamente non dimostra che ogni risorsa necessaria sia raggiungibile. Un ciclo di riconnessione può produrre diverse negoziazioni separate, quindi conservate il nome del profilo e l’ora del tentativo con gli eventi, e leggete un tentativo invece di un flusso unito. Un singolo tentativo è una sequenza con una causa, mentre un flusso unito è un muro di righe ripetute. Scrivete il primo errore nel ticket prima di leggere oltre.

Non mescolate un servizio fallito con un client manuale

Se avete avviato un client a mano dopo il fallimento del servizio, il suo output va altrove e il suo comportamento può essere diverso. Catturate il nuovo risultato dallo stesso proprietario e dalla stessa richiesta dopo una correzione supportata, così il confronto mostra cosa è cambiato invece di mescolare due programmi diversi.

Non modificate le marche temporali originali per allinearle a un altro host. Annotate separatamente il fuso orario e l’eventuale differenza di orologio nota, perché una cronologia che avete modificato non è più una prova.

Condividete un estratto, non un’esportazione

Le voci del log possono contenere nomi utente, indirizzi di endpoint, topologia privata e informazioni sull’ambiente degli script. Esaminate l’estratto reale e oscurate ciò che è sensibile invece di pubblicare un’esportazione completa e senza restrizioni. Citate le righe che dimostrano il fallimento e riassumete il resto. Un breve estratto rivisto è più facile da usare di un file che nessuno legge.

Inviate la finestra stretta, il nome dell’unità e la prima fase fallita, e dite cosa avete già escluso. Il manuale di systemd journalctl documenta i selettori e le opzioni di output se avete bisogno di un formato che la versione della distribuzione supporti.