Do Access Server ao Community OpenVPN: o que precisa ser reconstruído

Access Server e Community OpenVPN falam o mesmo protocolo e quase nada mais da mesma forma. O handshake, a negociação de cifras e o plano de dados do túnel são compatíveis, então um cliente frequentemente se conecta a qualquer um dos dois sem editar o perfil. A diferença é quem é dono da configuração: um produto traz uma camada de gestão que escreve e aplica a política, o outro entrega um arquivo de configuração e um conjunto de hooks e espera que você decida.

Essa distinção é o plano de migração. Tudo o que o produto antigo decidia por você precisa se tornar uma decisão explícita em algum ponto da nova implantação.

Onde as duas implantações deixam de ser intercambiáveis

No Access Server, a interface web de administração é dona dos usuários, dos grupos, das permissões por usuário, da emissão de certificados e do pacote de perfil que alguém baixa. O daemon por baixo é configurado por essa camada, então o serviço em execução é o produto de um estado armazenado que raramente você edita à mão. No Community OpenVPN, o arquivo de configuração é o estado: ele nomeia o listener, a autoridade certificadora, o hook de autenticação e cada opção enviada, e nada o reescreve por você. A mesma maquinaria TLS fica, portanto, sob dois modelos de propriedade muito diferentes.

Um mapeamento curto torna a lacuna concreta. Usuários e grupos existem apenas no banco antigo até você recriá-los. Pacotes de perfil se tornam um arquivo de configuração mais certificados que você distribui. Permissões por usuário se tornam diretivas em client-config-dir. A interface administrativa se torna o processo que você escolher para emitir certificados e editar arquivos.

Escreva esse mapeamento antes de tocar em um servidor. Cada linha que você não consegue preencher é um recurso que está prestes a perder, e perdê-lo em silêncio é como uma migração vira um incidente duas semanas depois.

A identidade não é transferida com os arquivos de certificado

Certificados da autoridade antiga podem ser analisados corretamente no novo serviço e ainda assim ser a identidade errada, porque o produto antigo os emparelhava com um estado de conta que o novo não vê. Decida primeiro se a nova implantação autentica apenas com certificado, com um plugin que alcança PAM ou RADIUS, ou com uma combinação, e depois verifique se cada opção preserva as propriedades de que você precisa. Um certificado compartilhado sem identidade por usuário é uma única credencial para todos que o possuem. A revogação também precisa funcionar desde o primeiro dia, o que no Community OpenVPN significa um arquivo CRL referenciado por crl-verify mais um processo que o regenera.

Planeje a inscrição antes da virada, não depois. Certificados novos, um caminho de revogação testado e uma forma documentada de desativar uma pessoa são pré-requisitos, não trabalho de acompanhamento. Se a autenticação multifator veio da integração do produto antigo, nomeie o substituto explicitamente, porque um plugin não instalado falha fechado no pior momento possível.

O roteamento e a resolução de nomes seguem quem escreve a configuração

Rotas, ajustes de DNS e o comportamento de túnel completo são opções enviadas nos dois produtos, mas apenas um as calcula por você. No Community OpenVPN você escreve as diretivas push, decide se redirect-gateway pertence ao servidor ou ao cliente e confirma que encaminhamento e NAT existem no host. Um handshake concluído não diz nada sobre encaminhamento, tradução de endereços ou as rotas que o cliente realmente recebeu.

O comportamento por cliente exige client-config-dir mais um arquivo nomeado pelo common name do certificado do cliente, e um par site a site exige entradas iroute para os prefixos por trás. Se o nome estiver errado, as opções são ignoradas sem erro. Teste com um cliente que não seja de produção na própria faixa de endereços e depois leia o endereço atribuído, as rotas recebidas e os ajustes de resolver com que ele terminou.

Ordene a virada para que o serviço antigo possa voltar

Rode o novo listener em outra porta ou endereço e mantenha o antigo atendendo tráfego enquanto você prova o substituto. Dois daemons no mesmo socket não são um plano de reversão.

Mova um grupo de cada vez, com os próprios certificados, a própria faixa e as próprias rotas, e ensaie o caminho de volta em vez de descobri-lo durante um incidente. Uma reversão que só funciona se o novo serviço for parado antes continua sendo reversão, mas precisa ser testada quando nada está queimando.

Por fim, liste os recursos sem equivalente direto e decida o destino de cada um por escrito: download de perfil em autoatendimento, sinalizadores de permissão por usuário, a própria interface administrativa, relatórios de conexões ao vivo. Substituí-los por um processo manual documentado é uma resposta legítima. Deixar a linha em branco não é.

O trabalho termina quando alguém que nunca viu o portal antigo consegue se inscrever, conectar, alcançar o endereço interno pretendido e ser revogado de forma limpa. Tudo antes disso é preparação.