Manote, kad Pritunl serverio pervadinimas keičia jo galinį tašką?

Pritunl serverio pervadinimas konsolėje pakeičia etiketę. Tai nekeičia adreso, prie kurio jungiasi klientų profiliai, ir nesukuria DNS įrašo. Svarbi reikšmė yra viešasis hosto adresas, ir jis vardą priima taip pat lengvai kaip adresą.

Vardas, prie kurio jungiasi klientai, gyvena viename hosto lauke

Pritunl atskleidžia galinį tašką per hosto nuostatą Viešasis adresas, kuri priima viešą IP adresą arba DNS vardą. Įrašykite ten vpn.example.net, ir sugeneruoti profiliai bei autentifikuotas sinchronizavimas perduos tą vardą klientams. Įrašas jau turi egzistuoti ir būti sprendžiamas į klausytoją, kuris priima VPN transportą; laukas skelbia paskirties vietą, bet jos neviešina. Serverio objekto rodomas vardas yra administraciniai metaduomenys ir niekada nepasiekia kliento prisijungimo bandymo.

Taigi pirmas žingsnis yra ne ką nors pervadinti. Atidarykite hosto nustatymus, pakeiskite viešąjį adresą ir išsaugokite per palaikomą sąsają.

Trys laukai, kurie atrodo panašiai ir nėra tokie

Vietinis adresas tarnauja replikacijai ir maršrutizavimui tarp Pritunl hostų. Ryšio adresas apibūdina, kaip susieti serveriai pasiekia vienas kitą. Nė vienas jų nėra adresas, prie kurio jungiasi klientas, o viešo vardo nukopiavimas į juos sugriauna topologiją, kurią jie apibūdina. Viešasis IPv6 adresas yra atskiras laukas su savo įrašu ir keliu; IPv4 A įrašas nesukuria IPv6 pasiekiamumo.

DNS vardas taip pat neturi nei prievadų susiejimo, nei klausytojo. Jei paslauga klausosi 1194 UDP, vardas vis tiek sprendžiamas į hostą, kuris turi priimti 1194 UDP. HTTP atvirkštinis tarpinis serveris 443 prievade, kuris aptarnauja žiniatinklio konsolę, nėra VPN transporto galinis taškas, net kai abu dalijasi tuo pačiu vardu.

Domenais pagrįstas maršrutizavimas tunelio viduje yra dar kitas sluoksnis. Išorinio galinio taško pavadinimas nieko nesako apie tai, kurias privačias paskirties vietas klientas gali pasiekti.

Nusiųskite naują vardą esamiems klientams

Lauko pakeitimas neperrašo profilių, kurie jau paliko serverį. Pritunl autentifikuotas konfigūracijos sinchronizavimas gali pristatyti hosto adreso ir prievado pakeitimus suderinamiems klientams, o dokumentuotas CLI klientas sinchronizuojasi prieš prisijungdamas arba prisijungdamas iš naujo. Profilis, importuotas į NetworkManager arba atskirą OpenVPN klientą, tokio kanalo neturi ir jam reikia patvirtinto pakaitalo. Esamos sesijos nieko neįrodo, nes jos buvo sukurtos pagal senąją reikšmę.

Kai žiniatinklio konsolė yra už apkrovos balansuotojo, Pritunl dokumentuoja atskirą nuostatą Sinchronizavimo adresas sinchronizavimo keliui. Nenaudokite konsolės hosto vardo VPN klausytojui tik todėl, kad abu yra Pritunl.

Pristatykite pakeitimą šia tvarka: išsaugokite hosto nuostatą, eksportuokite arba sinchronizuokite dabartinį profilį, pakeiskite kliento kopiją, tada prisijunkite iš naujo. Užsirašykite, kuriuos klientus valdo sinchronizavimas, o kurie turi importuotus failus, nes antroji grupė automatiškai nesek. Klientų nuosavybės sąrašas čia naudingesnis nei dar vienas DNS įrašas.

Priimkite pakeitimą tikru ryšiu

Rezoliucija yra silpniausias įmanomas testas. dig +short vpn.example.net, kuris grąžina adresą, įrodo tik tai, kad įrašas egzistuoja.

Priėmimo testas yra naujas autentifikuotas ryšys iš kliento, turinčio naują profilį, po kurio pateikiama užklausa privačiam ištekliui, kuris turėtų būti pasiekiamas per tunelį. Patikrinkite kliento žurnale galinį tašką, kurį jis iš tikrųjų naudojo, o ne tą, kurį ketinote. Turėkite valdymo kelią, kuris nepriklauso nuo teisingo vardo pakeitimo, kad klaida negalėtų jūsų užrakinti už konsolės.

Vėliau, kai viešasis adresas pasislinks, atnaujinkite įrašą ir suplanuokite klientų podėliavimą bei pakartotinio prisijungimo elgesį. Hosto vardas atskiria klientus nuo skaitmeninio adreso; jis neperkelia veikiančio lizdo ir nepriverčia nepasiekiamo klausytojo atsakyti.