Mover um perfil VPN do NetworkManager para outro computador

Duas máquinas podem mostrar o mesmo nome de VPN no menu e não ter mais nada em comum. A página de configurações é a parte que viaja pior, porque o conteúdo real do perfil está espalhado por um ficheiro de chaves, um porta-chaves, um plugin e um punhado de caminhos absolutos de ficheiros. Três perguntas decidem se deve exportar, copiar ou voltar a inscrever-se. Faça-as antes de copiar seja o que for.

Comece pelo perfil que realmente funciona

Liste as ligações e leia o UUID em vez do nome. nmcli connection show mostra ambos, e o UUID é o único campo que distingue a entrada funcional de uma importação mais antiga com um rótulo idêntico. Mude o nome ou elimine a duplicação obsoleta na máquina de origem antes de começar, para que o que copia não seja ambíguo. Depois registe o plugin e o tipo de ligação, porque esses dois determinam o que a exportação significa sequer. Um perfil que não consegue identificar com precisão é um que não deve migrar.

Este passo custa um minuto. Evita a falha mais comum, que é mover o perfil errado e depois depurar o destino.

Exportar ou copiar o ficheiro de chaves?

O NetworkManager pode exportar alguns perfis VPN para um ficheiro quando o plugin instalado implementa a exportação, e para OpenVPN o resultado assemelha-se a uma configuração autónoma. Copiar o ficheiro de chaves nativo é o outro caminho: preserva todas as configurações, mas espera o mesmo plugin e um proprietário permitido no destino. Nenhum é universalmente melhor, e nenhum é uma cópia de segurança. Escolha perguntando o que tem de permanecer idêntico.

A exportação serve para uma mudança para uma máquina que execute o mesmo plugin, sobretudo quando quer um único artefacto que possa inspecionar. O ficheiro de chaves serve para um restauro numa distribuição idêntica onde as permissões e os caminhos podem ser reproduzidos exatamente.

Para o que o perfil ainda aponta

Um perfil não é autossuficiente só porque foi exportado de forma limpa. A CA, o certificado de cliente, a chave privada e qualquer material TLS adicional são normalmente ficheiros separados referenciados por caminho, e esses caminhos existem na máquina que está a deixar. Enumere cada ficheiro referenciado antes de transferir seja o que for.

Depois decida se a mesma credencial deve ser usada de todo. Um ficheiro com o mesmo nome noutra máquina não é a mesma identidade, e algumas implementações esperam antes uma nova inscrição.

Os segredos não estão no ficheiro

As palavras-passe e as frases-passe podem viver no ficheiro de chaves, num porta-chaves do utilizador ou em lugar nenhum porque o utilizador é questionado todas as vezes. Apenas a primeira dessas hipóteses viaja com uma cópia do ficheiro.

Verifique os indicadores de palavra-passe no perfil de origem antes de assumir que a mudança não exigirá atenção. Um perfil configurado para perguntar, ou para guardar o segredo num agente de sessão, chega à nova máquina sem credencial e com uma tentativa de ligação que falha sem explicar porquê. Reproduza aí o fluxo de segredos aprovado em vez de exportar uma palavra-passe em texto simples para um ficheiro para facilitar a mudança. Esse atalho transforma uma migração numa divulgação.

Retire corretamente a cópia antiga

Aceite a nova configuração utilizando a aplicação prevista através dela, e mantenha o caminho antigo disponível até então. Importe, releia o endpoint, a autenticação, as rotas e o DNS, depois ligue-se e confirme o recurso privado. Uma importação que produz um ícone verde não é uma aceitação.

Eliminar um perfil local não revoga nada. O certificado e as credenciais permanecem válidos até o operador os retirar, pelo que a retirada é um pedido separado a quem os emitiu. Remova os ficheiros antigos, remova a entrada do porta-chaves e registe que identidade foi retirada e quando. Se a máquina antiga for entregue, esse registo importa mais do que a eliminação.