Da Access Server a Community OpenVPN: cosa va ricostruito

Access Server e Community OpenVPN parlano lo stesso protocollo e quasi nient’altro allo stesso modo. L’handshake, la negoziazione dei cifrari e il piano dati del tunnel sono compatibili, quindi un client spesso si connette all’uno o all’altro senza modificare il profilo. La differenza è chi possiede la configurazione: un prodotto fornisce uno strato di gestione che scrive e applica la politica, l’altro ti consegna un file di configurazione e una serie di hook e si aspetta che decida tu.

Quella distinzione è il piano di migrazione. Tutto ciò che il vecchio prodotto decideva per te deve diventare una decisione esplicita da qualche parte nel nuovo deployment.

Dove i due deployment smettono di essere intercambiabili

In Access Server, l’interfaccia web di amministrazione possiede utenti, gruppi, permessi per utente, emissione dei certificati e il pacchetto di profilo che una persona scarica. Il demone sottostante è configurato da quello strato, quindi il servizio in esecuzione è il prodotto di uno stato memorizzato che raramente modifichi a mano. In Community OpenVPN il file di configurazione è lo stato: nomina il listener, l’autorità di certificazione, l’hook di autenticazione e ogni opzione inviata, e nulla lo riscrive per te. La stessa macchina TLS sta quindi sotto due modelli di proprietà molto diversi.

Una breve mappatura rende concreto il divario. Utenti e gruppi esistono solo nel vecchio database finché non li ricrei. I pacchetti di profilo diventano un file di configurazione più certificati che distribuisci tu stesso. I permessi per utente diventano direttive in client-config-dir. L’interfaccia di amministrazione diventa il processo che scegli per emettere certificati e modificare file.

Scrivi quella mappatura prima di toccare un server. Ogni riga che non riesci a compilare è una funzionalità che stai per perdere, e perderla in silenzio è il modo in cui una migrazione diventa un’interruzione due settimane dopo.

L’identità non si trasferisce con i file dei certificati

I certificati della vecchia autorità possono essere analizzati correttamente nel nuovo servizio e restare comunque l’identità sbagliata, perché il vecchio prodotto li abbinava a uno stato dell’account che il nuovo non vede. Decidi prima se il nuovo deployment autentica solo con certificato, con un plugin che raggiunge PAM o RADIUS, o con una combinazione, poi verifica che ogni opzione conservi le proprietà che ti servono. Un certificato condiviso senza identità per utente è un’unica credenziale per tutti quelli che lo possiedono. Anche la revoca deve funzionare dal primo giorno, il che in Community OpenVPN significa un file CRL a cui crl-verify fa riferimento più un processo che lo rigenera.

Pianifica l’iscrizione prima del passaggio, non dopo. Nuovi certificati, un percorso di revoca collaudato e un modo documentato per disabilitare una persona sono prerequisiti, non lavoro successivo. Se l’autenticazione a più fattori veniva dall’integrazione del vecchio prodotto, nomina esplicitamente il sostituto, perché un plugin non installato fallisce chiuso nel momento peggiore.

Il routing e la risoluzione dei nomi seguono chi scrive la configurazione

Rotte, impostazioni DNS e comportamento del tunnel completo sono opzioni inviate in entrambi i prodotti, ma solo uno le calcola per te. In Community OpenVPN scrivi tu le direttive push, decidi se redirect-gateway appartiene al server o al client e confermi che inoltro e NAT esistano sull’host. Un handshake completato non ti dice nulla su inoltro, traduzione degli indirizzi o rotte che il client ha realmente ricevuto.

Il comportamento per client richiede client-config-dir più un file nominato secondo il common name del certificato del client, e un peer site-to-site richiede voci iroute per i prefissi che stanno dietro. Se il nome è sbagliato, le opzioni vengono ignorate senza errore. Prova con un client non di produzione nel suo pool di indirizzi, poi leggi l’indirizzo assegnato, le rotte ricevute e le impostazioni del resolver con cui è finito.

Scandisci il passaggio perché il vecchio servizio possa tornare

Esegui il nuovo listener su una porta o un indirizzo diversi e lascia che il vecchio serva traffico mentre dimostri il sostituto. Due demoni sullo stesso socket non sono un piano di rollback.

Sposta un gruppo alla volta, con i suoi certificati, il suo pool e le sue rotte, e prova il percorso di ritorno invece di scoprirlo durante un incidente. Un rollback che funziona solo se prima si ferma il nuovo servizio è comunque un rollback, ma va testato mentre nulla è in fiamme.

Infine elenca le funzionalità senza equivalente diretto e decidi per iscritto il destino di ciascuna: download del profilo in self-service, flag di permesso per utente, l’interfaccia amministrativa stessa, il reporting delle connessioni in tempo reale. Sostituirle con un processo manuale documentato è una risposta legittima. Lasciare la riga vuota non lo è.

Il lavoro è finito quando una persona che non ha mai visto il vecchio portale può iscriversi, connettersi, raggiungere l’indirizzo interno previsto ed essere revocata in modo pulito. Tutto ciò che precede è preparazione.