De Access Server a OpenVPN Community: qué hay que reconstruir

Access Server y OpenVPN Community hablan el mismo protocolo y casi nada más de la misma forma. El handshake, la negociación de cifrados y el plano de datos del túnel son compatibles, así que un cliente suele conectarse a cualquiera de los dos sin editar su perfil. La diferencia está en quién es dueño de la configuración: un producto trae una capa de gestión que escribe y aplica la política, mientras que el otro te entrega un archivo de configuración y un juego de hooks y espera que decidas tú.

Esa distinción es el plan de migración. Todo lo que el producto antiguo decidía por ti tiene que convertirse en una decisión explícita en algún punto del nuevo despliegue.

Dónde dejan de ser intercambiables los dos despliegues

En Access Server, la interfaz web de administración es dueña de los usuarios, los grupos, los permisos por usuario, la emisión de certificados y el paquete de perfil que descarga una persona. El daemon que está debajo lo configura esa capa, así que el servicio en ejecución es el producto de un estado almacenado que rara vez editas a mano. En OpenVPN Community, el archivo de configuración es el estado: nombra el listener, la autoridad de certificación, el hook de autenticación y cada opción empujada, y nada lo reescribe por ti. La misma maquinaria TLS queda así bajo dos modelos de propiedad muy distintos.

Un mapeo breve vuelve concreta la brecha. Los usuarios y los grupos solo existen en la base de datos antigua hasta que los recreas. Los paquetes de perfil pasan a ser un archivo de configuración más certificados que distribuyes tú mismo. Los permisos por usuario pasan a ser directivas dentro de client-config-dir. La interfaz de administración pasa a ser el proceso que elijas para emitir certificados y editar archivos.

Escribe ese mapeo antes de tocar un servidor. Cada fila que no puedas completar es una función que estás a punto de perder, y perderla en silencio es la forma en que una migración se convierte en una caída dos semanas después.

La identidad no se transfiere con los archivos de certificado

Los certificados de la autoridad antigua pueden parsearse correctamente en el servicio nuevo y aun así ser la identidad equivocada, porque el producto viejo los emparejaba con un estado de cuenta que el nuevo no puede ver. Decide primero si el nuevo despliegue autentica solo con certificado, con un plugin que llega a PAM o RADIUS, o con alguna combinación, y luego comprueba que cada opción conserva las propiedades que necesitas. Un certificado compartido sin identidad por usuario es una sola credencial para todos los que lo tengan. La revocación también tiene que funcionar desde el primer día, lo que en OpenVPN Community significa un archivo CRL referenciado por crl-verify más un proceso que lo regenere.

Planifica la inscripción antes del corte, no después. Certificados nuevos, una ruta de revocación probada y una forma documentada de deshabilitar a una persona son requisitos previos, no trabajo de seguimiento. Si la autenticación multifactor venía de la integración del producto antiguo, nombra el reemplazo de forma explícita, porque un plugin que no está instalado falla cerrado en el peor momento posible.

El enrutamiento y la resolución de nombres siguen a quien escribe la configuración

Las rutas, los ajustes de DNS y el comportamiento de túnel completo son opciones empujadas en ambos productos, pero solo uno las calcula por ti. En OpenVPN Community escribes las directivas push tú mismo, decides si redirect-gateway va en el servidor o en el cliente y confirmas que el reenvío y el NAT existen en el host. Un handshake terminado no te dice nada sobre el reenvío, la traducción de direcciones ni las rutas que el cliente recibió realmente.

El comportamiento por cliente necesita client-config-dir más un archivo nombrado según el common name del certificado del cliente, y un par sitio a sitio necesita entradas iroute para los prefijos que quedan detrás. Si el nombre está mal, las opciones se ignoran sin ningún error. Prueba con un cliente que no sea de producción en su propia piscina de direcciones y luego lee la dirección que se le asignó, las rutas que recibió y los ajustes de resolver con los que terminó.

Ordena el corte para que el servicio antiguo pueda volver

Ejecuta el nuevo listener en otro puerto o en otra dirección y mantén el antiguo sirviendo tráfico mientras demuestras el reemplazo. Dos daemons en un mismo socket no son un plan de reversión.

Mueve un grupo por vez, con sus propios certificados, su propia piscina y sus propias rutas, y ensaya el camino de vuelta en lugar de descubrirlo durante un incidente. Una reversión que solo funciona si primero se detiene el servicio nuevo sigue siendo una reversión, pero hay que probarla cuando no hay nada en llamas.

Por último, enumera las funciones sin equivalente directo y decide el destino de cada una por escrito: la descarga de perfil de autoservicio, los indicadores de permiso por usuario, la propia interfaz administrativa, los informes de conexión en vivo. Sustituirlas por un proceso manual documentado es una respuesta legítima. Dejar la fila en blanco no lo es.

El trabajo está hecho cuando una persona que nunca vio el portal antiguo puede inscribirse, conectarse, alcanzar la dirección interna prevista y ser revocada sin problemas. Todo lo anterior a ese punto es preparación.