A mendoni se riemërtimi i serverit Pritunl ndryshon pikën e tij fundore?

Riemërtimi i një serveri Pritunl ndryshon një etiketë në konsolë. Nuk ndryshon adresën me të cilën lidhen profilët e klientëve dhe nuk krijon një regjistrim DNS. Vlera që ka rëndësi është Adresa Publike e hostit, dhe ajo pranon një emër po aq lehtë sa një adresë.

Emri me të cilin lidhen klientët jeton në një fushë të vetme të hostit

Pritunl e ekspozon pikën fundore përmes cilësimit Adresa Publike të hostit, i cili pranon një adresë IP publike ose një emër DNS. Vendosni vpn.example.net atje, dhe profilët e gjeneruar dhe sinkronizimi i vërtetuar do t'ia dorëzojnë atë emër klientëve. Regjistrimi duhet të ekzistojë tashmë dhe të zgjidhet drejt dëgjuesit që pranon transportin VPN; fusha njofton një destinacion, nuk e publikon atë. Emri i shfaqur i një objekti serveri është metadata administrative dhe nuk arrin kurrë në përpjekjen e lidhjes së klientit.

Pra hapi i parë nuk është riemërtimi i asgjëje. Hapni cilësimet e hostit, ndryshoni Adresën Publike dhe ruani përmes ndërfaqes së mbështetur.

Tre fusha që duken njësoj dhe nuk janë

Adresa Lokale shërben replikimin dhe rrugëtimin midis hosteve Pritunl. Adresa e Lidhjes përshkruan si serverët e lidhur arrijnë njëri-tjetrin. Asnjëra nuk është adresa me të cilën lidhet një klient, dhe kopjimi i emrit publik në to prish topologjinë që përshkruajnë. Adresa Publike IPv6 është një fushë e veçantë me regjistrimin dhe shtegun e vet; një regjistrim A për IPv4 nuk vendos aksesueshmëri IPv6.

Një emër DNS gjithashtu nuk mbart asnjë hartëzim portesh dhe asnjë dëgjues. Nëse shërbimi dëgjon në 1194 UDP, emri zgjidhet përsëri në një host që duhet të pranojë 1194 UDP. Një proxy i kundërt HTTP në portën 443 që shërben konsolën web nuk është pika fundore e transportit VPN, edhe kur të dy ndajnë të njëjtin emër.

Rrugëtimi i bazuar në domain brenda tunelit është edhe një shtresë tjetër. Emërtimi i pikës fundore të jashtme nuk thotë asgjë për destinacionet private që një klient mund të arrijë.

Dërgoni emrin e ri te klientët që ekzistojnë

Ndryshimi i fushës nuk i rishkruan profilët që kanë lënë tashmë serverin. Sinkronizimi i vërtetuar i konfigurimit i Pritunl mund t'u dorëzojë ndryshimet e adresës dhe portës së hostit klientëve të përputhshëm, dhe klienti CLI i dokumentuar sinkronizohet përpara se të lidhet ose të rilidhet. Një profil i importuar në NetworkManager ose në një klient OpenVPN të pavarur nuk ka një kanal të tillë dhe kërkon një zëvendësim të miratuar. Sesionet ekzistuese nuk provojnë asgjë, sepse u krijuan me vlerën e vjetër.

Kur konsola web qëndron pas një balancuesi ngarkese, Pritunl dokumenton një cilësim të veçantë Adresa e Sinkronizimit për shtegun e sinkronizimit. Mos e ripërdorni emrin e hostit të konsolës për dëgjuesin VPN vetëm sepse të dy janë Pritunl.

Dorëzojeni ndryshimin në këtë rend: ruani cilësimin e hostit, eksportoni ose sinkronizoni profilin aktual, zëvendësoni kopjen e klientit dhe më pas rilidhuni. Shënoni cilët klientë menaxhohen nga sinkronizimi dhe cilët mbajnë skedarë të importuar, sepse grupi i dytë nuk do të ndjekë automatikisht. Një listë e pronësisë së klientëve është më e dobishme këtu sesa një regjistrim tjetër DNS.

Pranojeni ndryshimin me një lidhje të vërtetë

Zgjidhja është testi më i dobët i mundshëm. dig +short vpn.example.net që kthen një adresë provon vetëm se ekziston një regjistrim.

Testi i pranimit është një lidhje e vërtetuar e re nga një klient që mban profilin e ri, e ndjekur nga një kërkesë drejt një burimi privat që duhet të jetë i arritshëm përmes tunelit. Kontrolloni në regjistrin e klientit pikën fundore që përdori në të vërtetë, jo atë që kishit ndërmend. Mbani një shteg administrimi që nuk varet nga ndryshimi i saktë i emrit, që një gabim të mos ju mbyllë jashtë konsolës.

Më vonë, kur adresa publike të zhvendoset, përditësoni regjistrimin dhe planifikoni cache-n e klientëve dhe sjelljen e rilidhjes. Një emër hosti i shkëput klientët nga një adresë numerike; nuk lëviz një socket aktiv dhe nuk bën një dëgjues të paarritshëm të përgjigjet.