Os perfis migram; as listas de usuários ficam para trás. Uma equipe que alterna entre Access Server e Community Edition encontra essa lacuna uma hora após a mudança, quando o primeiro cliente se autentica e então não tem política de grupo, nem rota por usuário, nem redefinição de senha por autosserviço. Os dois produtos falam o mesmo protocolo e aceitam o mesmo cliente, e é exatamente por isso que a lacuna fica invisível durante o planejamento. O que você realmente escolhe é a camada de gestão e as pessoas que a possuem.

Trate a decisão como uma questão de inventário, não como uma grade de recursos. Pergunte quem cria usuários, quem revoga certificados e quem atende a ligação às 02:00.

Por que o arquivo .ovpn não carrega a configuração

Um perfil .ovpn descreve a relação de um cliente com um servidor: o host remoto, o protocolo, a CA, um certificado e uma chave de cliente, e qualquer material tls-crypt embutido. Coloque esse arquivo em uma instalação nova e o cliente ainda completa o handshake, então a migração parece concluída. Nada nele lista os usuários, seus grupos, suas rotas estáticas ou a política que decidia quem podia se conectar. Esses registros vivem no armazenamento do próprio servidor, e os dois produtos os guardam em formas diferentes.

No Community Edition os equivalentes são arquivos que você mantém: entradas client-config-dir com opções por cliente, como ifconfig-push e iroute, uma CRL para revogações e a chave tls-crypt. O Access Server guarda os mesmos conceitos em seu próprio banco de dados e os expõe por meio de um console web e da ferramenta de linha de comando sacli. Os conceitos se correspondem um a um; os artefatos não se movem de forma alguma.

Os perfis também introduzem às escondidas comportamentos que ninguém nota até que mudem. Um cliente com redirect-gateway def1 envia toda a navegação pelo servidor; mova-o para uma instalação sem essa linha e a queixa será a de que a internet quebrou. Uma incompatibilidade de CA ou uma configuração errada de remote-cert-tls falha ruidosamente, o que é o bom resultado. Uma chave tls-crypt ausente falha como um tempo limite silencioso, o que não é.

O que a camada de gestão possui

Conte o que não é protocolo: criação de contas, redefinição de senhas, atribuição de grupos, inscrição em MFA, direitos de conexão e a trilha de auditoria que responde quem se conectou e quando. O Community Edition não oferece nada disso diretamente. Você escolhe um backend de autenticação, conecta PAM, LDAP ou RADIUS por meio de um plugin ou auth-user-pass-verify, e mantém o resto sozinho. O Access Server traz um portal de usuário, um console de administração e integrações com provedores de identidade comuns. Nenhuma das duas disposições é mais segura por padrão, porque a política ainda precisa ser escrita por alguém que conheça a rede.

Os direitos de conexão são a diferença operacional mais marcante. O Access Server é licenciado pelo número de conexões simultâneas e aplica esse número em software. No Community Edition, um limite global é uma única linha max-clients, enquanto qualquer coisa por usuário ou por grupo significa mais trabalho com client-config-dir e a sua própria aplicação. Uma equipe sem disposição para essa manutenção compra exatamente isso quando paga pelo produto comercial.

Licenciamento e suporte: a linha que ninguém orça

O Community Edition é gratuito e de código aberto. O Access Server é comercial, e seu nível gratuito cobriu historicamente um número pequeno de conexões simultâneas, com uma licença paga acima disso. Qualquer número citado em uma resposta antiga de fórum já está desatualizado, então verifique os termos atuais do fornecedor antes de calcular o custo do projeto. A comparação honesta soma as horas gastas construindo gestão de usuários, MFA e monitoramento no lado da comunidade à linha de licença no lado comercial.

A propriedade do suporte segue a mesma divisão. Com o Community Edition você é o caminho de escalonamento para cada cliente estranho e cada atualização de kernel. Com o Access Server você tem um fornecedor para chamar, e herda o ritmo de lançamentos dele, encaixe ou não na sua janela de mudanças.

Verificações antes da mudança

Inventarie o que o servidor em execução realmente guarda antes da mudança em qualquer direção. No lado do Access Server, exporte a lista de usuários e as atribuições de grupo e anote quais contas dependem de MFA. No lado do Community Edition, liste os certificados emitidos, a CRL e cada arquivo sob client-config-dir. Compare as duas listas linha por linha, porque a diferença entre elas é o trabalho de migração.

Teste clientes representativos enquanto o serviço antigo ainda está em execução. openvpn --config client.ovpn --verb 4 em primeiro plano imprime o handshake, as rotas enviadas e as opções de DNS, e openssl x509 -in client.crt -noout -subject -enddate mostra qual certificado o cliente realmente apresenta. Um cliente que se conecta mas não alcança um host interno tem uma lacuna de rota ou de iroute, não uma falha de autenticação.

Mantenha o caminho de recuperação antigo vivo até que o substituto passe por um teste de acesso negado além de um bem-sucedido. Escreva o mapa final em uma única página: cada requisito, o artefato que o atende hoje e o artefato que o atenderá depois.

Artigos relacionados