D'Access Server a Community OpenVPN: que cal reconstruir

Access Server i Community OpenVPN parlen el mateix protocol i gairebe res mes de la mateixa manera. L'apretada de ma, la negociacio de xifratges i el pla de dades del tunel son compatibles, aixi que un client sovint es pot connectar a qualsevol dels dos sense editar el perfil. La diferencia es qui posseeix la configuracio: un producte inclou una capa de gestio que escriu i aplica la politica, mentre que l'altre et dona un fitxer de configuracio i un conjunt de ganxos i espera que decideixis tu.

Aquesta distincio es el pla de migracio. Tot el que el producte antic va decidir per tu ha de convertir-se en una decisio explicita en algun lloc del desplegament nou.

On els dos desplegaments deixen de ser intercanviables

A Access Server, la interficie web d'administracio posseeix usuaris, grups, permisos per usuari, emissio de certificats i el paquet de perfil que una persona descarrega. El dimoni que hi ha a sota es configura amb aquesta capa, aixi que el servei en marxa es el producte d'un estat desat que poques vegades edites a ma. A Community OpenVPN, el fitxer de configuracio es l'estat: anomena l'oient, l'autoritat de certificacio, el ganxo d'autenticacio i cada opcio empenyuda, i res no el reescriu per tu. La mateixa maquinaria TLS, doncs, se soste sota dos models de propietat molt diferents.

Un mapatge breu fa concret el buit. Els usuaris i els grups nomes existeixen a la base de dades antiga fins que els recrees. Els paquets de perfil es converteixen en un fitxer de configuracio mes certificats que distribueixes tu mateix. Els permisos per usuari es converteixen en directives dins de client-config-dir. La interficie d'administracio es converteix en qualsevol proces que triis per emetre certificats i editar fitxers.

Escriu aquest mapatge abans de tocar cap servidor. Cada fila que no puguis omplir es una funcio que estas a punt de perdre, i perdre'n una en silenci es com una migracio es converteix en una caiguda dues setmanes despres.

La identitat no es trasllada amb els fitxers de certificat

Els certificats de l'autoritat antiga poden analitzar-se correctament al servei nou i tot i aixi ser la identitat equivocada, perque el producte antic els aparellava amb un estat de compte que el nou no pot veure. Decideix primer si el desplegament nou autentica nomes per certificat, amb un connector que arribi a PAM o RADIUS, o amb alguna combinacio, i despres comprova que cada opcio conserva les propietats que necessites. Un certificat compartit sense identitat per usuari es una credencial per a tothom qui el te. La revocacio tambe ha de funcionar des del primer dia, cosa que a Community OpenVPN vol dir un fitxer CRL referenciat per crl-verify mes un proces que el regeneri.

Planifica l'alta abans del canvi, no despres. Certificats nous, un cami de revocacio provat i una manera documentada de desactivar una persona son requisits previs, no feina posterior. Si l'autenticacio multifactor venia de la integracio del producte antic, anomena el reemplacament explicitament, perque un connector que no esta instal·lat falla tancat en el pitjor moment possible.

Les rutes i la resolucio de noms segueixen qui escriu la configuracio

Les rutes, els parametres de DNS i el comportament de tunel complet son opcions empenyudes en tots dos productes, pero nomes un les calcula per tu. A Community OpenVPN escrius tu les directives push, decideixes si redirect-gateway pertany al servidor o al client, i confirmes que l'encaminament i el NAT existeixen a l'amfitrio. Una apretada de ma acabada no et diu res sobre l'encaminament, la traduccio d'adreces o les rutes que el client ha rebut realment.

El comportament per client necessita client-config-dir mes un fitxer amb el nom comu del certificat del client, i un parell de lloc a lloc necessita entrades iroute per als prefixos que hi ha darrere. Si t'equivoques en el nom, les opcions s'ignoren sense cap error. Prova amb un client no productiu al seu propi pool d'adreces, i despres llegeix l'adreca que li van assignar, les rutes que va rebre i els parametres del resolutor amb que va acabar.

Ordena el canvi perque el servei antic pugui tornar

Executa el nou oient en un port o una adreca diferents i mante el vell servint transit mentre demostres el reemplacament. Dos dimonis en un sol sol no son un pla de retroces.

Mou un grup alhora, amb els seus certificats, el seu pool i les seves rutes, i assaja el cami de tornada en lloc de descobrir-lo durant un incident. Un retroces que nomes funciona si primer s'atura el servei nou encara es un retroces, pero s'ha de provar mentre no hi ha res cremant.

Finalment, llista les funcions sense equivalent directe i decideix el desti de cadascuna per escrit: descarrega de perfil d'autoservei, indicadors de permis per usuari, la mateixa interficie administrativa, informes de connexions en directe. Substituir-les per un proces manual documentat es una resposta legitima. Deixar la fila en blanc no ho es.

La feina esta feta quan un usuari que mai no ha vist el portal antic pot donar-se d'alta, connectar-se, arribar a l'adreca interna prevista i ser revocat netament. Tot el que hi ha abans d'aquest punt es preparacio.