Riconnettere un client OpenVPN: tre controlli, tre ambiti

Qualcuno chiede di riconnettere il client VPN, e quella richiesta può significare tre cose diverse. Può significare eliminare una sessione autenticata, avvisare ogni client che un server UDP sta andando via, o riavviare il demone stesso. Ognuna ha un raggio d’impatto diverso, e la scelta sbagliata trasforma una correzione per un utente in un’interruzione. L’ambito è la decisione, e il comando ne deriva.

Chiedete chi deve essere interessato prima di chiedere quale controllo usare.

Una istanza: l’interfaccia di gestione

Un’interfaccia di gestione configurata può elencare le istanze connesse ed eliminarne esattamente una. Ogni sessione porta un identificatore di client, e client-kill CID punta a quell’identificatore anziché a un nome comune. Leggete l’identificatore vivo dall’output di stato corrente, perché un valore copiato da un log più vecchio si riferisce a una sessione che non esiste più. Eliminare l’istanza termina quella connessione e nulla di più.

Non garantisce una nuova connessione. Che il client torni dipende dalle sue impostazioni di nuovo tentativo, dalle voci remote che gli restano, dai suoi requisiti di autenticazione e dal fatto che l’applicazione di supervisione sia ancora in esecuzione. Un client che torna ottiene un nuovo identificatore, e per questo confrontare gli identificatori è l’unico modo affidabile per distinguere il vecchio dal nuovo.

Un avviso di uscita UDP non è un comando per client

explicit-exit-notify è una direttiva di configurazione sugli eventi di uscita e riavvio. Su un client UDP dice all’interlocutore che la sessione sta finendo, e l’argomento numerico controlla quante volte l’avviso viene ripetuto. Quando il server funziona su UDP invia un messaggio di controllo di riavvio ai client connessi, e i valori documentati distinguono la riconnessione allo stesso server dal passaggio a un’altra voce remota. È un segnale del ciclo di vita con un pubblico ampio.

Niente in esso seleziona un client arbitrario in un momento arbitrario. Trattarlo come un pulsante di riconnessione raggiunge tutte le sessioni connesse insieme.

I segnali agiscono sul processo, non su una sessione

SIGUSR1 chiede a un processo in esecuzione di riavviare la propria connessione senza rileggere la configurazione, e le opzioni di persistenza decidono cosa sopravvive a quel riavvio. SIGHUP va oltre: rilegge il file di configurazione e riapre le sue risorse. SIGTERM e SIGINT chiedono uno spegnimento ordinato. Sono operazioni a livello di processo: su un server multi-client toccano ogni sessione che il processo porta, non quella indicata nel ticket.

Quando il processo gira sotto un gestore di servizi, usate il controllo del gestore stesso invece di inviare un segnale a un PID trovato in un elenco di processi. Leggete l’unità per vedere quale segnale invia il gestore, perché un riavvio e un ricaricamento fanno cose diverse allo stesso demone.

Decidete l’ambito prima di scegliere il controllo

Tre domande lo risolvono. Chi deve essere interessato: un utente, ogni client di un server, o il demone e tutto ciò che porta. Cosa deve sopravvivere: la configurazione, lo stato del tunnel o nessuno dei due. Chi è autorizzato: l’integrazione di gestione, il titolare del servizio o l’operatore di rete che controlla l’avviso di uscita. Rispondete e solo un controllo si adatta.

Aggiungere un ascoltatore di controllo non autenticato per ottenere un pulsante di riconnessione consegna a chiunque raggiunga la porta molto più di quel pulsante.

Verificate la nuova sessione, non la disconnessione

Un evento di disconnessione dimostra che la vecchia sessione è finita. Non dice nulla di una nuova che si autentica, riceve un indirizzo, installa rotte o raggiunge la risorsa di cui l’utente aveva bisogno. Controllate il nuovo identificatore, poi lo stato del tunnel, poi una risorsa reale. Quei tre passi sono la differenza tra una riconnessione e una connessione che funziona.

Scrivete l’ambito nel registro delle modifiche. «Ho riconnesso il client» non è una descrizione quando il client era uno di quaranta su un server condiviso.