Denkt u dat het hernoemen van de Pritunl-server het endpoint verandert?

Het hernoemen van een Pritunl-server verandert een label in de console. Het verandert niet het adres waarop clientprofielen verbinden, en het maakt geen DNS-record aan. De waarde die ertoe doet is het openbare adres van de host, en dat accepteert een naam net zo gemakkelijk als een adres.

De naam waarop clients verbinden zit in één hostveld

Pritunl biedt het endpoint aan via de instelling Openbaar adres van de host, die een openbaar IP-adres of een DNS-naam accepteert. Zet vpn.example.net daar, en de gegenereerde profielen en de geauthenticeerde synchronisatie geven die naam aan clients. Het record moet al bestaan en naar de listener verwijzen die VPN-verkeer accepteert; het veld adverteert een bestemming, het publiceert er geen. De weergavenaam van een serverobject is administratieve metadata en bereikt nooit de verbindingspoging van de client.

De eerste stap is dus niet iets hernoemen. Open de hostinstellingen, wijzig het openbare adres en sla op via de ondersteunde interface.

Drie velden die er hetzelfde uitzien en het niet zijn

Lokaal adres dient replicatie en routing tussen Pritunl-hosts. Linkadres beschrijft hoe gekoppelde servers elkaar bereiken. Geen van beide is het adres waarop een client verbindt, en het openbare adres erin kopiëren breekt de topologie die ze beschrijven. Openbaar IPv6-adres is een apart veld met een eigen record en pad; een A-record voor IPv4 vestigt geen IPv6-bereikbaarheid.

Een DNS-naam draagt ook geen portmapping en geen listener. Als de dienst op 1194 UDP luistert, wijst de naam nog steeds naar een host die 1194 UDP moet accepteren. Een HTTP-reverseproxy op poort 443 die de webconsole bedient, is niet het endpoint van het VPN-transport, zelfs niet wanneer beide dezelfde naam delen.

Domeingebaseerde routing binnen de tunnel is weer een andere laag. Het benoemen van het buitenste endpoint zegt niets over welke privébestemmingen een client kan bereiken.

Stuur de nieuwe naam naar de clients die al bestaan

Het wijzigen van het veld herschrijft geen profielen die de server al hebben verlaten. De geauthenticeerde configuratiesynchronisatie van Pritunl kan adres- en poortwijzigingen van de host aan compatibele clients leveren, en de gedocumenteerde CLI-client synchroniseert voordat hij verbindt of opnieuw verbindt. Een profiel dat in NetworkManager of een zelfstandige OpenVPN-client is geïmporteerd, heeft zo'n kanaal niet en heeft een goedgekeurde vervanging nodig. Bestaande sessies bewijzen niets, want ze zijn opgezet met de oude waarde.

Wanneer de webconsole achter een load balancer staat, documenteert Pritunl een aparte instelling Synchronisatieadres voor het synchronisatiepad. Hergebruik de hostnaam van de console niet voor de VPN-listener, alleen omdat beide Pritunl zijn.

Lever de wijziging in deze volgorde: sla de hostinstelling op, exporteer of synchroniseer het huidige profiel, vervang de kopie van de client en maak daarna opnieuw verbinding. Noteer welke clients door synchronisatie worden beheerd en welke geïmporteerde bestanden hebben, want de tweede groep volgt niet automatisch. Een lijst met clienteigendom is hier nuttiger dan nog een DNS-record.

Accepteer de wijziging met een echte verbinding

Resolutie is de zwakst mogelijke test. dig +short vpn.example.net dat een adres teruggeeft, bewijst alleen dat een record bestaat.

De acceptatietest is een nieuwe geauthenticeerde verbinding van een client met het nieuwe profiel, gevolgd door een verzoek aan een privébron die via de tunnel bereikbaar zou moeten zijn. Controleer in de clientlog het endpoint dat daadwerkelijk is gebruikt, niet dat u had bedoeld. Houd een beheerpad aan dat niet afhankelijk is van het correct wijzigen van de naam, zodat een fout u niet buiten de console kan sluiten.

Als het openbare adres later verschuift, werkt u het record bij en plant u clientcaching en herverbindingsgedrag. Een hostnaam ontkoppelt clients van een numeriek adres; hij verplaatst geen actieve socket en laat geen onbereikbare listener antwoorden.