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