Pensez-vous que renommer le serveur Pritunl change son point de terminaison ?
Renommer un serveur Pritunl change une étiquette, pas le point de terminaison que les clients contactent. Définissez l’adresse publique de l’hôte, puis poussez le nom vers les profils déjà existants.
Renommer un serveur Pritunl change une étiquette dans la console. Cela ne change pas l’adresse que les profils clients contactent et cela ne crée pas d’enregistrement DNS. La valeur qui compte est l’adresse publique de l’hôte, et elle accepte un nom aussi volontiers qu’une adresse.
Le nom que les clients contactent vit dans un seul champ de l’hôte
Pritunl expose le point de terminaison via le réglage Adresse publique de l’hôte, qui accepte soit une adresse IP publique, soit un nom DNS. Placez vpn.example.net à cet endroit, et les profils générés ainsi que la synchronisation authentifiée transmettront ce nom aux clients. L’enregistrement doit déjà exister et se résoudre vers l’écouteur qui accepte le transport VPN ; le champ annonce une destination, il ne la publie pas. Le nom affiché d’un objet serveur est une métadonnée administrative et n’atteint jamais la tentative de connexion du client.
La première étape n’est donc pas de renommer quoi que ce soit. Ouvrez les réglages de l’hôte, modifiez l’adresse publique et enregistrez via l’interface prise en charge.
Trois champs qui se ressemblent et ne le sont pas
L’adresse locale sert à la réplication et au routage entre les hôtes Pritunl. L’adresse de liaison décrit comment les serveurs liés s’atteignent mutuellement. Aucune des deux n’est l’adresse que contacte un client, et y copier le nom public casse la topologie qu’elles décrivent. L’adresse IPv6 publique est un champ distinct avec son propre enregistrement et son propre chemin ; un enregistrement A pour IPv4 n’établit pas l’accessibilité IPv6.
Un nom DNS ne porte pas non plus de mappage de ports ni d’écouteur. Si le service écoute sur 1194 UDP, le nom se résout toujours vers un hôte qui doit accepter 1194 UDP. Un proxy inverse HTTP sur le port 443 qui sert la console web n’est pas le point de terminaison du transport VPN, même lorsque les deux partagent le même nom.
Le routage par domaine à l’intérieur du tunnel est encore une autre couche. Nommer le point de terminaison externe ne dit rien des destinations privées qu’un client peut atteindre.
Poussez le nouveau nom vers les clients qui existent
Changer le champ ne réécrit pas les profils qui ont déjà quitté le serveur. La synchronisation de configuration authentifiée de Pritunl peut livrer les changements d’adresse et de port de l’hôte aux clients compatibles, et le client CLI documenté se synchronise avant de se connecter ou de se reconnecter. Un profil importé dans NetworkManager ou dans un client OpenVPN autonome n’a pas un tel canal et nécessite un remplacement approuvé. Les sessions existantes ne prouvent rien, car elles ont été établies avec l’ancienne valeur.
Lorsque la console web se trouve derrière un répartiteur de charge, Pritunl documente un réglage distinct Adresse de synchronisation pour le chemin de synchronisation. Ne réutilisez pas le nom d’hôte de la console pour l’écouteur VPN simplement parce que les deux sont Pritunl.
Livrez le changement dans cet ordre : enregistrez le réglage de l’hôte, exportez ou synchronisez le profil actuel, remplacez la copie du client, puis reconnectez-vous. Notez quels clients sont gérés par la synchronisation et lesquels détiennent des fichiers importés, car le second groupe ne suivra pas automatiquement. Une liste de propriété des clients est ici plus utile qu’un autre enregistrement DNS.
Acceptez le changement avec une vraie connexion
La résolution est le test le plus faible possible. dig +short vpn.example.net qui renvoie une adresse ne prouve qu’une chose : un enregistrement existe.
Le test d’acceptation est une nouvelle connexion authentifiée depuis un client détenant le nouveau profil, suivie d’une requête vers une ressource privée qui devrait être joignable par le tunnel. Vérifiez dans le journal du client le point de terminaison qu’il a réellement utilisé, pas celui que vous aviez prévu. Conservez un chemin de gestion qui ne dépend pas du changement correct du nom, afin qu’une erreur ne puisse pas vous verrouiller hors de la console.
Plus tard, lorsque l’adresse publique bougera, mettez l’enregistrement à jour et prévoyez le cache des clients et le comportement de reconnexion. Un nom d’hôte découple les clients d’une adresse numérique ; il ne déplace pas une socket active et ne fait pas répondre un écouteur injoignable.