OpenVPN push-peer-info: позначати клієнтів, не надаючи доступу

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

Це керівництво для робочого шляху, кроку перевірки, який показує, що насправді надійшло, і відкату, який не залишає напівналаштованого гачка. Ніщо тут не потребує нового сертифіката, нового плагіна чи розширення протоколу.

Задайте змінну та ввімкніть шлях

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

setenv UV_DEPLOY field-support
push-peer-info

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

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

Прочитайте поле з гачка сервера

На боці сервера отримана інформація про вузол перевіряється та вставляється в середовище робочого процесу з’єднання, і саме це робить її доступною для читання з гачка без будь-якої вашої роботи з протоколом. Серверу не потрібно розбирати канал керування чи щось зберігати для вас; значення просто присутнє, поки встановлюється з’єднання. Мінімальний скрипт client-connect, який записує мітку поруч з автентифікованим ім’ям, виглядає так.

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

Читайте змінну через середовище, а не розбираючи журнал, і завжди давайте їй значення за замовчуванням. ${UV_DEPLOY:-unset} зберігає працездатність скрипта для клієнтів, які ніколи не надсилають поле, що є нормальним станом під час поетапного розгортання. Не виливайте все середовище в журнал, щоб знайти ім’я; там набагато більше, ніж мітка, включно зі значеннями, які ви не збиралися зберігати.

Запустіть скрипт вручну, і він повідомить unset для всього, бо ручна оболонка не несе середовище з’єднання. Це не помилка скрипта і не доказ того, що поле відсутнє. Перевірте його через реальне з’єднання — єдиний контекст, у якому змінна існує.

Перевірте, що насправді надійшло

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

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

Ці рядки коментарів — форма виводу, а не розшифровка з вашого сервера; читайте власний файл. Якщо другий клієнт теж показує значення, змінна встановлена десь інде в середовищі, і ви читаєте застаріле налаштування, а не поле вузла.

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

Ставтеся до мітки як до заяви, а не як до особи

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

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

Відкатіть чисто

Видалення функції — це два видалення і одна перевірка. Видаліть рядки setenv і push-peer-info з профілю клієнта, потім видаліть або вимкніть гачок і його ціль журналу на сервері.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

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

Наприкінці залишається невеликий, обмежений фрагмент метаданих сеансу з задокументованим походженням: клієнт заявляє його, сервер записує, і ніщо в доступі від нього не залежить. Це корисна версія функції, і для неї не потрібні нові облікові дані.