Usiamo OpenVPN: protocollo, motore o applicazione? Cosa chiedere invece

La frase «usiamo OpenVPN» arriva nei ticket, nei moduli di acquisto e nei documenti di inserimento, e in ciascuno risponde a una domanda diversa. A volte indica un protocollo di trasporto, a volte il software su un gateway e a volte l'applicazione che un nuovo assunto deve installare. Questi tre fatti portano a passi successivi diversi, e chiedere quale sia quello inteso richiede meno tempo che indovinare. Il resto dell'indagine deriva da quella risposta.

Inizia separando il ruolo dal marchio, perché il marchio copre tutti e tre.

Il nome copre tre ruoli che falliscono in modi diversi

Come protocollo, OpenVPN descrive come peer compatibili stabiliscono un tunnel e proteggono ciò che lo attraversa. Come software, è un'implementazione che parla quel protocollo in un ruolo client o server. Come client, è un'applicazione che qualcuno installa, con la propria versione, il proprio formato di profilo e le proprie particolarità di piattaforma. Un guasto in un ruolo non implica un guasto in un altro, ed è per questo che «OpenVPN è giù» ha bisogno di un soggetto.

Chiedi cosa può vedere chi segnala: un file di profilo, un programma installato o un gateway che amministra. Quel singolo dettaglio ti dice se il passo successivo è un log del client, una domanda sul pacchetto o un controllo dell'ascoltatore lato server.

OpenVPN 2 e OpenVPN 3 non sono una coppia di aggiornamento

OpenVPN 2.x funziona sia in ruolo server sia client, ed è quello che la maggior parte delle distribuzioni gateway usa ancora. OpenVPN 3 è un'implementazione separata orientata al client, con la propria configurazione e il proprio modello di sessione, non la versione successiva da installare sopra un server 2.x. OpenVPN Connect è un'applicazione client costruita sul motore OpenVPN 3. Installare una qualsiasi di esse non crea un servizio di uscita internet; l'uscita è ciò che l'operatore ha configurato.

La compatibilità a livello di protocollo non si estende alle direttive del profilo, quindi un profilo che si importa senza errori può comunque fallire su una direttiva che il client non implementa.

Il trasporto non è l'applicazione al suo interno

La connessione esterna usa un trasporto come UDP o TCP per raggiungere un ascoltatore configurato, e tutto ciò che il tunnel trasporta viaggia al suo interno. Una richiesta web fatta attraverso la VPN non ha bisogno di un proprio ascoltatore OpenVPN e non diventa un pacchetto OpenVPN sul filo. In modalità TLS il canale di controllo negozia il materiale delle chiavi mentre il canale dati protegge il carico utile, ed è una separazione che vale la pena tenere corretta quando si leggono i log.

Confondere i livelli produce richieste come aprire una porta per un sito che funziona già attraverso il tunnel. La porta appartiene alla connessione esterna, non all'applicazione.

Cosa può promettere un profilo e cosa no

Un profilo dice a un client come raggiungere un servizio: punto finale, trasporto, materiale di identità e spesso alcune preferenze di instradamento e DNS. Non dice nulla su chi gestisce quel servizio né se l'account è autorizzato. Rotte, impostazioni del resolver, regole di inoltro e politica di accesso decidono a cosa arriva davvero la sessione. Un profilo che si importa correttamente è l'inizio di una connessione funzionante, non la sua prova.

Quando qualcuno chiede se una risorsa è raggiungibile tramite la VPN, la risposta dipende dalla politica del server e non dal file di configurazione del client.

Chiedi ciò che può essere fornito

Trasforma il nome ampio in tre elementi concreti: il client e la sua versione, il profilo autorizzato per quel client e la risorsa che la persona deve raggiungere. Con questi, il provisioning è un compito concreto. Senza di essi, ogni risposta è una supposizione su quale OpenVPN intendesse la domanda.

Annota la risposta nella richiesta stessa. Il prossimo ticket porrà la stessa domanda nello stesso modo ambiguo.