Ви вважаєте, що перейменування сервера 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, що повертає адресу, доводить лише те, що запис існує.

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

Пізніше, коли публічна адреса зсунеться, оновіть запис і сплануйте кешування в клієнтів та поведінку під час перепідключення. Ім'я хоста відв'язує клієнтів від числової адреси; воно не переносить активний сокет і не змушує недоступного слухача відповідати.