Вы думаеце, што перайменаванне сервера Pritunl змяняе яго канчатковы пункт?

Перайменаванне сервера Pritunl змяняе назву ў кансолі. Яно не змяняе адрас, да якога падключаюцца кліенцкія профілі, і не стварае запіс DNS. Важнае значэнне — публічны адрас хоста, і ён прымае імя так жа ахвотна, як і адрас.

Імя, да якога падключаюцца кліенты, жыве ў адным полі хоста

Pritunl адкрывае канчатковы пункт праз наладу Публічны адрас хоста, якая прымае альбо публічны IP-адрас, альбо імя DNS. Пастаўце там vpn.example.net, і згенераваныя профілі разам з аўтэнтыфікаванай сінхранізацыяй перададуць гэтае імя кліентам. Запіс мусіць ужо існаваць і ўказваць на слухача, які прымае транспарт VPN; гэтае поле абвяшчае пункт прызначэння, але не публікуе яго. Адлюстраванае імя аб'екта сервера — гэта адміністрацыйныя метаданыя, і яно ніколі не даходзіць да спробы злучэння кліента.

Таму першы крок — не перайменаванне чаго-небудзь. Адкрыйце налады хоста, змяніце публічны адрас і захавайце праз падтрымліваемы інтэрфейс.

Тры палі, якія выглядаюць падобна і не з'яўляюцца такімі

Лакальны адрас служыць рэплікацыі і маршрутызацыі паміж хостамі Pritunl. Адрас сувязі апісвае, як злучаныя серверы дасягаюць адзін аднаго. Ніводзін з іх не з'яўляецца адрасам, да якога падключаецца кліент, і капіраванне публічнага імя ў іх ламае тапалогію, якую яны апісваюць. Публічны адрас IPv6 — асобнае поле з уласным запісам і шляхам; запіс A для IPv4 не стварае дасяжнасці праз IPv6.

Імя DNS таксама не нясе ні супастаўлення партоў, ні слухача. Калі служба слухае на 1194 UDP, імя ўсё адно ўказвае на хост, які мусіць прымаць 1194 UDP. Зваротны праксі HTTP на парту 443, які абслугоўвае вэб-кансоль, не з'яўляецца канчатковым пунктам транспарту VPN, нават калі абодва маюць адно імя.

Маршрутызацыя на аснове даменаў усярэдзіне тунеля — гэта яшчэ адзін узровень. Называнне знешняга канчатковага пункта нічога не кажа пра тое, да якіх прыватных пунктаў прызначэння можа дасягнуць кліент.

Перадайце новае імя кліентам, якія ўжо існуюць

Змяненне поля не перапісвае профілі, якія ўжо пакінулі сервер. Аўтэнтыфікаваная сінхранізацыя канфігурацыі Pritunl можа дастаўляць змены адраса хоста і порта сумяшчальным кліентам, а дакументаваны кліент CLI сінхранізуецца перад злучэннем або паўторным злучэннем. Профіль, імпартаваны ў NetworkManager або ў асобны кліент OpenVPN, не мае такога канала і патрабуе ўзгодненай замены. Існуючыя сесіі нічога не даказваюць, бо яны ўсталяваныя па старым значэнні.

Калі вэб-кансоль знаходзіцца за балансіроўшчыкам нагрузкі, Pritunl дакументуе асобную наладу Адрас сінхранізацыі для шляху сінхранізацыі. Не выкарыстоўвайце імя хоста кансолі для слухача VPN толькі таму, што абодва — Pritunl.

Дастаўляйце змену ў такім парадку: захавайце наладу хоста, экспартуйце або сінхранізуйце бягучы профіль, заменіце копію кліента, потым падключыцеся зноў. Запішыце, якімі кліентамі кіруе сінхранізацыя, а якія трымаюць імпартаваныя файлы, бо другая група не пойдзе аўтаматычна. Спіс прыналежнасці кліентаў тут карыснейшы за чарговы запіс DNS.

Прыміце змену рэальным злучэннем

Разрозненне — самая слабая магчымая праверка. dig +short vpn.example.net, які вяртае адрас, даказвае толькі тое, што запіс існуе.

Прыёмачная праверка — гэта свежае аўтэнтыфікаванае злучэнне ад кліента з новым профілем, а за ім — запыт да прыватнага рэсурсу, які павінен быць дасяжны праз тунель. Праверце ў журнале кліента канчатковы пункт, які ён фактычна выкарыстаў, а не той, які вы мелі на ўвазе. Трымайце шлях кіравання, які не залежыць ад правільнага змянення імя, каб памылка не замкнула вас па-за кансоллю.

Пазней, калі публічны адрас зменіцца, абнавіце запіс і сплануйце кэшаванне на баку кліента і паводзіны пры перападключэнні. Імя хоста адвязвае кліентаў ад лікавага адраса; яно не перамяшчае жывы сокет і не прымушае недасяжнага слухача адказваць.