Socket di gestione di OpenVPN: un canale di controllo, non metriche

Chiedi uno stato all’interfaccia di gestione una volta e inizia a sembrare una porta di stato. Non lo è. Una volta ammesso un client, può emettere i comandi di controllo del protocollo, e l’account che esegue quel client eredita tutto ciò che quei comandi possono fare al demone. Trattarlo come un flusso in sola lettura è l’errore che trasforma un’integrazione di monitoraggio in una console non autenticata.

La convinzione, e quanto costa

La convinzione è che l’ascoltatore di gestione equivalga a un endpoint di metriche: collega un raccoglitore, leggi i contatori, vai avanti. In realtà il raccoglitore apre una sessione con capacità di controllo, e ogni altra ipotesi fatta sul deployment ora dipende dal fatto che quel raccoglitore si comporti bene.

Niente nell’interfaccia pubblicizza una modalità in sola lettura. Non c’è alcun ruolo di osservatore da scegliere, e un nome utente nella configurazione non ne crea uno.

Ciò che detiene davvero un client ammesso

Il demone della community accetta un solo client di gestione attivo alla volta. Quello slot unico significa che una GUI, uno script e un agente di monitoraggio non possono collegarsi tutti; il secondo attende o fallisce mentre il primo tiene la sessione. Se il tuo progetto presuppone lettori simultanei, è già sbagliato.

Dove basta uno snapshot periodico, l’output del file di stato dà gli stessi numeri senza una sessione attiva. Scrivere quel file a intervalli e leggerlo con normali permessi di file tiene il raccoglitore completamente fuori dal piano di controllo, ed è la disposizione di cui la maggior parte del monitoraggio ha davvero bisogno.

Un socket posseduto, non uno aperto

Un socket di dominio Unix tiene il percorso di controllo fuori dalla rete, il che elimina dal problema l’indirizzo del tunnel che cambia. Non elimina la questione dei permessi. La directory padre deve essere scrivibile dall’account del servizio e raggiungibile dall’account del controller, e sono due autorizzazioni separate:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

Il file delle password porta il segreto di gestione nella sua prima riga. Proteggi quel file come qualsiasi altra credenziale e tieni il suo contenuto fuori dai log e dai ticket di supporto. Le restrizioni di utente e gruppo sono controlli del peer sul socket Unix, non permessi del file system, quindi il processo previsto ha bisogno sia dell’accesso al file sia dell’identità corrispondente.

Rendere il socket accessibile a tutto il mondo per risolvere un errore di permessi è l’unica correzione da evitare. Trasforma un canale di controllo locale in qualcosa che qualsiasi processo sull’host può pilotare.

Pubblicarlo su TCP non è lo stesso progetto

Spostare l’ascoltatore su una porta TCP non lo rende più sicuro o più comodo. La password di gestione viene inviata in chiaro, quindi un ascoltatore TCP espone sia la credenziale sia la sessione a chiunque possa osservare il percorso. Raggiungerlo da un altro host richiede un canale di amministrazione autorizzato, o un piccolo agente locale che espone solo le osservazioni di cui hai bisogno.

Una password su un trasporto in chiaro è autenticazione senza riservatezza, e quella combinazione è peggiore di quanto sembri perché dà l’impressione di essere protetta.

Dipendenze di avvio che non hai chiesto

Diverse opzioni di gestione cambiano il ciclo di vita del demone. Trattenere l’avvio finché un controller non si connette, o terminare quando il controller scompare, trasforma un osservatore opzionale in una dipendenza rigida. Un agente di monitoraggio che va in crash porterebbe giù anche il tunnel.

Esamina quelle opzioni prima di abilitare qualsiasi cosa oltre al socket stesso. L’osservazione opzionale dovrebbe restare opzionale, e una politica di riavvio non dovrebbe essere accoppiata a un raccoglitore aggiunto per i grafici.

Un file di socket rimasto dopo un processo fallito non è prova che esista un ascoltatore. Identifica quale istanza possiede il percorso prima di rimuoverlo, e usa il flusso di ripristino del servizio stesso invece di eliminare file sotto un demone in esecuzione.

Come appare l’accettazione

Quattro controlli coprono il progetto: l’identità prevista del controller si connette, un processo senza quell’identità viene rifiutato, il demone sopravvive a un controller che si disconnette senza avviso, e il tunnel continua a trasportare traffico attraverso un riavvio controllato. Una connessione di gestione riuscita dimostra solo il piano di controllo. Non dice nulla sul funzionamento del traffico delle applicazioni private, quindi provalo separatamente. Annota i quattro risultati dove il prossimo operatore può trovarli.

La documentazione dell’interfaccia di gestione descrive il modello a client singolo e la natura privilegiata del protocollo, ed è la parte che vale la pena leggere prima di puntarci una dashboard.