openvpn3 session-start игнорирует ваш файл учётных данных

Подключитесь клиентом 2.x, и профиль работает; передайте тот же файл клиенту 3.x, и он останавливается на запросе пароля. Передайте --auth-user-pass creds.txt в openvpn3 session-start, и результат тот же, потому что у нового клиента нет этапа, который читает файл. Отказ намеренный: учётные данные принадлежат сеансу, а сеанс создаёт служба, а не процесс в вашем терминале. Выберите между интерактивным запросом и помощником autoload и знайте, что хранит каждый из них.

Почему сохранённому файлу некуда деться

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

Старый шаблон стоит назвать, чтобы от него было легче отвыкнуть: профиль ссылается на файл учётных данных, а демон читает его при запуске туннеля. В новой модели учётные данные принадлежат сеансу и передаются, когда этот сеанс начинается. openvpn3 session-start --config work.ovpn запрашивает их, а --auth-user-pass creds.txt отклоняется, потому что ничто на этом пути не открыло бы файл. Любой найденный вами рецепт для 2.x предполагает этап, которого больше нет.

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

Путь запроса и сеанс, который он оставляет

Передать пароль при старте сеанса — это и есть задуманный рабочий процесс. Клиент спрашивает один раз, передаёт учётные данные бэкенду сеанса и продолжает:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Этим путём на диск ничего не записывается. Сеанс продолжает работать и после закрытия терминала, что удивляет тех, кто ожидает, что процесс умрёт вместе с оболочкой. В этом и смысл переноса обработки сеансов в службу. Сеанс живёт дольше терминала, который его запросил, и его нужно останавливать явно.

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

Автоматизация без человека за клавиатурой

Там, где машине нужно подключаться без человека, проект поставляет openvpn3-autoload. Он читает каталог профилей и соответствующий дескриптор для каждого профиля, а дескриптор передаёт учётные данные открытым текстом. Помощник — это отдельный двоичный файл, обычно в /usr/sbin/openvpn3-autoload, а не флаг session-start. Его настройка означает создание каталога, копирование профиля под именем, которого ждёт дескриптор, и запись дескриптора.

Настройка для одного пользователя выглядит так и выполняется от учётной записи, которая будет владеть сеансом. Режим каталога не пускает других локальных пользователей:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Дескриптор называет учётные данные и запрашивает автоматический запуск. Держите значение пароля вне системы контроля версий:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Затем вызовите помощник один раз и убедитесь, что сеанс появился. Вторая команда — это проверка, а не ещё один шаг настройки:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

При загрузке упакованный модуль с именем openvpn3-autoload.service использует общесистемный каталог /etc/openvpn3/autoload, а не каталог для отдельного пользователя. Этому месту нужны права root и более строгий режим, а дескриптор по-прежнему хранит пароль открытым текстом. Компромисс очевиден: пароль теперь лежит на диске, поэтому относитесь к этому каталогу как к секрету, исключите его из резервных копий за пределами хоста и выбирайте интерактивный путь всякий раз, когда рядом есть человек.

Отказы шины, которые выглядят как отказы пароля

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

Приведённые ниже команды разделяют эти две вещи. Первая сообщает, запущен ли бэкенд; вторая показывает недавние ошибки шины:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

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

Когда старый клиент всё ещё используется

Клиент 2.x по-прежнему принимает файл учётных данных, а связка ключей может ответить на его запрос, ни разу не допустив секрет на диск. Обёртка разрешает запись, поэтому файл называет поиск, а не пароль. Такая схема зависит от разблокированной связки ключей, которую не может предоставить контейнер без сеанса входа или модуль, запускающийся до чьего-либо входа. Тогда инструмент поиска сообщает о коллекции, в которую не может писать, и ошибка выглядит как отказ учётных данных, хотя это отказ связки ключей.

Прежде чем что-либо из этого строить, проверьте, не снимает ли параметр keepalive в профиле необходимость перезапуска вообще. Сеанс, который остаётся поднятым, никогда не доходит до запроса, который вы пытаетесь автоматизировать.