Kas arvate, et Pritunl-serveri ümbernimetamine muudab selle lõpp-punkti?

Pritunl-serveri ümbernimetamine muudab konsoolis silti. See ei muuda aadressi, millega kliendiprofiilid ühenduvad, ega loo DNS-kirjet. Oluline väärtus on hosti avalik aadress ja see võtab nime vastu sama kergesti kui aadressi.

Nimi, millega kliendid ühenduvad, elab ühes hosti väljas

Pritunl avab lõpp-punkti hosti seade Avalik aadress kaudu, mis võtab vastu kas avaliku IP-aadressi või DNS-nime. Pange sinna vpn.example.net ja loodud profiilid ning autenditud sünkroonimine annavad selle nime klientidele edasi. Kirje peab juba olemas olema ja suunama kuulajale, mis võtab vastu VPN-liikluse; väli kuulutab sihtkoha, aga ei avalda seda. Serveriobjekti kuvatav nimi on haldusmetaandmed ega jõua kunagi kliendi ühenduskatseni.

Nii et esimene samm ei ole millegi ümbernimetamine. Avage hosti seaded, muutke avalikku aadressi ja salvestage toetatud liidese kaudu.

Kolm välja, mis näevad sarnased välja ja ei ole seda

Kohalik aadress teenib Pritunl-hostide vahelist replikatsiooni ja marsruutimist. Lingiaadress kirjeldab, kuidas lingitud serverid üksteiseni jõuavad. Kumbki ei ole aadress, millega klient ühendub, ja avaliku nime kopeerimine neisse rikub topoloogia, mida need kirjeldavad. Avalik IPv6-aadress on eraldi väli oma kirje ja teega; IPv4 jaoks mõeldud A-kirje ei loo IPv6 kättesaadavust.

DNS-nimi ei kanna ka portide vastendust ega kuulajat. Kui teenus kuulab 1194 UDP-l, laheneb nimi ikkagi hostile, mis peab vastu võtma 1194 UDP. HTTP-pöördproksi pordil 443, mis teenindab veebikonsooli, ei ole VPN-i transpordi lõpp-punkt, isegi kui mõlemad jagavad sama nime.

Domeenipõhine marsruutimine tunnelis on jälle teine kiht. Välise lõpp-punkti nimetamine ei ütle midagi selle kohta, millistele privaatsetele sihtkohtadele klient pääseb.

Saatke uus nimi olemasolevatele klientidele

Välja muutmine ei kirjuta üle profiile, mis on serverist juba lahkunud. Pritunli autenditud konfiguratsiooni sünkroonimine saab toimetada hosti aadressi ja pordi muudatused ühilduvatele klientidele ning dokumenteeritud CLI-klient sünkroonib enne ühendamist või uuesti ühendamist. NetworkManagerisse või eraldiseisvasse OpenVPN-kliendisse imporditud profiilil sellist kanalit ei ole ja see vajab kinnitatud asendust. Olemasolevad sessioonid ei tõesta midagi, sest need loodi vana väärtuse vastu.

Kui veebikonsool seisab koormusjaoturi taga, dokumenteerib Pritunl sünkroonimisteekonna jaoks eraldi seade Sünkroonimisaadress. Ärge kasutage konsooli hostinime VPN-i kuulaja jaoks uuesti ainult seetõttu, et mõlemad on Pritunl.

Toimetage muudatus selles järjekorras: salvestage hosti seade, eksportige või sünkroonige praegune profiil, asendage kliendi koopia ja seejärel ühenduge uuesti. Märkige üles, milliseid kliente haldab sünkroonimine ja millistel on imporditud failid, sest teine rühm ei järgi automaatselt. Klientide omandi loend on siin kasulikum kui veel üks DNS-kirje.

Võtke muudatus vastu tõelise ühendusega

Lahendamine on nõrgim võimalik test. dig +short vpn.example.net, mis tagastab aadressi, tõestab ainult seda, et kirje on olemas.

Vastuvõtutest on värske autenditud ühendus kliendist, kellel on uus profiil, millele järgneb päring privaatsele ressursile, mis peaks olema tunnelist kättesaadav. Kontrollige kliendi logist lõpp-punkti, mida see tegelikult kasutas, mitte seda, mida kavatsesite. Hoidke haldustee, mis ei sõltu nime õigest muutmisest, et viga ei saaks teid konsoolist välja lukustada.

Hiljem, kui avalik aadress liigub, värskendage kirjet ning planeerige kliendi vahemällu salvestamist ja taasühendumise käitumist. Hostinimi eraldab kliendid numbrilisest aadressist; see ei liiguta aktiivset soklit ega pane kättesaamatut kuulajat vastama.