Ĉu vi pensas, ke renomado de la Pritunl-servilo ŝanĝas ĝian finpunkton?

Renomado de Pritunl-servilo ŝanĝas etikedon en la konzolo. Ĝi ne ŝanĝas la adreson, kiun alvokas klientaj profiloj, kaj ĝi ne kreas DNS-rikordon. La valoro, kiu gravas, estas la Publika Adreso de la gastiganto, kaj ĝi akceptas nomon same pretente kiel adreson.

La nomo, kiun alvokas klientoj, loĝas en unu kampo de la gastiganto

Pritunl elmontras la finpunkton per la agordo Publika Adreso de la gastiganto, kiu akceptas aŭ publikan IP-adreson aŭ DNS-nomon. Metu vpn.example.net tien, kaj la generitaj profiloj kaj la aŭtentikigita sinkronigo transdonos tiun nomon al klientoj. La rikordo jam devas ekzisti kaj resolviĝi al la aŭskultanto, kiu akceptas VPN-transporton; la kampo anoncas celon, ĝi ne publikigas ĝin. La montra nomo de servila objekto estas administra metadatumo kaj neniam atingas la konektprovan de la kliento.

Do la unua paŝo ne estas renomi ion ajn. Malfermu la agordojn de la gastiganto, ŝanĝu la Publikan Adreson kaj konservu per la subtenata interfaco.

Tri kampoj, kiuj similas kaj ne estas tiaj

Loka Adreso servas al replikado kaj enkursigo inter Pritunl-gastigantoj. Liga Adreso priskribas, kiel ligitaj serviloj atingas unu la alian. Neniu el ili estas la adreso, kiun alvokas kliento, kaj kopii la publikan nomon en ilin rompas la topologion, kiun ili priskribas. Publika IPv6-Adreso estas aparta kampo kun propra rikordo kaj vojo; A-rikordo por IPv4 ne starigas IPv6-atingeblecon.

DNS-nomo ankaŭ portas nek pordomapadon nek aŭskultanton. Se la servo aŭskultas sur 1194 UDP, la nomo ankoraŭ resolviĝas al gastiganto, kiu devas akcepti 1194 UDP. HTTP-inversa prokurilo sur pordo 443, kiu servas la retkonzolon, ne estas la finpunkto de VPN-transporto, eĉ kiam ambaŭ dividas la saman nomon.

Domajnbazita enkursigo ene de la tunelo estas ankoraŭ alia tavolo. Nomado de la ekstera finpunkto diras nenion pri tio, kiujn privatajn celojn kliento povas atingi.

Sendu la novan nomon al la klientoj, kiuj ekzistas

Ŝanĝi la kampon ne reskribas profilojn, kiuj jam forlasis la servilon. La aŭtentikigita agorda sinkronigo de Pritunl povas transdoni ŝanĝojn de gastiganta adreso kaj pordo al kongruaj klientoj, kaj la dokumentita CLI-kliento sinkronigas antaŭ ol konekti aŭ rekonekti. Profilo importita en NetworkManager aŭ en memstaran OpenVPN-klienton ne havas tian kanalon kaj bezonas aprobitan anstataŭaĵon. Ekzistantaj sesioj pruvas nenion, ĉar ili estis starigitaj laŭ la malnova valoro.

Kiam la retkonzolo staras malantaŭ ŝarĝbalancilo, Pritunl dokumentas apartan agordon Sinkroniga Adreso por la sinkroniga vojo. Ne reuzu la gastigantan nomon de la konzolo por la VPN-aŭskultanto nur ĉar ambaŭ estas Pritunl.

Liveru la ŝanĝon en ĉi tiu ordo: konservu la agordon de la gastiganto, eksportu aŭ sinkronigu la nunan profilon, anstataŭigu la kopion de la kliento, poste rekonektu. Notu, kiujn klientojn administras sinkronigo kaj kiuj tenas importitajn dosierojn, ĉar la dua grupo ne sekvos aŭtomate. Listo de klienta posedado estas pli utila ĉi tie ol alia DNS-rikordo.

Akceptu la ŝanĝon per reala konekto

Resolvado estas la plej malforta ebla testo. dig +short vpn.example.net, kiu redonas adreson, pruvas nur, ke rikordo ekzistas.

La akcepta testo estas freŝa aŭtentikigita konekto de kliento tenanta la novan profilon, sekvata de peto al privata rimedo, kiu devus esti atingebla tra la tunelo. Kontrolu en la klienta protokolo la finpunkton, kiun ĝi efektive uzis, ne tiun, kiun vi intencis. Tenu administran vojon, kiu ne dependas de tio, ke la nomo estu ĝuste ŝanĝita, por ke eraro ne povu ŝlosi vin ekster la konzolo.

Poste, kiam la publika adreso moviĝos, ĝisdatigu la rikordon kaj planu klientan kaŝadon kaj rekonektan konduton. Gastiganta nomo malligas klientojn de numera adreso; ĝi ne movas vivan soketon nek igas neatingeblan aŭskultanton respondi.