OpenVPN Access Server o Community: cosa migra davvero

I profili migrano; gli elenchi utenti restano indietro. Un team che passa tra Access Server e Community Edition incontra quel vuoto un’ora dopo il passaggio, quando il suo primo client si autentica e poi non ha criteri di gruppo, né route per utente, né reimpostazione della password in self-service. Entrambi i prodotti parlano lo stesso protocollo e accettano lo stesso client, ed è proprio per questo che il vuoto resta invisibile durante la pianificazione. Ciò che scegliete davvero è lo strato di gestione e le persone che lo possiedono.

Trattate la decisione come una questione di inventario, non come una griglia di funzioni. Chiedete chi crea utenti, chi revoca certificati e chi risponde alla chiamata alle 02:00.

Perché il file .ovpn non porta con sé la configurazione

Un profilo .ovpn descrive la relazione di un client con un server: l’host remoto, il protocollo, la CA, un certificato e una chiave client, e qualsiasi materiale tls-crypt inline. Deponete quel file in un’installazione nuova e il client completa comunque l’handshake, così la migrazione sembra finita. Nulla in esso elenca gli utenti, i loro gruppi, le loro route statiche o il criterio che decideva chi poteva connettersi. Quei record vivono nello spazio di archiviazione del server stesso, e i due prodotti li conservano in forme diverse.

In Community Edition gli equivalenti sono file che tenete voi: voci client-config-dir con opzioni per client come ifconfig-push e iroute, una CRL per le revoche e la chiave tls-crypt. Access Server conserva gli stessi concetti nel proprio database e li espone tramite una console web e lo strumento da riga di comando sacli. I concetti si corrispondono uno a uno; gli artefatti non si spostano affatto.

I profili introducono anche di nascosto comportamenti che nessuno nota finché non cambiano. Un client con redirect-gateway def1 manda tutta la navigazione attraverso il server; spostatelo in un’installazione senza quella riga e la lamentela sarà che si è rotto internet. Un disallineamento della CA o un’impostazione remote-cert-tls errata fallisce rumorosamente, che è il buon esito. Una chiave tls-crypt mancante fallisce come timeout silenzioso, che non lo è.

Cosa possiede lo strato di gestione

Contate ciò che non è protocollo: creazione di account, reimpostazione delle password, assegnazione ai gruppi, iscrizione MFA, diritti di connessione e la traccia di controllo che risponde chi si è connesso e quando. Community Edition non ne fornisce nessuno direttamente. Scegliete un backend di autenticazione, collegate PAM, LDAP o RADIUS tramite un plugin o auth-user-pass-verify, e manutenete il resto da soli. Access Server fornisce un portale utente, una console di amministrazione e integrazioni con i provider di identità comuni. Nessuna delle due soluzioni è più sicura per impostazione predefinita, perché il criterio deve comunque essere scritto da qualcuno che conosce la rete.

I diritti di connessione sono la differenza operativa più netta. Access Server è concesso in licenza per numero di connessioni simultanee e applica quel numero via software. In Community Edition un tetto globale è una sola riga max-clients, mentre qualsiasi cosa per utente o per gruppo comporta più lavoro con client-config-dir e la vostra applicazione. Un team senza voglia di quella manutenzione compra esattamente questo quando paga il prodotto commerciale.

Licenze e supporto: la voce che nessuno mette a budget

Community Edition è gratuito e open source. Access Server è commerciale, e il suo livello gratuito ha storicamente coperto un piccolo numero di connessioni simultanee, con una licenza a pagamento al di sopra. Qualsiasi cifra citata in una vecchia risposta di forum è ormai obsoleta, quindi verificate i termini attuali del fornitore prima di calcolare il progetto. Il confronto onesto somma le ore spese a costruire gestione utenti, MFA e monitoraggio lato community alla voce di licenza lato commerciale.

La proprietà del supporto segue la stessa divisione. Con Community Edition siete voi il percorso di escalation per ogni client strano e ogni aggiornamento del kernel. Con Access Server avete un fornitore da chiamare, e ereditate il suo ritmo di rilascio, che si adatti o meno alla vostra finestra di cambiamento.

Verifiche da fare prima del passaggio

Inventariate ciò che il server in funzione contiene davvero prima del passaggio in entrambe le direzioni. Lato Access Server, esportate l’elenco utenti e le assegnazioni di gruppo e annotate quali account dipendono da MFA. Lato Community Edition, elencate i certificati emessi, la CRL e ogni file sotto client-config-dir. Confrontate i due elenchi riga per riga, perché la differenza tra loro è il lavoro di migrazione.

Provate client rappresentativi mentre il vecchio servizio è ancora attivo. openvpn --config client.ovpn --verb 4 in primo piano stampa l’handshake, le route inviate e le opzioni DNS, e openssl x509 -in client.crt -noout -subject -enddate mostra quale certificato il client presenta realmente. Un client che si connette ma non raggiunge un host interno ha un vuoto di route o di iroute, non un errore di autenticazione.

Mantenete vivo il vecchio percorso di ripristino finché il sostituto non supera una prova di accesso negato oltre a una riuscita. Scrivete la mappa finale su una sola pagina: ogni requisito, l’artefatto che lo soddisfa oggi e l’artefatto che lo soddisferà dopo.