Los perfiles se trasladan; las listas de usuarios se quedan atrás. Un equipo que cambia entre Access Server y Community Edition se topa con ese hueco una hora después del cambio, cuando su primer cliente se autentica y luego no tiene política de grupo, ni ruta por usuario, ni restablecimiento de contraseña de autoservicio. Ambos productos hablan el mismo protocolo y aceptan el mismo cliente, y por eso mismo el hueco pasa inadvertido durante la planificación. Lo que en realidad elige es la capa de gestión y las personas que la poseen.

Trate la decisión como una cuestión de inventario y no como una tabla de funciones. Pregunte quién crea usuarios, quién revoca certificados y quién contesta la llamada a las 02:00.

Por qué el archivo .ovpn no lleva la configuración

Un perfil .ovpn describe la relación de un cliente con un servidor: el host remoto, el protocolo, la CA, un certificado y una clave de cliente, y cualquier material tls-crypt en línea. Deje ese archivo en una instalación nueva y el cliente igualmente completa el saludo, así que la migración parece terminada. Nada en él enumera los usuarios, sus grupos, sus rutas estáticas ni la política que decidía quién podía conectarse. Esos registros viven en el almacenamiento propio del servidor, y los dos productos los guardan con formas distintas.

En Community Edition los equivalentes son archivos que usted mantiene: entradas client-config-dir con opciones por cliente como ifconfig-push e iroute, una CRL para las revocaciones y la clave tls-crypt. Access Server guarda los mismos conceptos en su propia base de datos y los expone mediante una consola web y la herramienta de línea de comandos sacli. Los conceptos se corresponden uno a uno; los artefactos no se mueven en absoluto.

Los perfiles también introducen de tapadillo comportamientos que nadie nota hasta que cambian. Un cliente con redirect-gateway def1 envía toda la navegación por el servidor; muévalo a una instalación sin esa línea y la queja será que se ha roto internet. Un desajuste de CA o una configuración incorrecta de remote-cert-tls falla ruidosamente, que es el buen resultado. Una clave tls-crypt ausente falla como un tiempo de espera silencioso, que no lo es.

Qué posee la capa de gestión

Cuente lo que no es protocolo: creación de cuentas, restablecimiento de contraseñas, asignación de grupos, inscripción en MFA, derechos de conexión y el rastro de auditoría que responde quién se conectó y cuándo. Community Edition no ofrece nada de eso directamente. Usted elige un backend de autenticación, conecta PAM, LDAP o RADIUS mediante un complemento o auth-user-pass-verify, y mantiene el resto por su cuenta. Access Server incluye un portal de usuario, una consola de administración e integraciones con proveedores de identidad habituales. Ninguna de las dos disposiciones es más segura por defecto, porque la política todavía tiene que escribirla alguien que conozca la red.

Los derechos de conexión son la diferencia operativa más marcada. Access Server se licencia por número de conexiones simultáneas y aplica ese número por software. En Community Edition, un límite global es una sola línea max-clients, mientras que cualquier cosa por usuario o por grupo implica más trabajo con client-config-dir y su propia aplicación. Un equipo sin ganas de ese mantenimiento compra exactamente eso cuando paga el producto comercial.

Licencias y soporte: la partida que nadie presupuesta

Community Edition es gratuito y de código abierto. Access Server es comercial, y su nivel gratuito ha cubierto históricamente un número reducido de conexiones simultáneas, con una licencia de pago por encima. Cualquier cifra citada en una respuesta antigua de un foro ya está desfasada, así que compruebe las condiciones actuales del proveedor antes de calcular el coste del proyecto. La comparación honesta suma las horas dedicadas a construir la gestión de usuarios, MFA y monitorización en el lado comunitario a la línea de licencia del lado comercial.

La propiedad del soporte sigue la misma división. Con Community Edition usted es la vía de escalado para cada cliente raro y cada actualización del núcleo. Con Access Server tiene un proveedor al que llamar, y hereda su ritmo de versiones, encaje o no en su ventana de cambios.

Comprobaciones que hacer antes del cambio

Inventaríe lo que el servidor en marcha guarda realmente antes del cambio en cualquier dirección. En el lado de Access Server, exporte la lista de usuarios y las asignaciones de grupo y anote qué cuentas dependen de MFA. En el lado de Community Edition, enumere los certificados emitidos, la CRL y cada archivo bajo client-config-dir. Compare las dos listas línea por línea, porque la diferencia entre ellas es el trabajo de migración.

Pruebe clientes representativos mientras el servicio antiguo sigue en marcha. openvpn --config client.ovpn --verb 4 en primer plano imprime el saludo, las rutas enviadas y las opciones de DNS, y openssl x509 -in client.crt -noout -subject -enddate muestra qué certificado presenta realmente el cliente. Un cliente que se conecta pero no llega a un host interno tiene un hueco de ruta o de iroute, no un fallo de autenticación.

Mantenga vivo el camino de recuperación antiguo hasta que el sustituto supere una prueba de acceso denegado además de una exitosa. Escriba el mapa final en una sola página: cada requisito, el artefacto que lo satisface hoy y el artefacto que lo satisfará después.

Artículos relacionados