В , я розповів про передісторію створення Veliam і про рішення його розповсюдження за системою SaaS. У цій статті, я розповім про те, що довелося зробити, щоб продукт став не локальним, а публічним. Про те, як починали поширення та з якими проблемами зіткнулися.
планування
Поточна серверна частина користувачів була на Linux. Майже в кожній організації є сервери Windows, чого не можна сказати про Linux. Основна сильна сторона Veliam – віддалені підключення до серверів та мережного обладнання за NAT. Але цей функціонал був дуже жорстко пов'язаний з тим, що маршрутизатором мав бути обов'язково мікротик. І це явно багатьох не задовольняло б. Я спочатку почав думати про те, щоб додати підтримку маршрутизаторів найпоширеніших вендорів. Але я розумів, що це нескінченна гонка із розширенням списку підтримуваних фірм. Більше того, так і ті, що вже підтримуються, можуть від моделі до моделі мати різний набір команд зміни правил NAT. Єдиним виходом із ситуації бачився VPN.
Оскільки ми вирішили поширювати продукт, але не як open source, то й включати до свого складу різні бібліотеки з відкритими ліцензіями типу GPL не можна було. Це взагалі окрема тема після прийняття рішення про продаж продукту довелося перебрати половину бібліотек через те, що вони були GPL. Коли писали під себе, то це було нормально. Але поширення не підходить. Перший же VPN який спадає на думку — OpenVPN. Але він є GPL. Ще був варіант використовувати японський SoftEther VPN. Його ліцензія дозволяла включити його до складу свого продукту. Після декількох днів різних тестів як інтегрувати його таким чином, щоб користувачеві взагалі нічого не потрібно було налаштовувати і знати про SoftEther VPN - вийшов прототип. Все було як слід. Але чомусь нас ця схема все одно бентежила, і ми від неї відмовилися. Але природно відмовилися після того, як придумали інший варіант. У результаті все зробили на стандартних TCP з'єднаннях. Частина підключень працює через координатор, частина безпосередньо через технологію Nat Hole Punching (NHP), яка також реалізовувалась на Free Pascal. Потрібно сказати, що про NHP я раніше взагалі навіть не чув. І на думку не могло спасти, що можна зв'язати 2 мережні пристрої, обидва з яких знаходяться за NAT безпосередньо. Простудив тему, зрозумів принцип роботи і сів писати. Задумане здійснено, користувач підключається одним кліком до потрібного пристрою за NAT RDP, SSH або Winbox без введення паролів і налаштування VPN. Причому більша частина цих підключень йде повз наш координатор, що добре позначається на пінгу і собівартості обслуговування цих підключень.
Переклад серверної частини з Linux на Windows
Проблем під час переходу на Windows було відразу кілька. Перша - вбудований wmic у windows не дозволяє робити WQL запити. А в нашій системі вже все було збудовано на них. І було ще щось, але зараз забув чому остаточно відмовилися від його використання. Можливо, різницю між версіями Windows. І друга проблема – багатопоточність. Не знайшовши хорошої сторонньої утиліти під “припустимою” ліцензією, я знову запустив IDE Lazarus. І написав необхідну утиліту. На вхід подається потрібний список об'єктів та які саме запити треба робити, а у відповідь отримую дані. І все це у багатопотоковому режимі. Чудово.
Після того як налаштував pthreads для PHP Windows думав, що все прямо запуститься, але не тут-то було. Через деякий час налагодження, я зрозумів, що pthreads начебто працює, але саме в нашій системі не працював. Стало зрозуміло, що є якась особливість роботи з pthreads в Windows. Так воно й було. Прочитав документацію, і там було написано, що для Windows кількість потоків обмежена, причому, як я пам'ятаю неявно. Це стало проблемою. Тому що, коли я почав скорочувати кількість потоків, при яких програма працювала, вона робила роботу дуже повільно. Знову відкрив IDE і в ту ж утиліту був доданий функціонал багатопоточного пропінгування об'єктів. Ну і до купи вже й сканування портів туди. Власне, після цього, необхідність у pthreads для PHP зникла, і він більше не використовується. Далі до цієї утиліти було додано ще кілька функціоналів і працює вона до цього дня. Після цього був зібраний інсталятор для Windows, який включав Apache, PHP, MariaDB, саме PHP додаток і набір утиліт для взаємодії з системою, написаних на Free Pascal. Що ж до установника, то думав, що це питання швидко вирішу, т.к. це понад поширена та потрібна майже для кожного софту річ. Чи то я не так шукав, чи ще щось. Але мені траплялися постійно продукти, які були недостатньо гнучкі, або дорогі і при цьому теж негнучкі. І все ж таки я знайшов безкоштовний установник, в якому можна буде передбачити будь-які хотілки. Це InnoSetup. Пишу тут про це, бо мені довелося пошукати, раптом я комусь заощаджу час.
Відмова від плагіна на користь свого клієнта
Я раніше писав, що клієнтською частиною був браузер із «плагіном». Так ось були такі часи, коли Chrome оновиться і верстка трохи кривиться, то Windows оновиться і custom uri scheme злітають. Дуже не хотілося мати такого роду сюрпризи у громадській версії товару. Причому custom uri почали злітати після кожного оновлення Windows. Microsoft просто видаляла всі її гілки в потрібному розділі. Також Google Chrome тепер не дозволяє запам'ятати вибір відкривати чи ні програму з custom uri, і ставить це питання при кожному натисканні на об'єкт моніторингу. Ну і в цілому, потрібна була нормальна взаємодія з локальною системою користувача, чого браузер не дає. Найпростіший варіант у такій схемі бачиться просто зробити свій браузер, як багато хто зараз робить через Electron. Але вже багато речей було написано на Free Pascal, у тому числі в серверній частині, тому вирішили і клієнт зробити тією ж мовою, а не плодити зоопарк. Так було написано клієнта з Chromium на борту. Після цього він почав обростати різними обв'язками.
реліз
Нарешті вибрали назву системи. Ми постійно перебирали різні варіанти, поки йшов процес переробки з локальної версії в SaaS. Оскільки ми спочатку планували вихід як на внутрішній ринок, то основним критерієм підбору назви було наявність незайнятого, або дуже дорогого домену у зоні “.com”. Деякі функції/модулі ще не були портовані з локальної версії до Veliam, але ми вирішили, що будемо випускати з поточним функціоналом, а решту робити вже у вигляді оновлень. У першій версії не було HelpDesk'а, Veliam Connector'а, не можна було змінювати пороги спрацьовування тригерів повідомлень і багато іншого. Купили Code Sign Certificate, підписали клієнтську та серверну частини. Написали сайт для продукту, розпочали процедури реєстрації програмного забезпечення, товарного знаку тощо. Загалом, готові починати. Легка ейфорія від виконаної роботи і від того, що можливо твоїм продуктом хтось користуватиметься, хоча з цього приводу у нас не було сумнівів. І тут стоп. Партнер сказав, що без повідомлень у месенджери виходити на ринок не можна. Можна багато чого іншого, але не без цього. Після нетривалих суперечок, було додано інтеграцію з Telegram, яка нас влаштувала. З усіх поточних месенджерів це єдиний, який дає доступ до своїх API безкоштовно і без якихось складних процедур погоджень. Той самий WhatsApp пропонує звертатися до провайдерів, які беруть непогані гроші за користування їхніми послугами, всі листи з проханням надати доступ без прокладок були проігноровані. Ну а вайбер ... Я не знаю хто ним користується зараз, т.к. спам та реклама там зашкалюють. Наприкінці грудня, після низки внутрішніх тестувань та тестувань серед друзів, відкрили реєстрацію для всіх та виклали софт для скачування.
Початок поширення
З самого початку ми розуміли, що нам потрібен невеликий потік користувачів системи для того, щоб вони вже в бойовому режимі протестували продукт і дали перший фідбек. Декілька куплених постів у ВК дали плоди. Пішли перші реєстрації.
Тут треба сказати, що виходити на ринок, коли твоя компанія не має знаменитого імені, і при цьому надавати функціонал безагентного моніторингу, в який потрібно вводити облікові записи від своїх серверів і робочих станцій, дуже непросто. Дуже багато людей це лякає. Ми з самого початку розуміли, що з цим будуть проблеми і були готові до цього технічно і морально. Всі віддалені підключення, незважаючи на те, що RDP і SSH шифруються за замовчуванням, додатково шифруються нашим софтом за стандартом AES. Всі дані з локальних серверів передаються в хмару HTTPS. Облікові записи зберігаються у зашифрованому вигляді. Ключі шифрування всіх підсистем у всіх клієнтів індивідуальні. Для віддалених підключень використовуються сеансові ключі шифрування.
Все, що ми можемо робити в цій ситуації, щоб людям було спокійніше — це бути максимально відкритими, працювати над безпекою і не втомлюватися відповідати людям на питання, що їх хвилюють.
Для багатьох, зручність та функціонал софту переважують страх, і вони реєструються. Деякі особи в опублікованих постах у ВК писали, що це використання не можна т.к. це збирання їхніх паролів і взагалі ноунейм компанія. Треба сказати, що така думка не була в однієї людини. Багато хто просто не розуміє, що коли вони ставлять до себе інший пропрієтарний софт на сервер, який працює як служба, так само має повні права в системі і їм не потрібні обліки для того, щоб робити щось протиправне (зрозуміло, що можна змінити користувача від якого запускається служба, але так і тут, можна вводити обліковий запис будь-яку). Насправді побоювання людей зрозумілі. Встановлення софту на сервер - це справа звична, а ось введення облікового запису - це вже трохи страшно і інтимно, так як у доброї половини людей один пароль на всі сервіси, а робити окремий облік навіть для тесту ліниво. Але на даний момент є безліч сервісів, яким люди довіряють свої облікові дані і не тільки. І ми прагнемо стати одними з них.
Чимало коментарів було такого плану, що ми десь це вкрали. Нас це трохи здивувало. Ну гаразд думка однієї людини, але такі коментарі зустрічалися в різних публікаціях від різних людей. Не знали спочатку, як на це реагувати. Чи то сумувати про те, що в деяких людей думка, що в Росії ніхто нічого не може зробити сам, а може тільки вкрасти, то радіти, що вважають, що таке можна тільки вкрасти.
Наразі ми завершили процедуру отримання EV Code Sign Certificate. Для його отримання необхідно пройти низку перевірок та надіслати купу документів про компанію, частину з яких слід завірити адвокатом. Отримання сертифіката EV Code Sign в умовах пандемії – це взагалі окрема тема для статті. Процедура тривала на місяць. І це був місяць не очікування, а постійних запитів на додаткові документи. Може пандемія тут ні до чого, і у всіх процедура проходила так довго? Поділіться.
Дехто каже, що не користуватимемося тому, що немає сертифікату ФСТЕК. Доводиться пояснювати, що ми не можемо його отримати і не будемо тому, що для отримання цього сертифіката — шифрування має бути за ГОСТ, а ми плануємо розповсюдження ПЗ не тільки в Росії та використовуємо AES.
Всі ці коментарі навіювали деяку невпевненість у тому, що це можливо — просувати продукт, у який потрібно вводити облікові записи, не будучи при цьому на слуху. Навіть з огляду на те, що ми знали, що будуть ті, хто дуже негативно ставиться до цього. Після того, як кількість реєстрацій перевалила за тисячу, ми перестали про це думати. Особливо після того, як крім негативу тих, хто навіть не пробував продукт, почали з'являтися і дуже приємні відгуки. Треба сказати, що ці позитивні відгуки є найбільшим мотиватором до розвитку продукту.
Додавання функціоналу віддаленого доступу для працівників
Одне з найчастіших завдань від клієнтів є «зробіть Вані доступ до його комп'ютера з дому». Піднімали VPN на мікротик та робили для користувачів обліки. Але це реально проблема. Користувачі не в змозі дивитися інструкцію і зробити її кроками, щоб підключитися по VPN. Різні версії Windows. В одній вінді все добре підключається, в іншій потрібен інший протокол. І загалом це завжди було пов'язане з переналаштуванням мережного обладнання, яке виступало сервером VPN, а не у всіх співробітників є до нього доступ і це було незручно.
Але ж у нас вже є віддалені підключення до серверів та мережного обладнання. Чому б не скористатися готовим транспортом і зробити окрему утиліту маленького розміру, яку можна просто дати користувачеві для підключення. Хотілося тільки зробити так, щоб користувач там нічого не вводив хитромудрого. Просто одна кнопка "підключитися". Але як ця утиліта буде розуміти, куди підключатися, якщо в ній тільки одна кнопка. Була ідея онлайн складання потрібної програми на наших серверах. Системний адміністратор натискає кнопку «завантажити ярлик», і до нас у хмару подається команда на складання індивідуального бінарника із зашитою інформацією щодо підключення до потрібного сервера/комп'ютера RDP. Загалом це можна було зробити. Але це довго, адміністратору довелося б чекати спочатку, поки бінарник скомпілюється, а потім і скачається. Можна було б звичайно додати просто другий файл з конфігом, але це вже 2 файли, а для простоти користувачеві потрібен один. Один файлик, одна кнопка та жодних установників. Почитавши трохи простори гугла, я дійшов висновку, що, якщо в кінець скомпілюваного ".exe" додати якусь інформацію, то він не псується (ну майже). Туди можна хоч війну та світ додати, і він працюватиме, як і раніше. Гріх цим не скористатися. Тепер можна просто на ходу прямо в самому клієнті розпаковувати програму, до речі вона називається Veliam Connector, і просто дописувати до неї потрібну для підключення інформацію. А вже сама програма знає, що з цим робити. Чому я трохи вище у дужках написав "ну майже"? Тому, що за цю зручність доводиться платити тим, що програма втрачає свій підпис ЕЦП. Але ми на даному етапі вважаємо, що це невелика ціна за таку зручність.
Ліцензії сторонніх модулів
Вище я вже писав, що після того, як було вирішено зробити продукт загальнодоступним, а не тільки для свого користування, довелося добряче попрацювати і пошукати заміни деяким модулям, які не дозволяли включати себе до складу нашого продукту. Але вже після релізу випадково виявилася дуже неприємна річ. У складі Veliam Server, який був на стороні клієнта, була СУБД MariaDB. І вона має ліцензію GPL. Ліцензія GPL передбачає, що софт має бути з відкритим вихідним кодом, і якщо до складу нашого продукту включена MariaDB, яка має цю ліцензію, то і наш продукт має бути під цією ліцензією. Але на щастя, ця ліцензія має на меті відкритий вихідний код, а не покарання в суді тих, хто випадково помилився. Якщо у правовласника з'являється претензія, він письмово повідомляє порушника і той повинен протягом 30 днів усунути порушення. Ми виявили свою помилку самі і листів не отримували і відразу почали розглядати варіанти, як вирішити проблему. Вихід виявився очевидним - перехід на SQLite. Ця БД не має жодних обмежень щодо ліцензування. Більшість сучасних браузерів використовує SQLite, та й купа інших програм. Знаходив в інтернеті інформацію, що SQLite вважається найпоширенішою СУБД у світі, саме через браузери, але не шукав пруфів, так що це неточна інформація. Почав вивчати, чим загрожує перехід на SQLite.
Це стає вже нетривіальним завданням, коли є кілька сотень встановлених у клієнтів серверів з MariaDB та даними в ній. Деякі фішки MariaDB недоступні у SQLite. Ну, наприклад, у коді використовували запити типу
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Дана конструкція робить не тільки вибірку з таблиці, а й блокує рядки. І ще кілька конструкцій також довелося переписувати. Але, крім того, що довелося переписувати багато запитів, так само довелося вигадувати механізм, який при оновленні Veliam Server у клієнта портує всі дані в нову СУБД і видалить стару. Також, не працювали транзакції SQLite і це було реальною проблемою. Але, почитавши простори всесвітньої павутини, я без проблем знайшов, що транзакції в SQLite можна включити, передавши при підключенні просту команду
PRAGMA journal_mode=WAL;У результаті завдання виконано, і тепер серверна частина у клієнтів працює на SQLite. Якихось змін у роботі системи ми не помітили.
Новий HelpDesk
З внутрішньої версії SaaS версію необхідно було портувати HelpDesk систему, але з деякими змінами. Перше, що хотілося зробити, - це інтеграція з доменом клієнта в частині прозорої авторизації користувачів в системі. Зараз користувач, щоб зайти в HelpDesk і залишити заявку в системі, просто натискає на ярлик на робочому столі і відкривається браузер. Користувач не вводить жодних облікових даних. Модуль для Apache SSPI, який входить до складу Veliam Server, автоматично авторизує користувача під доменним обліковим записом. Щоб залишити заявку в системі, коли користувач знаходиться за межами корпоративної мережі, він натискає кнопку, і йому на пошту приходить посилання, за яким він без паролів авторизується в системі HelpDesk. Якщо користувача вимкнути або видалити в домені, то обліковий запис HelpDesk теж перестане працювати. Таким чином, системному адміністратору не потрібно стежити за обліковими записами і в домені, і в HelpDesk. Звільнився співробітник - відключив обліковий запис у домені і все, він не зайде в систему не з корпоративної мережі, не за посиланням. Для роботи даної інтеграції системному адміністратору потрібно зробити одну GPO, яка и .
Друге, що вважаємо вкрай необхідним для систем HelpDesk, принаймні для нас самих – це підключення до заявника прямо із заявки в один клік. Більше того, підключення має відбуватися, якщо системний адміністратор знаходиться в іншій мережі. Для аутсорсу це обов'язково, для штатних системних адміністраторів теж дуже часто потрібно. Є вже кілька продуктів, які чудово справляються із завданням віддалених підключень. І ми вирішили зробити для них інтеграцію. Зараз ми зробили інтеграцію для VNC, а в майбутньому плануємо додати Radmin та TeamViewer. Використовуючи наш мережевий транспорт для віддалених підключень до інфраструктури, ми зробили так, що VNC підключається до віддалених робочих станцій NAT. Те саме буде і з Radmin. Зараз, щоб підключитися до користувача, потрібно просто в самій заявці натиснути кнопку "підключитися до заявника". Відкривається VNC клієнт і підключається до заявника незалежно від того в одній мережі або сидите вдома в тапочках. Попередньо, системний адміністратор, засобами ДПО має встановити всім на робочі станції VNC Server.
Зараз ми самі переходимо на новий HelpDesk та користуємось інтеграцією з доменом та VNC. Це дуже зручно для нас. Тепер ми можемо не платити за TeamViewer, яким ми користувалися понад три роки для роботи нашої служби підтримки.
Що плануємо робити далі
Коли ми випустили продукт, то не робили платних тарифів, а просто обмежили безкоштовний тариф 50 об'єктами моніторингу. П'ять десятків мережевих пристроїв та серверів має вистачити всім, подумали ми. І тут почали надходити запити збільшення ліміту. Сказати, що ми були трохи шоковані — нічого не сказати. Невже нашим софтом зацікавилися компанії, які мають таку кількість серверів. Ми безкоштовно розширювали ліміт для тих, хто робив такі запити. У деяких ми у відповідь на їх запит запитали навіщо їм стільки, невже в них така велика кількість серверів та обладнання. І виявилось, що системні адміністратори почали використовувати систему так, як ми взагалі не планували. Все виявилося просто – моніторити нашим софтом почали не лише сервери, а й робочі станції. Звідси багато запитів на розширення лімітів. Зараз ми вже запровадили платні тарифи та ліміти можна розширити самостійно.
Сервери майже завжди працюють або з СХД або з локальними дисками в RAID масиві. І ми спочатку робили продукт для них. І моніторинг SMART був нецікавий для цього завдання. Але з урахуванням того, що люди пристосували програму для моніторингу робочих станцій, з'явилися запити на реалізацію моніторингу SMART. Незабаром ми його реалізуємо.
З появою Veliam Connector стало непотрібним розгортання VPN сервера в корпоративній мережі, або робити RDGW, або просто прокидати порти до необхідних машин для підключення по RDP. Дуже багато хто користується нашою системою лише для цих віддалених підключень. Veliam Connector є лише під Windows, а деякі користувачі компаній підключаються з домашніх ноутбуків під керуванням MacOS до робочих станцій або терміналів у корпоративній мережі. І виходить, що системний адміністратор змушений через кілька користувачів все одно повертатися до питання прокидів або VPN. Тому ми вже закінчуємо робити версію Veliam Connector під MacOS. Користувачі своєї улюбленої яблучної техніки також отримають можливість в один клік підключатися до корпоративної інфраструктури.
Дуже подобається те, що, маючи велику кількість користувачів системи, не доводиться ламати голову, що людям потрібно і що буде зручніше. вони самі пишуть свої побажання, тому планів з розробки найближчим часом дуже багато.
Паралельно, плануємо зараз зайнятися перекладом системи англійською мовою та поширенням її зарубіжжя. Ми поки не знаємо, як поширюватимемо продукт поза нашою країною, шукаємо варіанти. Можливо, про це пізніше буде окрема стаття. Можливо хтось із тих, хто прочитав цю статтю, зможе підказати потрібний вектор, чи сам знає і вміє як це робити і запропонує свої послуги. Будемо вдячні за допомогу.
Джерело: habr.com