OpenVPN Access Server fronte a Community: que se migra realmente

Os perfís trasládanse; as listas de usuarios quedan atrás. Un equipo que cambia entre Access Server e Community Edition atopa ese oco unha hora despois do cambio, cando o seu primeiro cliente se autentica e logo non ten política de grupo, nin ruta por usuario, nin restablecemento de contrasinal de autoservizo. Ambos os produtos falan o mesmo protocolo e aceptan o mesmo cliente, e por iso mesmo o oco pasa desapercibido durante a planificación. O que en realidade elixe é a capa de xestión e as persoas que a posúen.

Trate a decisión como unha cuestión de inventario e non como unha táboa de funcións. Pregunte quen crea usuarios, quen revoga certificados e quen contesta a chamada ás 02:00.

Por que o ficheiro .ovpn non leva a configuración

Un perfil .ovpn describe a relación dun cliente cun servidor: o host remoto, o protocolo, a CA, un certificado e unha chave de cliente, e calquera material tls-crypt en liña. Deixe ese ficheiro nunha instalación nova e o cliente igualmente completa o salto de mans, así que a migración parece rematada. Nada nel enumera os usuarios, os seus grupos, as súas rutas estáticas nin a política que decidía quen podía conectarse. Eses rexistros viven no almacenamento propio do servidor, e os dous produtos gárdaos con formas distintas.

En Community Edition os equivalentes son ficheiros que vostede mantén: entradas client-config-dir con opcións por cliente como ifconfig-push e iroute, unha CRL para as revogacións e a chave tls-crypt. Access Server garda os mesmos conceptos na súa propia base de datos e expónos mediante unha consola web e a ferramenta de liña de ordes sacli. Os conceptos correspóndense un a un; os artefactos non se moven en absoluto.

Os perfís tamén introducen ás agachadas comportamentos que ninguén nota ata que cambian. Un cliente con redirect-gateway def1 envía toda a navegación polo servidor; móvao a unha instalación sen esa liña e a queixa será que se rompeu internet. Un desaxuste de CA ou unha configuración incorrecta de remote-cert-tls falla ruidosamente, que é o bo resultado. Unha chave tls-crypt ausente falla como un tempo de espera silencioso, que non o é.

Que posúe a capa de xestión

Conte o que non é protocolo: creación de contas, restablecemento de contrasinais, asignación de grupos, inscrición en MFA, dereitos de conexión e o rexistro de auditoría que responde quen se conectou e cando. Community Edition non ofrece nada diso directamente. Vostede escolle un backend de autenticación, conecta PAM, LDAP ou RADIUS mediante un complemento ou auth-user-pass-verify, e mantén o resto pola súa conta. Access Server inclúe un portal de usuario, unha consola de administración e integracións con provedores de identidade habituais. Ningunha das dúas disposicións é máis segura por defecto, porque a política aínda ten que escribila alguén que coñeza a rede.

Os dereitos de conexión son a diferenza operativa máis marcada. Access Server licénciase por número de conexións simultáneas e aplica ese número por software. En Community Edition, un límite global é unha soa liña max-clients, mentres que calquera cousa por usuario ou por grupo implica máis traballo con client-config-dir e a súa propia aplicación. Un equipo sen ganas dese mantemento compra exactamente iso cando paga o produto comercial.

Licenzas e soporte: a partida que ninguén orza

Community Edition é gratuíto e de código aberto. Access Server é comercial, e o seu nivel gratuíto cubriu historicamente un número reducido de conexións simultáneas, cunha licenza de pago por riba. Calquera cifra citada nunha resposta antiga dun foro xa está desfasada, así que comprobe as condicións actuais do provedor antes de calcular o custo do proxecto. A comparación honesta suma as horas dedicadas a construír a xestión de usuarios, MFA e monitorización no lado comunitario á liña de licenza no lado comercial.

A propiedade do soporte segue a mesma división. Con Community Edition vostede é a vía de escalado para cada cliente estraño e cada actualización do núcleo. Con Access Server ten un provedor ao que chamar, e herda o seu ritmo de versións, encaixe ou non na súa xanela de cambios.

Comprobacións que facer antes do cambio

Inventaríe o que o servidor en marcha garda realmente antes do cambio en calquera dirección. No lado de Access Server, exporte a lista de usuarios e as asignacións de grupo e anote que contas dependen de MFA. No lado de Community Edition, enumere os certificados emitidos, a CRL e cada ficheiro baixo client-config-dir. Compare as dúas listas liña por liña, porque a diferenza entre elas é o traballo de migración.

Probe clientes representativos mentres o servizo antigo segue en marcha. openvpn --config client.ovpn --verb 4 en primeiro plano imprime o salto de mans, as rutas enviadas e as opcións de DNS, e openssl x509 -in client.crt -noout -subject -enddate mostra que certificado presenta realmente o cliente. Un cliente que se conecta pero non chega a un host interno ten un oco de ruta ou de iroute, non un fallo de autenticación.

Manteña vivo o camiño de recuperación antigo ata que o substituto supere unha proba de acceso denegado ademais dunha exitosa. Escriba o mapa final nunha soa páxina: cada requisito, o artefacto que o satisface hoxe e o artefacto que o satisfará despois.