OpenVPN 3 Linux: leggi un errore D-Bus prima di tornare indietro

I guasti di OpenVPN 3 Linux arrivano come errore di metodo D-Bus con un nome sconosciuto allegato, e la tentazione è declassare un pacchetto e sperare. Il client non è un solo programma: un frontend a riga di comando parla sul bus con servizi che possiedono i profili, le sessioni, il motore VPN e le modifiche di rete privilegiate. Decidere quale di quei cinque possiede la chiamata che fallisce è la maggior parte della diagnosi, e costa un comando invece di un rollback. Quello che segue è quella decisione, nell’ordine in cui i guasti di solito compaiono.

Cinque proprietari dietro un comando

Cinque processi contano, e ognuno ha il proprio nome di bus: il frontend che accetta il tuo comando, il gestore di configurazione che conserva i profili e la loro politica di accesso, il gestore delle sessioni che possiede la durata delle sessioni, il backend che esegue la connessione tramite OpenVPN 3 Core Engine, e il servizio di configurazione di rete che installa l’interfaccia, le rotte e le impostazioni DNS. Un errore che nomina un oggetto di configurazione non è quindi un errore del backend, e un backend che non si avvia non è un guasto di autenticazione. Collocare il messaggio in una di quelle righe deve avvenire prima di cambiare qualsiasi cosa, perché ogni passo successivo dipende da quale riga è vera. Indovinare la riga è il modo in cui una correzione breve diventa un pomeriggio di lavoro sui pacchetti.

Chiedi al bus di sistema quali servizi sono presenti prima di chiedere qualsiasi altra cosa, poi conferma che i pezzi installati concordano su una versione. OpenVPN 3 Linux registra quei servizi come unità di sistema, quindi il bus da interrogare è quello di sistema, la query di versione richiede autorità amministrativa, e un elenco fatto con --user legge la tua sessione di accesso, dove le unità non compaiono mai. I servizi si attivano su richiesta e alcuni terminano quando sono inattivi, quindi un servizio assente prima della tua prima richiesta semplicemente non è ancora stato interrogato per nulla. I tre comandi sotto rispondono su presenza, versione e stato delle unità senza aprire una sessione VPN.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Che cosa dimostra davvero ciascun elenco

Le viste del client sono la prova più economica disponibile, e ciascuna di esse dimostra meno di quanto sembri. Un profilo nell’elenco di configurazione mostra che un profilo è importato e nulla sul fatto che qualcuno possa connettersi con esso. Una sessione nell’elenco delle sessioni mostra che esiste un oggetto sessione e nulla sul fatto che l’autenticazione remota sia terminata.

openvpn3 configs-list
openvpn3 sessions-list

I percorsi di oggetto in quegli output identificano oggetti gestiti sul bus e non file, quindi non possono essere modificati, e un percorso annotato prima diventa obsoleto nel momento in cui quella sessione si disconnette. Riusarne uno dai tuoi appunti produce errori "no such object" che non hanno nulla a che vedere con la VPN. La tabella delle fasi sotto separa ciò che ogni passo di una connessione stabilisce da ciò che lascia aperto, ed è proprio la distinzione su cui si basa una decisione di rollback. Leggi la riga che corrisponde alla tua prova, poi rileggi il testo dell’errore.

La chiamata di connessione ritorna prima che il tunnel esista

La chiamata di connessione ti consegna una sessione da osservare e ritorna, ed è per questo che una chiamata apparentemente riuscita seguita dal silenzio è uno stato intermedio normale e non una contraddizione. Il frontend deve comunque seguire i cambi di stato e rispondere a ogni richiesta di interazione. Un profilo che richiede una credenziale e non riceve risposta attende in uno stato che assomiglia esattamente a un backend bloccato. Quello stato di attesa merita di essere riconosciuto, perché manda le persone verso il componente sbagliato.

Mentre un tentativo è in corso, osserva l’elenco delle sessioni e il log del frontend per quel profilo. Una sessione che non lascia mai il suo stato iniziale nomina il componente che si è fermato, e il log di solito lo nomina nelle prime righe. Tieni a portata di mano il nome del profilo, dato che il comando di log prende un profilo e non un percorso di sessione, il che è un’altra ragione per rileggere l’elenco invece di riusare un percorso.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Leggere il log di un singolo componente senza aprire una sessione

Quando il frontend non riporta nulla di utile, vai a il componente che ha registrato il guasto invece di avviare un’altra connessione. Con un logger systemd-journald configurato, la vista di journal circoscritta dell’amministratore legge gli eventi di un componente senza toccare la politica del bus né aprire una sessione, il che conta perché una diagnosi che cambia il sistema che misura dimostra ben poco. Filtra per unità invece che per tag syslog: le singole unità di servizio non garantiscono un identificatore condiviso, quindi una query per tag può restituire una pagina vuota mentre l’unità stessa ha registrato il guasto.

Annota quattro campi prima di chiedere aiuto a qualcuno: il nome completo dell’errore, il servizio e l’oggetto coinvolti, la marca temporale e le versioni dei pacchetti installati. È ciò di cui ha bisogno chi mantiene il codice, e nulla di tutto ciò richiede di incollare un profilo o una credenziale in un ticket. Ampliare la politica di accesso al bus per silenziare l’errore non è una diagnosi, cancella il confine che stava nominando il componente per te. I contenuti privati dei profili restano fuori dai rapporti condivisi per la stessa ragione delle credenziali.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Correggere il confine che ha rifiutato

Ogni riga della mappa ha la propria correzione, e le righe non si sostituiscono l’una all’altra. Un’operazione negata su un profilo è una questione di politica e proprietà, mentre un backend che non si attiva è una questione di servizi e pacchettizzazione. Un server che rifiuta l’autenticazione non è nessuna delle due, quindi cambi di password ripetuti non possono riparare un problema di attivazione locale. Scegliere la correzione sbagliata è il modo in cui un problema di politica diventa una reinstallazione.

Dopo una modifica dei pacchetti, verifica un’installazione coerente e supportata invece di copiare un vecchio binario al suo posto. Un rollback controllato è una risposta legittima a una regressione confermata, purché i pacchetti restino compatibili ed esista una via di ritorno alla manutenzione supportata. Stabilisci quella via prima che il servizio smetta di avviarsi, non dopo.

Un’altra piattaforma può condividere la stessa libreria VPN di base senza condividere i servizi di bus di Linux, quindi un guasto dall’aspetto simile su Windows non dice nulla su questo. La panoramica D-Bus documenta i percorsi di oggetto esposti per configurazioni e sessioni, ed è la parte dell’architettura da cui dipende questa diagnosi. Leggila una volta, e il prossimo errore arriverà con un componente già attaccato.