Pensa que renomear o servidor Pritunl cambia o seu punto final?

Renomear un servidor Pritunl cambia unha etiqueta na consola. Non cambia a dirección á que se conectan os perfís dos clientes nin crea un rexistro DNS. O valor que importa é a Dirección pública do host, e acepta un nome coa mesma facilidade ca unha dirección.

O nome ao que se conectan os clientes vive nun só campo do host

Pritunl expón o punto final mediante o axuste Dirección pública do host, que acepta unha dirección IP pública ou un nome DNS. Poña vpn.example.net alí e os perfís xerados e a sincronización autenticada entregarán ese nome aos clientes. O rexistro xa debe existir e resolverse cara ao receptor que acepta o transporte VPN; o campo anuncia un destino, non o publica. O nome visible dun obxecto de servidor é metadato administrativo e nunca chega ao intento de conexión do cliente.

Así que o primeiro paso non é renomear nada. Abra os axustes do host, cambie a Dirección pública e garde desde a interface compatible.

Tres campos que parecen iguais e non o son

A Dirección local serve para a replicación e o enrutamento entre hosts de Pritunl. A Dirección de enlace describe como se alcanzan entre si os servidores vinculados. Ningunha das dúas é a dirección á que se conecta un cliente, e copiar o nome público nelas rompe a topoloxía que describen. A Dirección IPv6 pública é un campo aparte co seu propio rexistro e ruta; un rexistro A para IPv4 non establece accesibilidade por IPv6.

Un nome DNS tampouco leva ningunha asignación de portos nin ningún receptor. Se o servizo escoita en 1194 UDP, o nome segue resolvéndose a un host que debe aceptar 1194 UDP. Un proxy inverso HTTP no porto 443 que serve a consola web non é o punto final do transporte VPN, aínda que ambos compartan o mesmo nome.

O enrutamento por dominios dentro do túnel é outra capa distinta. Nomear o punto final exterior non di nada sobre que destinos privados pode alcanzar un cliente.

Envíe o nome novo aos clientes que xa existen

Cambiar o campo non reescribe os perfís que xa saíron do servidor. A sincronización de configuración autenticada de Pritunl pode entregar os cambios de dirección e porto do host aos clientes compatibles, e o cliente CLI documentado sincroniza antes de conectarse ou reconectarse. Un perfil importado en NetworkManager ou nun cliente OpenVPN independente non ten esa canle e necesita unha substitución aprobada. As sesións existentes non demostran nada, porque se estableceron co valor antigo.

Cando a consola web está detrás dun balanceador de carga, Pritunl documenta un axuste aparte Dirección de sincronización para a ruta de sincronización. Non reutilice o nome de host da consola para o receptor VPN só porque ambos son Pritunl.

Entregue o cambio nesta orde: garde o axuste do host, exporte ou sincronice o perfil actual, substitúa a copia do cliente e despois reconecte. Anote que clientes xestiona a sincronización e cales teñen ficheiros importados, porque o segundo grupo non seguirá automaticamente. Unha lista de propiedade dos clientes é máis útil aquí ca outro rexistro DNS.

Acepte o cambio cunha conexión real

A resolución é a proba máis feble posible. dig +short vpn.example.net que devolve unha dirección só demostra que existe un rexistro.

A proba de aceptación é unha conexión autenticada nova desde un cliente co perfil novo, seguida dunha petición a un recurso privado que debería ser alcanzable polo túnel. Revise no rexistro do cliente o punto final que realmente usou, non o que pretendía. Manteña unha ruta de xestión que non dependa de que o nome se cambie correctamente, para que un erro non o poida deixar fóra da consola.

Máis adiante, cando a dirección pública se mova, actualice o rexistro e planifique a caché dos clientes e o comportamento de reconexión. Un nome de host desacopla os clientes dunha dirección numérica; non move un socket activo nin fai que un receptor inalcanzable responda.