Tror du at omdøping av Pritunl-serveren endrer endepunktet dens?

Omdøping av en Pritunl-server endrer en etikett i konsollen. Det endrer ikke adressen som klientprofilene kobler til, og det oppretter ikke en DNS-post. Verdien som betyr noe, er vertens offentlige adresse, og den godtar et navn like gjerne som en adresse.

Navnet klientene kobler til, bor i ett vertsfelt

Pritunl eksponerer endepunktet via vertens innstilling Offentlig adresse, som godtar enten en offentlig IP-adresse eller et DNS-navn. Sett vpn.example.net der, og de genererte profilene og den autentiserte synkroniseringen gir klientene det navnet. Posten må allerede finnes og peke på lytteren som godtar VPN-transport; feltet annonserer en destinasjon, det publiserer den ikke. Visningsnavnet til et serverobjekt er administrative metadata og når aldri klientens tilkoblingsforsøk.

Så det første steget er ikke å døpe om noe. Åpne vertsinnstillingene, endre den offentlige adressen, og lagre via det støttede grensesnittet.

Tre felt som ser like ut og ikke er det

Lokal adresse tjener replikering og ruting mellom Pritunl-verter. Lenkeadresse beskriver hvordan sammenkoblede servere når hverandre. Ingen av dem er adressen en klient kobler til, og å kopiere det offentlige navnet inn i dem ødelegger topologien de beskriver. Offentlig IPv6-adresse er et eget felt med sin egen post og sti; en A-post for IPv4 etablerer ikke IPv6-tilgjengelighet.

Et DNS-navn bærer heller ingen portmapping og ingen lytter. Hvis tjenesten lytter på 1194 UDP, peker navnet fortsatt på en vert som må godta 1194 UDP. En HTTP-reversproxy på port 443 som betjener webkonsollen, er ikke VPN-transportens endepunkt, selv når begge deler samme navn.

Domenebasert ruting inne i tunnelen er enda et annet lag. Navngiving av det ytre endepunktet sier ingenting om hvilke private destinasjoner en klient kan nå.

Skyv det nye navnet ut til klientene som finnes

Endring av feltet skriver ikke om profiler som allerede har forlatt serveren. Pritunls autentiserte konfigurasjonssynkronisering kan levere endringer i vertens adresse og port til kompatible klienter, og den dokumenterte CLI-klienten synkroniserer før den kobler til eller kobler til på nytt. En profil importert i NetworkManager eller en frittstående OpenVPN-klient har ingen slik kanal og trenger en godkjent erstatning. Eksisterende økter beviser ingenting, fordi de ble opprettet mot den gamle verdien.

Når webkonsollen står bak en lastbalanserer, dokumenterer Pritunl en egen innstilling Synkroniseringsadresse for synkroniseringsstien. Ikke bruk konsollens vertsnavn på nytt for VPN-lytteren bare fordi begge er Pritunl.

Lever endringen i denne rekkefølgen: lagre vertsinnstillingen, eksporter eller synkroniser den gjeldende profilen, erstatt klientens kopi, og koble deretter til på nytt. Noter hvilke klienter som styres av synkronisering, og hvilke som har importerte filer, fordi den andre gruppen ikke følger automatisk. En liste over klienters eierskap er mer nyttig her enn nok en DNS-post.

Godta endringen med en ekte tilkobling

Oppslag er den svakeste mulige testen. dig +short vpn.example.net som returnerer en adresse, beviser bare at en post finnes.

Aksepttesten er en fersk autentisert tilkobling fra en klient med den nye profilen, etterfulgt av en forespørsel til en privat ressurs som skal være tilgjengelig gjennom tunnelen. Sjekk i klientloggen hvilket endepunkt den faktisk brukte, ikke det du hadde tenkt. Hold en administrasjonsvei som ikke avhenger av at navnet endres riktig, slik at en feil ikke kan låse deg ute av konsollen.

Senere, når den offentlige adressen flytter seg, oppdater posten og planlegg for klientbufring og gjenoppkoblingsatferd. Et vertsnavn frikobler klientene fra en numerisk adresse; det flytter ikke en aktiv socket eller får en utilgjengelig lytter til å svare.