Trur du at omdøyping av Pritunl-tenaren endrar endepunktet hans?

Omdøyping av ein Pritunl-tenar endrar ei etikett i konsollen. Det endrar ikkje adressa som klientprofilane koplar til, og det opprettar ikkje ein DNS-post. Verdien som tel, er den offentlege adressa til verten, og ho godtek eit namn like gjerne som ei adresse.

Namnet klientane koplar til, bur i eitt vertsfelt

Pritunl eksponerer endepunktet via innstillinga Offentleg adresse til verten, som godtek anten ei offentleg IP-adresse eller eit DNS-namn. Set vpn.example.net der, og dei genererte profilane og den autentiserte synkroniseringa gjev klientane det namnet. Posten må allereie finnast og peike på lyttaren som godtek VPN-transport; feltet annonserer ein destinasjon, det publiserer han ikkje. Visningsnamnet til eit tenarobjekt er administrative metadata og når aldri fram til tilkoplingsforsøket til klienten.

Så det første steget er ikkje å døype om noko. Opne vertsinnstillingane, endre den offentlege adressa, og lagre via det støtta grensesnittet.

Tre felt som ser like ut og ikkje er det

Lokal adresse tener replikering og ruting mellom Pritunl-vertar. Lenkjeadresse skildrar korleis samankopla tenarar når kvarandre. Ingen av dei er adressa ein klient koplar til, og å kopiere det offentlege namnet inn i dei øydelegg topologien dei skildrar. Offentleg IPv6-adresse er eit eige felt med sin eigen post og sti; ein A-post for IPv4 etablerer ikkje IPv6-tilgjenge.

Eit DNS-namn ber heller inga portkartlegging og ingen lyttar. Viss tenesta lyttar på 1194 UDP, peikar namnet framleis på ein vert som må godta 1194 UDP. Ein HTTP-omvend proxy på port 443 som tener nettkonsollen, er ikkje endepunktet for VPN-transporten, sjølv når begge deler same namn.

Domenebasert ruting inne i tunnelen er endå eit anna lag. Namngjeving av det ytre endepunktet seier ingenting om kva private destinasjonar ein klient kan nå.

Skyv det nye namnet ut til klientane som finst

Endring av feltet skriv ikkje om profilar som allereie har forlate tenaren. Den autentiserte konfigurasjonssynkroniseringa til Pritunl kan levere endringar i adresse og port til verten til kompatible klientar, og den dokumenterte CLI-klienten synkroniserer før han koplar til eller koplar til på nytt. Ein profil importert i NetworkManager eller ein frittståande OpenVPN-klient har ingen slik kanal og treng ei godkjend erstatning. Eksisterande økter beviser ingenting, fordi dei vart oppretta mot den gamle verdien.

Når nettkonsollen står bak ein lastbalansar, dokumenterer Pritunl ei eiga innstilling Synkroniseringsadresse for synkroniseringsstien. Ikkje bruk vertsnamnet til konsollen på nytt for VPN-lyttaren berre fordi begge er Pritunl.

Lever endringa i denne rekkjefølgja: lagre vertsinnstillinga, eksporter eller synkroniser den gjeldande profilen, erstatt kopien til klienten, og kople deretter til på nytt. Noter kva klientar som vert styrte av synkronisering, og kva som har importerte filer, fordi den andre gruppa ikkje følgjer automatisk. Ei liste over klientars eigarskap er meir nyttig her enn endå ein DNS-post.

Godta endringa med ei ekte tilkopling

Oppslag er den svakaste mogelege testen. dig +short vpn.example.net som returnerer ei adresse, beviser berre at ein post finst.

Godtakingsprøva er ei fersk autentisert tilkopling frå ein klient med den nye profilen, etterfølgd av ein førespurnad til ein privat ressurs som skal vere tilgjengeleg gjennom tunnelen. Sjekk i klientloggen kva endepunkt han faktisk brukte, ikkje det du hadde tenkt. Hald ein administrasjonsveg som ikkje er avhengig av at namnet vert endra rett, slik at ein feil ikkje kan låse deg ute av konsollen.

Seinare, når den offentlege adressa flyttar seg, oppdater posten og planlegg for klientbufring og atferd ved gjenoppkopling. Eit vertsnamn frikoplar klientane frå ei numerisk adresse; det flyttar ikkje ein aktiv sokkel eller får ein utilgjengeleg lyttar til å svare.