Acha que renomear o servidor Pritunl altera o endpoint dele?

Renomear um servidor Pritunl altera um rótulo no console. Não altera o endereço ao qual os perfis de clientes se conectam, e não cria um registro DNS. O valor que importa é o Endereço Público do host, e ele aceita um nome com a mesma facilidade que um endereço.

O nome ao qual os clientes se conectam vive em um único campo do host

O Pritunl expõe o endpoint pela configuração Endereço Público do host, que aceita um endereço IP público ou um nome DNS. Coloque vpn.example.net ali, e os perfis gerados e a sincronização autenticada entregarão esse nome aos clientes. O registro já deve existir e resolver para o listener que aceita o transporte VPN; o campo anuncia um destino, não o publica. O nome de exibição de um objeto de servidor é metadado administrativo e nunca chega à tentativa de conexão do cliente.

Portanto, o primeiro passo não é renomear nada. Abra as configurações do host, altere o Endereço Público e salve pela interface suportada.

Três campos que parecem iguais e não são

O Endereço Local serve à replicação e ao roteamento entre hosts Pritunl. O Endereço de Link descreve como servidores vinculados se alcançam. Nenhum dos dois é o endereço ao qual um cliente se conecta, e copiar o nome público para eles quebra a topologia que descrevem. O Endereço IPv6 Público é um campo separado com seu próprio registro e caminho; um registro A para IPv4 não estabelece alcance IPv6.

Um nome DNS também não carrega mapeamento de portas nem listener. Se o serviço escuta em 1194 UDP, o nome ainda resolve para um host que deve aceitar 1194 UDP. Um proxy reverso HTTP na porta 443 que atende ao console web não é o endpoint do transporte VPN, mesmo quando ambos compartilham o mesmo nome.

O roteamento baseado em domínios dentro do túnel é ainda outra camada. Nomear o endpoint externo não diz nada sobre quais destinos privados um cliente pode alcançar.

Envie o novo nome aos clientes que existem

Alterar o campo não reescreve perfis que já deixaram o servidor. A sincronização de configuração autenticada do Pritunl pode entregar mudanças de endereço e porta do host a clientes compatíveis, e o cliente CLI documentado sincroniza antes de conectar ou reconectar. Um perfil importado no NetworkManager ou em um cliente OpenVPN autônomo não tem esse canal e precisa de uma substituição aprovada. Sessões existentes não provam nada, porque foram estabelecidas com o valor antigo.

Quando o console web fica atrás de um balanceador de carga, o Pritunl documenta uma configuração separada Endereço de Sincronização para o caminho de sincronização. Não reutilize o nome de host do console para o listener VPN só porque ambos são Pritunl.

Entregue a mudança nesta ordem: salve a configuração do host, exporte ou sincronize o perfil atual, substitua a cópia do cliente e reconecte. Anote quais clientes são gerenciados pela sincronização e quais mantêm arquivos importados, porque o segundo grupo não seguirá automaticamente. Uma lista de propriedade dos clientes é mais útil aqui do que outro registro DNS.

Aceite a mudança com uma conexão real

A resolução é o teste mais fraco possível. dig +short vpn.example.net que retorna um endereço só prova que existe um registro.

O teste de aceitação é uma conexão autenticada nova de um cliente com o perfil novo, seguida de uma requisição a um recurso privado que deveria ser alcançável pelo túnel. Verifique no log do cliente o endpoint que ele realmente usou, não o que você pretendia. Mantenha um caminho de gestão que não dependa da alteração correta do nome, para que um erro não possa trancá-lo fora do console.

Mais tarde, quando o endereço público mudar, atualize o registro e planeje o cache dos clientes e o comportamento de reconexão. Um nome de host desacopla os clientes de um endereço numérico; ele não move um socket ativo nem faz um listener inalcançável responder.