De Access Server a OpenVPN Community: o que hai que reconstruír

Access Server e Community OpenVPN falan o mesmo protocolo e case nada máis do mesmo xeito. O handshake, a negociación de cifrados e o plano de datos do túnel son compatibles, así que un cliente adoita conectarse a calquera dos dous sen editar o seu perfil. A diferenza está en quen posúe a configuración: un produto trae unha capa de xestión que escribe e aplica a política, mentres que o outro entrega un ficheiro de configuración e un conxunto de hooks e espera que decidas ti.

Esa distinción é o plan de migración. Todo o que o produto antigo decidía por ti ten que converterse nunha decisión explícita nalgún punto do novo despregamento.

Onde deixan de ser intercambiables os dous despregamentos

En Access Server, a interface web de administración posúe os usuarios, os grupos, os permisos por usuario, a emisión de certificados e o paquete de perfil que descarga unha persoa. O daemon que está debaixo configúrao esa capa, así que o servizo en execución é o produto dun estado almacenado que raramente editas a man. En Community OpenVPN, o ficheiro de configuración é o estado: nomea o listener, a autoridade de certificación, o hook de autenticación e cada opción empuxada, e nada o reescribe por ti. A mesma maquinaria TLS queda así baixo dous modelos de propiedade moi distintos.

Unha mapeado breve fai concreta a fenda. Os usuarios e os grupos só existen na base de datos antiga ata que os recreas. Os paquetes de perfil pasan a ser un ficheiro de configuración máis certificados que distribúes ti mesmo. Os permisos por usuario pasan a ser directivas dentro de client-config-dir. A interface de administración pasa a ser o proceso que elixas para emitir certificados e editar ficheiros.

Escribe ese mapeado antes de tocar un servidor. Cada fila que non poidas encher é unha función que estás a punto de perder, e perdela en silencio é a forma en que unha migración se converte nunha caída dúas semanas despois.

A identidade non se transfire cos ficheiros de certificado

Os certificados da autoridade antiga poden analizarse correctamente no servizo novo e aínda así ser a identidade equivocada, porque o produto vello emparellábaos cun estado de conta que o novo non pode ver. Decide primeiro se o novo despregamento autentica só con certificado, cun plugin que chega a PAM ou RADIUS, ou cunha combinación, e despois comproba que cada opción conserva as propiedades que necesitas. Un certificado compartido sen identidade por usuario é unha soa credencial para todos os que o teñan. A revogación tamén ten que funcionar desde o primeiro día, o que en Community OpenVPN significa un ficheiro CRL referenciado por crl-verify máis un proceso que o rexenere.

Planifica a inscrición antes do corte, non despois. Certificados novos, unha ruta de revogación probada e unha forma documentada de desactivar a unha persoa son requisitos previos, non traballo de seguimento. Se a autenticación multifactor viña da integración do produto antigo, nomea o substituto de forma explícita, porque un plugin que non está instalado falla pechado no peor momento posible.

O encamiñamento e a resolución de nomes seguen a quen escribe a configuración

As rutas, os axustes de DNS e o comportamento de túnel completo son opcións empuxadas nos dous produtos, pero só un as calcula por ti. En Community OpenVPN escribes as directivas push ti mesmo, decides se redirect-gateway vai no servidor ou no cliente e confirmas que o reenvío e o NAT existen no host. Un handshake rematado non che di nada sobre o reenvío, a tradución de enderezos nin as rutas que o cliente recibiu realmente.

O comportamento por cliente necesita client-config-dir máis un ficheiro nomeado segundo o common name do certificado do cliente, e un par sitio a sitio necesita entradas iroute para os prefixos que quedan detrás. Se o nome está mal, as opcións ignóranse sen ningún erro. Proba cun cliente que non sexa de produción na súa propia piscina de enderezos e despois le o enderezo que se lle asignou, as rutas que recibiu e os axustes de resolver cos que rematou.

Ordena o corte para que o servizo antigo poida volver

Executa o novo listener noutro porto ou noutro enderezo e mantén o antigo servindo tráfico mentres demostras o substituto. Dous daemons nun mesmo socket non son un plan de reversión.

Move un grupo por vez, cos seus propios certificados, a súa propia piscina e as súas propias rutas, e ensaia o camiño de volta en lugar de descubrilo durante un incidente. Unha reversión que só funciona se primeiro se detén o servizo novo segue sendo unha reversión, pero hai que probala cando non hai nada en chamas.

Por último, enumera as funcións sen equivalente directo e decide o destino de cada unha por escrito: a descarga de perfil de autoservizo, os indicadores de permiso por usuario, a propia interface administrativa, os informes de conexión en vivo. Substituílas por un proceso manual documentado é unha resposta lexítima. Deixar a fila en branco non o é.

O traballo está feito cando unha persoa que nunca viu o portal antigo pode inscribirse, conectarse, alcanzar o enderezo interno previsto e ser revogada sen problemas. Todo o anterior a ese punto é preparación.