Лише один клієнт керування: чому ваш монітор вибиває графічний інтерфейс
Керівний сокет приймає одне з'єднання за раз. Другий підписник або не може підключитися, або відбирає керування у компонента, якому належать запити.
Настільний графічний інтерфейс тримає керівне з'єднання, тож скрипт моніторингу, який намагається відкрити власне, нічого не читає або, що гірше, інтерфейс перестає відповідати на запити. Звичний висновок — демон нестабільний. У громадському демоні обмеження навмисне: інтерфейс керування обслуговує одного підключеного клієнта керування за раз, і це число ніяк не пов'язане з тим, скільки користувачів здатен витримати VPN.
Один сокет, один власник
Канал керування приймає одного підключеного клієнта. Коли другий приходить, поки перший активний, він чекає або отримує відмову, і жодного паралельного режиму підписника, схованого за опцією, немає. Від'єднання поточного власника дозволяє демону прийняти наступного, і це передача, а не другий канал.
Так кожен додатковий інструмент стає конкурентом. Якщо з'єднанням володіє інтерфейс, скрипт опитування або не підключається, або досягає цього лише після того, як інтерфейс здався, і послідовність повторюється під час наступного перепідключення. Якщо скрипт підключиться першим, інтерфейс втрачає свій шлях керування і його запити перестають працювати. Жоден з інструментів не повідомляє про конфлікт, бо кожен бачить лише свою невдалу команду.
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
Вирішіть, який компонент володіє керуванням
Виберіть одного власника інтерактивного каналу і зробіть його єдиним, хто підключається. Інтерфейс, що керує з'єднанням, скрипт, який відповідає на запити автентифікації, і контролер, що завершує сеанси, усі вважаються власниками, і лише один може обіймати цю роль.
Коли інтерфейс володіє з'єднанням, використовуйте інтеграцію, яку він надає, замість боротьби з ним. Гонка з власником за сокет породжує періодичні збої, які користувачам здаються випадковими, а той, хто зневаджує, зазвичай бачить лише другу половину гонки. Запишіть, який процес підключається першим після перезавантаження, бо цей порядок щоразу вирішує, хто переможе. Монітор, запущений раніше за інтерфейс, утримає канал, доки інтерфейс не здасться.
Використовуйте знімки стану для збирачів
Більшості завдань моніторингу потрібен список, а не розмова. Періодичний файл стану відповідає на це, не торкаючись каналу керування, і продовжує працювати, поки інтерфейс залишається підключеним.
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixІнтервал — це бюджет свіжості, тому задайте його за тим, що панелі справді потрібно, а не за найменшим значенням, яке видається безпечним. Знімок, що записується кожні кілька секунд, дешевий; скрипт, який кожні кілька секунд заново підключається до керівного сокета, — ні, бо кожне перепідключення конкурує з власником.
Знімок — це не історія і не потік подій. З'єднання, які приходять і йдуть у межах одного інтервалу, ніколи не з'являються, тому вимогу аудиту не можна виконати, опитуючи файл, що переписує сам себе. Якщо вам потрібно знати, чи підключався користувач узагалі, знімок — неправильний інструмент.
Роздача — це проєкт, а не режим
Якщо кільком споживачам справді потрібні дані керування в реальному часі, поставте перед сокетом один довірений компонент і дозвольте йому публікувати ретельно відібрані спостереження для решти. Цей компонент володіє перепідключенням, запитами автентифікації та рішенням про те, що безпечно розкривати.
Будуйте його усвідомлено: визначте, які запити дозволені, записуйте, хто запитував, і не допускайте, щоб шар роздачі випадково перетворився на пульт дистанційного керування. Демон не має багатоклієнтного режиму, який можна ввімкнути, і жоден рядок конфігурації його не створює. Ставтеся до власника як до частини межі безпеки, бо він тримає інтерфейс, здатний відключати людей. Його перезапуск має бути рутинною операцією з документованим шляхом відновлення.
Ставтеся до сокета як до привілею, а не як до метрик
Інтерфейс керування може відключати користувачів, змінювати стан і читати події, у яких названо людей. Його пароль автентифікує клієнта і не шифрує транспорт, тому мережевий слухач розкриває розмову кожному, хто може її спостерігати.
Надавайте перевагу локальному сокету або суворо обмеженому слухачу і перевіряйте, до якого процесу насправді звертається ваш збирач, оскільки серверні продукти постачають власні API керування, які поводяться інакше. Збирач, скерований на не той демон, дає впевнені й хибні висновки. Підтвердьте шлях і процес-власник, перш ніж зневаджувати запит, який нічого не повертає.