OpenVPN push-peer-info: etichettare i client senza concedere accesso

I tag di distribuzione sono il motivo abituale per cui si ricorre a questa funzione: ogni connessione dovrebbe portare qualcosa come un sito o un ruolo, e il server dovrebbe leggerlo senza inventare un secondo formato di credenziali. OpenVPN community ha già il meccanismo, ed è piccolo. La parte che fa male sono le aspettative. Impostare una variabile ordinaria nel profilo del client non fa nulla sul server, e un valore che pure arriva dimostra solo che il client lo ha inviato.

Questa è una guida operativa per il percorso funzionante, il passo di verifica che mostra cosa è realmente arrivato e il rollback che non lascia hook a metà configurazione. Nulla qui richiede un nuovo certificato, un nuovo plugin o un’estensione del protocollo.

Imposta la variabile e abilita il percorso

Due righe fanno il lavoro nel profilo del client, ed entrambe sono necessarie. Senza la prima non c’è nulla da inviare; senza la seconda il client non offre affatto informazioni sul peer. L’ordine non conta, e vale la pena saperlo perché le due righe finiscono spesso in parti diverse di un profilo generato. L’importante è che entrambe sopravvivano a qualunque riscrittura del profilo prima che il client lo legga.

setenv UV_DEPLOY field-support
push-peer-info

Il prefisso UV_ non è decorazione. Una variabile DEPLOY normale resta locale al processo del client e non viene mai inoltrata, mentre la forma con prefisso è lo spazio dei nomi che il protocollo riserva ai campi definiti dall’utente. Lascia intatto il resto del profilo approvato e conferma che la build del client che distribuisci supporti entrambe le direttive prima di distribuirla.

Un controllo pratico va fatto qui e non alla fine: assicurati che la direttiva raggiunga il binario del client e non venga inghiottita da un wrapper. Un client grafico che genera la propria riga di comando, o un’interfaccia di gestione che ricarica un profilo salvato, può scartare righe che non riconosce. Se il server non vede nulla, questo è il primo posto da guardare.

Leggi il campo da un hook del server

Lato server, le informazioni sul peer ricevute vengono validate e inserite nell’ambiente del flusso di connessione, ed è questo che le rende leggibili da un hook senza alcun lavoro di protocollo da parte tua. Il server non deve analizzare il canale di controllo né memorizzare nulla per te; il valore è semplicemente presente mentre la connessione viene impostata. Uno script client-connect minimo che registra l’etichetta accanto al nome autenticato ha questo aspetto.

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

Leggi la variabile tramite l’ambiente invece di analizzare il log, e dalle sempre un valore predefinito. ${UV_DEPLOY:-unset} mantiene lo script funzionante per i client che non inviano mai il campo, che è lo stato normale durante un rilascio graduale. Non riversare l’intero ambiente in un log per trovare il nome; contiene molto più dell’etichetta, inclusi valori che non intendevi conservare.

Esegui lo script a mano e segnalerà unset per tutto, perché una shell manuale non porta con sé l’ambiente della connessione. Non è un bug dello script e non è la prova che il campo manchi. Provalo tramite una connessione reale, l’unico contesto in cui la variabile esiste.

Verifica cosa è realmente arrivato

Collega un client con l’etichetta e uno senza, poi leggi il file. La coppia è il test: una riga dovrebbe portare il valore e l’altra il valore predefinito, ed entrambe dovrebbero indicare la stessa identità autenticata che ti aspetti.

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

Quelle righe di commento sono la forma dell’output, non una trascrizione dal tuo server; leggi il tuo file. Se anche il secondo client mostra un valore, la variabile è impostata altrove nell’ambiente, e stai leggendo un’impostazione obsoleta invece del campo peer.

Controlla anche il log del server per la connessione. Le informazioni sul peer possono comparire lì, il che è comodo per il debug e un motivo per mantenere i valori noiosi: nessun nome di persona, nessun numero di ticket, nulla che non vorresti che un lettore del log vedesse.

Tratta l’etichetta come un’affermazione, non un’identità

Chiunque possa modificare il profilo del client può cambiare il tag, e il fatto che il tunnel sia autenticato non rende autorevole il tag. Il trasporto protegge il valore in transito; non certifica l’affermazione. L’autorizzazione appartiene ancora all’identità autenticata e a un record di iscrizione posseduto dal server, con l’etichetta confrontata con quel record quando conta.

Questa distinzione decide dove l’etichetta può essere usata. Gli usi buoni sono instradare una sessione al file di log giusto, scegliere un gruppo di visualizzazione in una dashboard o etichettare una sessione di supporto perché una persona la trovi più tardi. Gli usi cattivi sono ammettere un dispositivo in una sottorete, selezionare una politica del firewall o decidere quali dati di un cliente la sessione può leggere.

Valida il valore prima che raggiunga un percorso, una query o un comando shell. Una lista di autorizzazione di stringhe attese basta per un tag di distribuzione, e non costa nulla. Non interpolare mai una stringa fornita dal peer in una riga di comando shell, e limita qualsiasi osservazione memorizzata alla sessione e non a un indirizzo del tunnel che il prossimo client riutilizzerà.

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

Fai rollback in modo pulito

Rimuovere la funzione sono due cancellazioni e una verifica. Elimina le righe setenv e push-peer-info dal profilo del client, poi rimuovi o disabilita l’hook e la sua destinazione di log sul server.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

Ricollega un client in seguito e conferma che la riga di log smetta di comparire. Un hook che continua a scattare dopo la modifica del profilo è di solito un secondo profilo ancora distribuito su un dispositivo di test, e trovarlo adesso costa meno che trovarlo durante un audit.

Ciò che resta alla fine è un piccolo, limitato frammento di metadati di sessione con origine documentata: il client lo afferma, il server lo registra, e nulla dell’accesso dipende da esso. È la versione utile della funzione, e non serve alcuna nuova credenziale per arrivarci.