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

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

Позже, когда публичный адрес сместится, обновите запись и запланируйте кеширование у клиентов и поведение при переподключении. Имя хоста отвязывает клиентов от числового адреса; оно не перемещает активный сокет и не заставляет недоступного слушателя отвечать.