Sa tingin mo ba ay binabago ng pagpapalit ng pangalan ng Pritunl server ang endpoint nito?

Ang pagpapalit ng pangalan ng Pritunl server ay nagbabago ng label sa console. Hindi nito binabago ang address na kinokonektahan ng mga kliyente profile, at hindi ito gumagawa ng DNS record. Ang halagang mahalaga ay ang Pampublikong Address ng host, at tumatanggap ito ng pangalan kasing dali ng address.

Ang pangalan na kinokonektahan ng mga kliyente ay naninirahan sa isang field ng host

Inilalantad ng Pritunl ang endpoint sa pamamagitan ng setting na Pampublikong Address ng host, na tumatanggap ng pampublikong IP address o DNS name. Ilagay ang vpn.example.net doon, at ang mga nabuong profile at ang authenticated na sync ay ibibigay ang pangalang iyon sa mga kliyente. Dapat umiiral na ang record at dapat itong mag-resolve sa listener na tumatanggap ng VPN transport; ang field ay naghahayag ng destinasyon, hindi ito naglalathala. Ang display name ng isang server object ay administrative metadata at hindi kailanman umaabot sa pagtatangka ng koneksyon ng kliyente.

Kaya ang unang hakbang ay hindi ang pagpapalit ng pangalan ng anuman. Buksan ang mga setting ng host, baguhin ang Pampublikong Address, at i-save sa sinusuportahang interface.

Tatlong field na mukhang pareho at hindi

Ang Lokal na Address ay nagsisilbi sa replication at routing sa pagitan ng mga Pritunl host. Ang Address ng Link ay naglalarawan kung paano naaabot ng mga naka-link na server ang isa't isa. Wala sa dalawa ang address na kinokonektahan ng kliyente, at ang pagkopya ng pampublikong pangalan sa mga ito ay sumisira sa topology na inilalarawan nila. Ang Pampublikong IPv6 Address ay hiwalay na field na may sariling record at landas; ang A record para sa IPv4 ay hindi nagtatatag ng IPv6 reachability.

Ang DNS name ay wala ring port mapping at listener. Kung ang serbisyo ay nakikinig sa 1194 UDP, ang pangalan ay nag-resolve pa rin sa host na dapat tumanggap ng 1194 UDP. Ang HTTP reverse proxy sa port 443 na nagsisilbi sa web console ay hindi ang endpoint ng VPN transport, kahit na pareho silang nagbabahagi ng parehong pangalan.

Ang routing na nakabatay sa domain sa loob ng tunnel ay isa pang layer. Ang pagbibigay ng pangalan sa panlabas na endpoint ay walang sinasabi tungkol sa kung aling mga pribadong destinasyon ang maaabot ng kliyente.

Ipadala ang bagong pangalan sa mga kliyenteng mayroon na

Ang pagbabago ng field ay hindi nagsusulat muli ng mga profile na umalis na sa server. Ang authenticated na configuration sync ng Pritunl ay maaaring maghatid ng mga pagbabago sa address at port ng host sa mga compatible na kliyente, at ang dokumentadong CLI client ay nag-sync bago kumonekta o muling kumonekta. Ang profile na inangkat sa NetworkManager o sa standalone na OpenVPN client ay walang ganoong channel at nangangailangan ng aprubadong kapalit. Ang mga umiiral na session ay walang pinatutunayan, dahil itinatag ang mga ito sa lumang halaga.

Kapag ang web console ay nasa likod ng load balancer, dokumentado ng Pritunl ang hiwalay na setting na Address ng Sync para sa sync path. Huwag muling gamitin ang hostname ng console para sa VPN listener dahil lang pareho silang Pritunl.

Ihatid ang pagbabago sa ganitong pagkakasunod-sunod: i-save ang setting ng host, i-export o i-sync ang kasalukuyang profile, palitan ang kopya ng kliyente, pagkatapos ay muling kumonekta. Itala kung aling mga kliyente ang pinamamahalaan ng sync at alin ang may mga inangkat na file, dahil ang pangalawang grupo ay hindi awtomatikong susunod. Ang listahan ng pagmamay-ari ng kliyente ay mas kapaki-pakinabang dito kaysa sa isa pang DNS record.

Tanggapin ang pagbabago gamit ang tunay na koneksyon

Ang resolution ay ang pinakamahinang posibleng pagsubok. dig +short vpn.example.net na nagbabalik ng address ay nagpapatunay lamang na may record.

Ang acceptance test ay isang bagong authenticated na koneksyon mula sa kliyenteng may bagong profile, na sinusundan ng kahilingan sa isang pribadong resource na dapat maabot sa pamamagitan ng tunnel. Tingnan sa log ng kliyente ang endpoint na aktwal na ginamit, hindi ang nilayon mo. Panatilihin ang management path na hindi umaasa sa tamang pagbabago ng pangalan, upang hindi ka mai-lock out ng isang pagkakamali sa console.

Sa paglaon, kapag lumipat ang pampublikong address, i-update ang record at planuhin ang client caching at pag-uugali ng muling pagkonekta. Ang hostname ay naghihiwalay sa mga kliyente mula sa numeric na address; hindi nito ginagalaw ang isang live na socket o pinapasagot ang isang hindi maabot na listener.