Мислите ли, че преименуването на сървъра 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, който връща адрес, доказва само че съществува запис.

Приемният тест е нова удостоверена връзка от клиент с новия профил, последвана от заявка към частен ресурс, който трябва да е достъпен през тунела. Проверете в клиентския журнал крайната точка, която той действително е използвал, а не тази, която сте предвидили. Пазете път за управление, който не зависи от правилната промяна на името, така че грешка да не ви заключи извън конзолата.

По-късно, когато публичният адрес се премести, актуализирайте записа и планирайте кеширането при клиента и поведението при повторно свързване. Името на хоста отделя клиентите от цифров адрес; то не мести жив сокет и не кара недостъпен слушател да отговаря.