Только один клиент управления: почему ваш монитор выбивает графический интерфейс
Управляющий сокет принимает одно подключение за раз. Второй подписчик либо не может подключиться, либо отбирает управление у компонента, которому принадлежат запросы.
Настольный графический интерфейс держит управляющее подключение, поэтому скрипт мониторинга, пытающийся открыть своё, ничего не читает или, что хуже, интерфейс перестаёт отвечать на запросы. Обычный вывод — демон нестабилен. В общественном демоне ограничение намеренное: интерфейс управления обслуживает одного подключённого клиента управления за раз, и это число никак не связано с тем, сколько пользователей способен выдержать 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 управления, которые ведут себя иначе. Сборщик, направленный на не тот демон, даёт уверенные и неверные выводы. Подтвердите путь и процесс-владелец, прежде чем отлаживать запрос, который ничего не возвращает.