¿Cree que renombrar el servidor Pritunl cambia su punto final?

Renombrar un servidor Pritunl cambia una etiqueta en la consola. No cambia la dirección a la que se conectan los perfiles de los clientes ni crea un registro DNS. El valor que importa es la Dirección pública del host, y acepta un nombre con la misma facilidad que una dirección.

El nombre al que se conectan los clientes vive en un solo campo del host

Pritunl expone el punto final mediante el ajuste Dirección pública del host, que acepta una dirección IP pública o un nombre DNS. Ponga vpn.example.net ahí y los perfiles generados y la sincronización autenticada entregarán ese nombre a los clientes. El registro ya debe existir y resolverse hacia el receptor que acepta el transporte VPN; el campo anuncia un destino, no lo publica. El nombre visible de un objeto de servidor es metadato administrativo y nunca llega al intento de conexión del cliente.

Así que el primer paso no es renombrar nada. Abra los ajustes del host, cambie la Dirección pública y guarde desde la interfaz compatible.

Tres campos que parecen iguales y no lo son

La Dirección local sirve para la replicación y el enrutamiento entre hosts de Pritunl. La Dirección de enlace describe cómo se alcanzan entre sí los servidores enlazados. Ninguna de las dos es la dirección a la que se conecta un cliente, y copiar el nombre público en ellas rompe la topología que describen. La Dirección IPv6 pública es un campo aparte con su propio registro y ruta; un registro A para IPv4 no establece accesibilidad por IPv6.

Un nombre DNS tampoco lleva ninguna asignación de puertos ni ningún receptor. Si el servicio escucha en 1194 UDP, el nombre sigue resolviéndose a un host que debe aceptar 1194 UDP. Un proxy inverso HTTP en el puerto 443 que sirve la consola web no es el punto final del transporte VPN, aunque ambos compartan el mismo nombre.

El enrutamiento por dominios dentro del túnel es otra capa distinta. Nombrar el punto final exterior no dice nada sobre qué destinos privados puede alcanzar un cliente.

Envíe el nombre nuevo a los clientes que ya existen

Cambiar el campo no reescribe los perfiles que ya salieron del servidor. La sincronización de configuración autenticada de Pritunl puede entregar los cambios de dirección y puerto del host a los clientes compatibles, y el cliente CLI documentado sincroniza antes de conectarse o reconectarse. Un perfil importado en NetworkManager o en un cliente OpenVPN independiente no tiene ese canal y necesita un reemplazo aprobado. Las sesiones existentes no demuestran nada, porque se establecieron con el valor antiguo.

Cuando la consola web está detrás de un balanceador de carga, Pritunl documenta un ajuste aparte Dirección de sincronización para la ruta de sincronización. No reutilice el nombre de host de la consola para el receptor VPN solo porque ambos son Pritunl.

Entregue el cambio en este orden: guarde el ajuste del host, exporte o sincronice el perfil actual, sustituya la copia del cliente y luego reconecte. Anote qué clientes gestiona la sincronización y cuáles tienen archivos importados, porque el segundo grupo no seguirá automáticamente. Una lista de propiedad de los clientes es más útil aquí que otro registro DNS.

Acepte el cambio con una conexión real

La resolución es la prueba más débil posible. dig +short vpn.example.net que devuelve una dirección solo demuestra que existe un registro.

La prueba de aceptación es una conexión autenticada nueva desde un cliente con el perfil nuevo, seguida de una petición a un recurso privado que debería ser alcanzable por el túnel. Revise en el registro del cliente el punto final que realmente usó, no el que pretendía. Mantenga una ruta de gestión que no dependa de que el nombre se cambie correctamente, para que un error no pueda dejarlo fuera de la consola.

Más adelante, cuando la dirección pública se mueva, actualice el registro y planifique el almacenamiento en caché de los clientes y el comportamiento de reconexión. Un nombre de host desacopla a los clientes de una dirección numérica; no mueve un socket activo ni hace que un receptor inalcanzable responda.