Creieu que canviar el nom del servidor Pritunl canvia el seu punt final?

Canviar el nom d’un servidor Pritunl canvia una etiqueta a la consola. No canvia l’adreça a la qual es connecten els perfils dels clients ni crea cap registre DNS. El valor que importa és l’adreça pública de l’amfitrió, i accepta un nom tan fàcilment com una adreça.

El nom al qual es connecten els clients viu en un sol camp de l’amfitrió

Pritunl exposa el punt final mitjançant el paràmetre Adreça pública de l’amfitrió, que accepta una adreça IP pública o un nom DNS. Poseu-hi vpn.example.net i els perfils generats i la sincronització autenticada lliuraran aquest nom als clients. El registre ha d’existir ja i resoldre’s cap al receptor que accepta el transport VPN; el camp anuncia una destinació, no la publica. El nom visible d’un objecte de servidor és metadada administrativa i mai arriba a l’intent de connexió del client.

Així, el primer pas no és canviar el nom de res. Obriu la configuració de l’amfitrió, canvieu l’adreça pública i deseu-ho des de la interfície compatible.

Tres camps que semblen iguals i no ho són

Adreça local serveix per a la replicació i l’encaminament entre amfitrions Pritunl. Adreça d’enllaç descriu com arriben els servidors enllaçats els uns als altres. Cap de les dues no és l’adreça a la qual es connecta un client, i copiar-hi el nom públic trenca la topologia que descriuen. Adreça IPv6 pública és un camp a part amb el seu propi registre i camí; un registre A per a IPv4 no estableix accessibilitat per IPv6.

Un nom DNS tampoc no porta cap mapatge de ports ni cap receptor. Si el servei escolta a 1194 UDP, el nom encara es resol a un amfitrió que ha d’acceptar 1194 UDP. Un proxy invers HTTP al port 443 que serveix la consola web no és el punt final del transport VPN, encara que tots dos comparteixin el mateix nom.

L’encaminament per dominis dins del túnel és encara una altra capa. Anomenar el punt final exterior no diu res sobre quines destinacions privades pot assolir un client.

Envieu el nom nou als clients que ja existeixen

Canviar el camp no reescriu els perfils que ja han sortit del servidor. La sincronització de configuració autenticada de Pritunl pot lliurar els canvis d’adreça i port de l’amfitrió als clients compatibles, i el client CLI documentat se sincronitza abans de connectar-se o reconnectar-se. Un perfil importat a NetworkManager o a un client OpenVPN autònom no té aquest canal i necessita un reemplaçament aprovat. Les sessions existents no proven res, perquè es van establir amb el valor antic.

Quan la consola web seu darrere d’un balancejador de càrrega, Pritunl documenta un paràmetre Adreça de sincronització a part per al camí de sincronització. No reutilitzeu el nom d’amfitrió de la consola per al receptor VPN només perquè tots dos són Pritunl.

Lliureu el canvi en aquest ordre: deseu el paràmetre de l’amfitrió, exporteu o sincronitzeu el perfil actual, substituïu la còpia del client i torneu a connectar. Anoteu quins clients gestiona la sincronització i quins tenen fitxers importats, perquè el segon grup no seguirà automàticament. Una llista de propietat dels clients és més útil aquí que un altre registre DNS.

Accepteu el canvi amb una connexió real

La resolució és la prova més feble possible. dig +short vpn.example.net que retorna una adreça només demostra que existeix un registre.

La prova d’acceptació és una connexió autenticada nova des d’un client amb el perfil nou, seguida d’una petició a un recurs privat que hauria de ser abastable pel túnel. Comproveu al registre del client el punt final que realment va fer servir, no el que preteníeu. Manteniu un camí de gestió que no depengui que el nom es canviï correctament, perquè un error no us pugui deixar fora de la consola.

Més endavant, quan l’adreça pública es mogui, actualitzeu el registre i planifiqueu la memòria cau dels clients i el comportament de reconnexió. Un nom d’amfitrió desacobla els clients d’una adreça numèrica; no mou un sòcol actiu ni fa que un receptor inaccessible respongui.