Tror du att ett byte av namn på Pritunl-servern ändrar dess slutpunkt?

Att byta namn på en Pritunl-server ändrar en etikett i konsolen. Det ändrar inte adressen som klientprofilerna ansluter till, och det skapar ingen DNS-post. Värdet som spelar roll är värdens offentliga adress, och den accepterar ett namn lika gärna som en adress.

Namnet som klienterna ansluter till bor i ett enda fält hos värden

Pritunl exponerar slutpunkten via värdens inställning Offentlig adress, som accepterar antingen en offentlig IP-adress eller ett DNS-namn. Sätt vpn.example.net där, och de genererade profilerna och den autentiserade synkroniseringen ger klienterna det namnet. Posten måste redan finnas och peka ut den lyssnare som tar emot VPN-trafik; fältet annonserar en destination, det publicerar den inte. Visningsnamnet för ett serverobjekt är administrativa metadata och når aldrig klientens anslutningsförsök.

Så det första steget är inte att byta namn på något. Öppna värdinställningarna, ändra den offentliga adressen och spara via det stödda gränssnittet.

Tre fält som ser likadana ut och inte är det

Lokal adress tjänar replikering och routning mellan Pritunl-värdar. Länkadress beskriver hur sammankopplade servrar når varandra. Inget av dem är adressen som en klient ansluter till, och att kopiera det offentliga namnet dit bryter topologin de beskriver. Offentlig IPv6-adress är ett eget fält med egen post och egen väg; en A-post för IPv4 ger inte IPv6-nåbarhet.

Ett DNS-namn bär heller ingen portmappning och ingen lyssnare. Om tjänsten lyssnar på 1194 UDP pekar namnet fortfarande på en värd som måste acceptera 1194 UDP. En HTTP-omvänd proxy på port 443 som betjänar webbkonsolen är inte VPN-transportens slutpunkt, även när båda delar samma namn.

Domänbaserad routning inne i tunneln är ännu ett annat lager. Att namnge den yttre slutpunkten säger ingenting om vilka privata destinationer en klient kan nå.

Skicka det nya namnet till klienterna som finns

Ändring av fältet skriver inte om profiler som redan har lämnat servern. Pritunls autentiserade konfigurationssynkronisering kan leverera ändringar av värdens adress och port till kompatibla klienter, och den dokumenterade CLI-klienten synkroniserar innan den ansluter eller återansluter. En profil som importerats till NetworkManager eller en fristående OpenVPN-klient har ingen sådan kanal och behöver en godkänd ersättning. Befintliga sessioner bevisar ingenting, eftersom de upprättades mot det gamla värdet.

När webbkonsolen står bakom en lastbalanserare dokumenterar Pritunl en separat inställning Synkroniseringsadress för synkroniseringsvägen. Återanvänd inte konsolens värdnamn för VPN-lyssnaren bara för att båda är Pritunl.

Leverera ändringen i den här ordningen: spara värdinställningen, exportera eller synkronisera den aktuella profilen, ersätt klientens kopia och anslut sedan igen. Notera vilka klienter som styrs av synkronisering och vilka som har importerade filer, eftersom den andra gruppen inte följer automatiskt. En lista över klientägande är mer användbar här än ännu en DNS-post.

Acceptera ändringen med en riktig anslutning

Uppslagning är det svagaste möjliga testet. dig +short vpn.example.net som returnerar en adress bevisar bara att en post finns.

Acceptanstestet är en ny autentiserad anslutning från en klient med den nya profilen, följd av en begäran till en privat resurs som ska vara nåbar genom tunneln. Kontrollera i klientloggen vilken slutpunkt den faktiskt använde, inte den du hade tänkt. Behåll en administrationsväg som inte är beroende av att namnet ändras korrekt, så att ett misstag inte kan låsa dig ute från konsolen.

Senare, när den offentliga adressen flyttar, uppdatera posten och planera för klientcachning och återanslutningsbeteende. Ett värdnamn kopplar loss klienterna från en numerisk adress; det flyttar inte en aktiv socket eller får en onåbar lyssnare att svara.