Hook lato client o hook lato server? Dove viene eseguito uno script OpenVPN

Il compito è chiaro: quando un portatile si connette, qualcosa sul portatile dovrebbe cambiare. La configurazione che si sta modificando appartiene al server, ed è lì che l’ipotesi si rompe. Un percorso in un file del server indica un file su quel server, e nessuna quantità di push cambia quale processo lo esegue. Scegliere tra i due hook è soprattutto decidere quale macchina possiede il lavoro e accettare i limiti che ne derivano.

Due macchine, due domande a cui rispondere prima

Chiedetevi dove deve avvenire il cambiamento di stato, poi quale evento vi corrisponde. Se il cambiamento è un’autorizzazione per utente o una decisione di configurazione per client, appartiene a dove è nota la directory degli utenti: il server. Se il cambiamento è una rotta, un’impostazione del resolver o un helper locale su un endpoint, appartiene all’endpoint, e solo l’endpoint può farlo.

Rispondere a queste due domande nell’ordine inverso è come la gente finisce per provare a spingere un file batch su un portatile Windows. Il server sa chi si è connesso; il portatile sa com’è la propria pila di rete. Nessuno dei due ha le informazioni dell’altro, e il tentativo di solito fallisce in silenzio invece che con un errore chiaro.

Prima di entrambe vale la pena una terza domanda: la piattaforma espone davvero l’hook che volete? Un apparato che genera da sé la propria configurazione potrebbe non offrire gli stessi nomi di evento, e un client desktop che importa un file .ovpn non è necessariamente lo stesso client per cui il file è stato scritto. Confermare prima la piattaforma vi risparmia di progettare intorno a un hook che lì non esiste. Vi dice anche quale documentazione si applica davvero alla macchina che avete davanti.

L’opzione lato server: un evento per connessione

Uno script client-connect viene eseguito nel contesto del processo del server quando un client autenticato si connette, e riceve dettagli di connessione documentati come il common name e l’indirizzo assegnato. È il posto giusto per scrivere un frammento di configurazione per client, applicare una decisione di policy o registrare stato che il server possiede.

La distinzione che la gente perde è la differenza tra quell’hook e un hook up del server. L’hook up scatta quando il server apre il proprio dispositivo tunnel, cosa che su un server multi-client avviene una volta all’avvio del demone. Non è un evento per login, e il codice inserito lì viene eseguito all’avvio del servizio anziché quando gli utenti si connettono.

Su un apparato con interfaccia web, usate il meccanismo di estensione supportato invece di modificare i file del demone generati. I file generati vengono riscritti al salvataggio successivo, e la riscrittura rimuove in silenzio la vostra modifica nel momento peggiore. Conservate una copia del testo dell’estensione fuori dall’apparato, così che un aggiornamento del firmware non perda anche l’intento.

L’opzione lato client: lavoro che deve girare in locale

Un client della comunità può eseguire uno script locale quando il dispositivo tunnel appare e di nuovo quando vengono installate le rotte. Sono due momenti diversi, e scegliere quello sbagliato produce la classica corsa in cui un helper parte prima che esista la rotta da cui dipende.

L’helper deve esistere su quel client, essere leggibile ed eseguibile dall’account che esegue il client, ed essere consentito da un’impostazione script-security esplicita. Uno script che funziona quando avviate il client come amministratore non vi dice nulla su un servizio precedente al login né sulla sessione di un altro utente.

Anche i nomi contano. L’hook up corrisponde alla creazione del dispositivo e route-up all’installazione delle rotte, ma un’attività che richiede che una rete privata sia raggiungibile deve verificare la raggiungibilità invece di presumere che la creazione del dispositivo implichi che ogni rotta, voce del resolver e applicazione siano pronte.

Perché spingere codice eseguibile non è fra le opzioni

Le opzioni spinte con push sono volutamente limitate, e le opzioni che eseguono script rientrano fra le categorie che il server non può trasmettere. Quel vincolo esiste perché l’alternativa permetterebbe a un server compromesso o mal configurato di eseguire comandi arbitrari su ogni client che si connetta mai.

Abilitare l’esecuzione di script in locale non cambia questo. La vostra impostazione script-security consente gli script locali che avete scelto; non autorizza il server a fornirne di nuovi.

Se l’obiettivo è semplicemente installare rotte VPN, usate la configurazione delle rotte supportata invece di inventare uno schema di esecuzione remota. Se l’obiettivo richiede davvero codice locale, distribuitelo tramite gli strumenti di gestione degli endpoint dell’organizzazione e riesaminatelo come qualsiasi altro software che gira con i privilegi dell’utente.

Cosa verificare prima di fidarvi di uno dei due hook

Annotate quattro cose per ogni hook: la macchina, il nome dell’evento, l’account con cui viene eseguito e il cambiamento di stato che dovrebbe produrre. Poi provate la connessione, una riconnessione e il percorso di pulizia, perché un hook che perde stato alla riconnessione è peggio di uno che non è mai partito.

Provate con l’account che lo eseguirà davvero, nel momento in cui verrà davvero eseguito. Il manuale openvpn(8) documenta entrambe le famiglie di hook e le restrizioni del push; la piattaforma su cui distribuite documenta se le espone o no. Uno script che riesce in un terminale amministratore interattivo è un’ipotesi, non una verifica.