ConnMan VPN: il menu mancante è un demone, non un protocollo

La convinzione è che un sistema ConnMan senza voce VPN sul desktop non abbia alcun supporto VPN installato. Di solito ha il supporto per il Wi-Fi e nessuno per il demone VPN, la configurazione del fornitore o l’agente di autenticazione, e queste sono tre assenze separate. Il menu è una vista su quei componenti, non la funzionalità stessa. Controllare la versione e il packaging ti dice più in un comando di qualsiasi numero di segnalazioni di bug dal desktop.

Il mito: il menu è la funzionalità VPN

Parti dalla versione installata di ConnMan e dai pacchetti che l’hanno accompagnata. Una segnalazione di bug di una release più vecchia descrive un diverso insieme di funzionalità, e citarla di solito finisce con qualcuno che reinstalla un gestore di rete che non serviva sostituire.

Annota ciò che hai davvero prima di cambiare qualcosa: il binario del demone, la directory dei fornitori e se è presente un agente.

Quale demone possiede il tunnel

Nella documentazione di ConnMan 1.41 per Debian bookworm, connman-vpnd è il demone che gestisce le connessioni VPN accanto a connmand. Elenca integrazioni per helper VPN con un nome, tra cui OpenVPN e OpenConnect. Quell’elenco è un’affermazione sugli helper, non una promessa che ogni protocollo o flusso di autenticazione funzionerà. Leggilo come un menu di ciò che va controllato, non come una garanzia di compatibilità.

Poi abbina l’integrazione al protocollo approvato del gateway. La parola Cisco non ti dice se serve una connessione in vecchio stile vpnc o un flusso compatibile con AnyConnect, e la scelta sbagliata produce un errore di autenticazione che sembra un problema di credenziali.

Se sia un helper autonomo sia ConnMan possono alzare il tunnel, decidi quale dei due possiede rotte, DNS e ciclo di vita prima che uno dei due parta.

Le impostazioni del demone non sono quelle del fornitore

La configurazione generale del demone e quella di un singolo fornitore sono file diversi con formati diversi. Nella disposizione documentata di bookworm il demone legge /etc/connman/connman-vpn.conf, mentre i file di provisioning dei fornitori risiedono sotto /var/lib/connman-vpn/ con un suffisso .config. Mettere un profilo OpenVPN in quella directory non lo trasforma in un file di provisioning di ConnMan. Il manuale del fornitore per questa versione descrive le sezioni del fornitore e i campi specifici del tipo di cui quei file hanno davvero bisogno.

Traduci solo attraverso la mappatura supportata dell’integrazione installata. La fiducia nel certificato, i riferimenti alla chiave privata, l’identità del gateway, le rotte e gli input di autenticazione mantengono ciascuno il proprio ruolo, e un esempio per un altro tipo di fornitore non è intercambiabile solo perché entrambi richiedono un indirizzo del server.

Quando un fornitore non si carica, confronta i suoi campi con il manuale della release installata invece che con un esempio di blog.

L’agente di autenticazione è una dipendenza separata

Una definizione di fornitore può comunque aver bisogno di un agente per ottenere credenziali o completare uno scambio di autenticazione. Per la sua integrazione OpenConnect, lo stesso manuale spiega che i valori legati all’autenticazione mancanti possono essere richiesti tramite l’API VPN Agent, e che un cookie di breve durata generalmente non è adatto come segreto di configurazione permanente. Quel meccanismo non garantisce il supporto per ogni accesso dal browser, ogni richiesta MFA o ogni controllo di postura del gateway. Conferma l’intero flusso con chi possiede il deployment.

Non compensare un agente assente scrivendo una password o un token di sessione in un file ampiamente leggibile. Questo trasforma un’integrazione mancante in un’esposizione di credenziali, e il secondo problema sopravvive al primo.

Se il gateway richiede un accesso interattivo, l’agente fa parte del progetto e non è un extra opzionale.

Verifica quattro esiti, non uno

Dopo un provisioning autorizzato, controlla quattro cose separatamente: il fornitore è selezionato, la connessione è autenticata, le rotte effettive sono quelle che volevi e il resolver si comporta come previsto. Un demone in esecuzione, un fornitore elencato e un’applicazione che raggiunge la sua risorsa sono tre esiti diversi, e solo l’ultimo è l’obiettivo reale dell’utente. Registrarli separatamente ti dice quale fase correggere.

Includi in quel controllo il comportamento di riconnessione e la politica di stato non disponibile richiesta, perché un tunnel che sale una volta e non si riprende mai non è distribuito. Mantieni recuperabile la configurazione di rete di base funzionante mentre cambi l’integrazione VPN.

Sostituire il gestore Wi-Fi per ottenere un pulsante è un cambiamento molto più grande dell’operazione mancante richiesta, e di solito è il mito che vince.