Управляващ сокет на OpenVPN: контролен канал, а не метрики

Попитайте интерфейса за управление за статус веднъж и той започва да изглежда като порт за статус. Но не е такъв. Щом бъде допуснат клиент, той може да издава управляващите команди на протокола, а акаунтът, който стартира този клиент, наследява всичко, което тези команди могат да направят с демона. Да го третирате като поток само за четене е грешката, която превръща една интеграция за мониторинг в конзола без удостоверяване.

Убеждението и какво струва

Убеждението е, че слушателят за управление е равнозначен на крайна точка за метрики: свържете колектор, прочетете броячите и продължете. Всъщност колекторът отваря сесия с възможности за управление и всяко друго допускане, което сте направили за внедряването, сега зависи от това колекторът да се държи добре.

Нищо в интерфейса не обявява режим само за четене. Няма роля на наблюдател, която да изберете, а потребителско име в конфигурацията не създава такава.

Какво всъщност притежава допуснатият клиент

Демонът на общността приема само един активен клиент за управление наведнъж. Този единствен слот означава, че графичен интерфейс, скрипт и агент за мониторинг не могат да се свържат едновременно; вторият чака или се проваля, докато първият държи сесията. Ако проектът ви предполага паралелни читатели, той вече е грешен.

Когато е достатъчна периодична снимка, изходът във файл за състоянието ви дава същите числа без жива сесия. Записването на този файл на интервали и четенето му с обикновени файлови разрешения държи колектора напълно извън контролната равнина и това е организацията, която повечето системи за мониторинг всъщност имат нужда.

Собствен сокет, а не отворен

Сокет в домейна Unix държи пътя за управление извън мрежата, което премахва от проблема променливия адрес на тунела. Но не премахва въпроса за разрешенията. Родителската директория трябва да е достъпна за запис от сервизния акаунт и достъпна от акаунта на контролера, а това са две отделни разрешения:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

Файлът с парола носи тайната за управление на първия си ред. Защитете този файл като всяко друго удостоверение и дръжте съдържанието му далеч от журнали и заявки за поддръжка. Ограниченията за потребител и група са проверки на партньора върху сокета Unix, а не файлови разрешения, затова предвиденият процес се нуждае както от достъп до файла, така и от съответната идентичност.

Направата на сокета достъпен за целия свят, за да се изчисти грешка с разрешенията, е единствената поправка, която трябва да избягвате. Тя превръща един локален контролен канал в нещо, което всеки процес на хоста може да управлява.

Публикуването му през TCP не е същият дизайн

Преместването на слушателя на TCP порт не го прави по-безопасен или по-удобен. Паролата за управление се изпраща в открит вид, така че TCP слушателят излага както удостоверението, така и сесията на всеки, който може да наблюдава пътя. Достъпът до него от друг хост изисква оторизиран канал за администриране или малък локален агент, който показва само наблюденията, от които се нуждаете.

Парола върху предаване в открит текст е удостоверяване без поверителност и тази комбинация е по-лоша, отколкото изглежда, защото се усеща като защитена.

Зависимости при стартиране, които не сте искали

Няколко опции за управление променят жизнения цикъл на демона. Задържането на стартирането, докато се свърже контролер, или прекратяването, когато контролерът изчезне, превръща един незадължителен наблюдател в твърда зависимост. Тогава агент за мониторинг, който се срине, ще свали тунела заедно със себе си.

Прегледайте тези опции, преди да включите нещо извън самия сокет. Незадължителното наблюдение трябва да остане незадължително, а политиката за рестартиране не бива да се обвързва с колектор, добавен заради графики.

Файл на сокет, оставен след неуспешен процес, не е доказателство, че съществува слушател. Установете кой екземпляр притежава пътя, преди да го премахнете, и използвайте собствения работен процес за възстановяване на услугата, вместо да триете файлове под работещ демон.

Как изглежда приемането

Четири проверки покриват дизайна: предвидената идентичност на контролера се свързва, процес без тази идентичност се отхвърля, демонът оцелява след контролер, който се разпада без предупреждение, и тунелът все още пренася трафик през контролиран рестарт. Успешна връзка за управление доказва само контролната равнина. Тя не казва нищо за това дали работи трафикът на частните приложения, затова тествайте го отделно. Запишете четирите резултата там, където следващият оператор може да ги намери.

Документацията за интерфейса за управление описва модела с един клиент и привилегирования характер на протокола и това е частта, която си струва да се прочете, преди да насочите табло към него.