openvpn3 session-start игнорира файла с идентификационни данни

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

Защо запазеният файл няма къде да отиде

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

Старият модел си заслужава да бъде назован, за да е по-лесно да се отучи: профилът сочи файл с идентификационни данни и демонът го чете при стартиране на тунела. В новия модел идентификационните данни принадлежат на сесия и се подават, когато тази сесия започне. 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 в профила не премахва нуждата от рестартиране изобщо. Сесия, която остава вдигната, никога не стига до подканата, която се опитвате да автоматизирате.