Бұл мақаланың соңғы бөлігі, міне, басы
Өткен жолы мен құрылғыны бақылауды қалай жүзеге асырғаным туралы жазған едім, енді басқару туралы сөйлесетін боламыз. Тапсырыс берушінің «техникалық мамандарымен» пікірталас кезінде мен мұндай шағын құрылғылардың мүмкіндіктерін (жад ресурстары мен өнімділігі төмен) шектеулі қабылдауды жиі кездестіремін, көбісі «бізге ең қажет нәрсе - қайта жүктеуді жіберу» деп санайды. Біз команда жібереміз ».
Бірақ тәжірибе көрсеткендей, бұл мүлдем дұрыс емес. Мұнда жалпы типтік тапсырмалардың шағын тізімі берілген:
- Желіні диагностикалау және ақаулықтарды жою. Маршрутизатордың Ethernet портының артында әдетте өзінің ішкі IP мекенжайы бар аппараттық құралдың басқа бөлігі болады. Кейде сіз оны «пинг» жасай аласыз (керек). Немесе туннельді басқару - егер туннель 3G модемі арқылы жұмыс істейтін маршрутизаторда кенеттен көтерілмесе, бірақ біз маршрутизатордың өзін көре аламыз.
- Жүйеге техникалық қызмет көрсету. Микробағдарламаны жаңарту, қызмет сценарийін жаңарту.
- Теңдестіру әрекеті. Мұны «бұзушылық» деп атауға болады, бірақ «теңдік» түсінігі, мен келтіремін, «цирк әртісі дененің тұрақсыз күйінде тепе-теңдікті сақтау қабілеті» - жақсырақ сәйкес келеді. Мұндай жағдайлар тұтынушының шектеулі бюджетіне байланысты туындайды. Төменде мен бірнеше мысал келтірдім, бірақ ... Олар әңгіменің тақырыбына тікелей қатысы жоқ, мен оларды конспектіге түсірдім
Wi-Fi мониторингіСоңғы бес жылдағы сәнді тақырып, негізінен федералды сауда желілері арасында. Сіз сауда алаңдарында жайбарақат серуендеп жатырсыз және Wi-Fi қосылған ұялы телефоныңыз желінің қандай да бір ағынына «жабысу» әрекеті үшін есептеу үшін талдауға болатын Probe Request пакеттерін жүйелі түрде жібереді. сіз: бұл дүкенге қаншалықты жиі келесіз, қандай себептермен? траекториялар бойынша жүресіз және т.б. Содан кейін деректер жиналады, талданады, жылу карталары сызылады және менеджерлер мұндай суреттер үшін басшылықтан немесе инвесторлардан ақша «қорқытады». Ал, әзірше.... «ақша жоқ, бірақ сен ұстайсың...», және нәтиже (нақты) қазірдің өзінде көрсетілуі керек, ескі жақсы ән басталады: «Иә, иә, онда әрине біз cis және сіз қалағанның бәрін орнатады, бірақ қазір біз Тұтынушыға нәтижені көрсетуіміз керек! Айтпақшы, біз Тұтынушының Wi-Fi арқылы жабдықты өзінің хотспотына қосуға рұқсат бергенін айтуды ұмытып кеттік, бірақ жалпы негізде, біз қонақ клиент болғандай». Сонымен, біз теңдестіретін маршрутизаторларды жасауымыз керек - бірнеше WiFi ішкі интерфейстері көтеріледі, олардың біреуі хотспотқа жабысады, ал екіншісі қоршаған ортаны бақылайды, tcpdump нәтижесін ашулы түрде өзіне жүктейді, содан кейін файлдың мазмұнын мұрағатқа жинайды және қауіп төндіреді. «артық тамақтанудан» өлу FTP серверіндегі мазмұнды түкіруге тырысады. Баланстаушы маршрутизатор жиі «бұзылады» және қандай да бір жолмен қашықтан «реанимацияға» тура келетіні таңқаларлық емес.
радиусТапсырыс берушінің келесі мәлімдемесі арқылы жағдайды сипаттау оңайырақ: «Біз моделі алдын ала белгілі емес арналар арқылы жабдықта жұмыс істейтін орталықтандырылмаған нүктелер желісін қалаймыз, бірақ қайсысы біз әлі белгісіз. О, біз айтуды ұмытып кеттік, біз клиенттерге жарнаманы көрсетуді ғана емес, сонымен қатар хотспот орнатылған жердің айналасындағы барлық нәрсені талдаймыз. Жоқ, біз неге екенін әлі білмейміз, бірақ біз оны анықтаймыз, күмәнданбаңыз, біз бұл идеяны жасай алдық ».
Бұған дейін белгісіз көптеген жағдайларға байланысты бақылауды стандартты емес жағдайларда жүргізу керек екенін ұмытпауымыз керек, біз маршрутизаторға IP: порты арқылы тікелей қосыла алмай, одан әрекетті күтуге мәжбүр боламыз. Егер біз өзімізді абстракциялайтын болсақ, сервер мен маршрутизатор арасындағы диалогты келесідей көрсетуге болады:
- Маршрутизатор: Сәлеметсіз бе. Мен анау-мынау маршрутизатормын, маған тапсырмалар бар ма?
- Сервер: роутер осындай және осындай, мен сізді тіркедім, сіздің тірі екеніңізді. Міне, мәселе: маған ifconfig пәрменінің нәтижесін көрсету керек пе?
- Маршрутизатор: Сәлеметсіз бе. Мен мынандай маршрутизатормын, сіз соңғы рет ifconfig нәтижесін көрсетуді сұрадыңыз, міне. Маған тапсырмалар бар ма?
- Сервер: роутер осындай және осындай, мен сізді тіркедім, сіздің тірі екеніңізді. Сізге тапсырма жоқ.
Ең қызықты сұрақ: қашықтағы маршрутизатор ақпараттың белгілі бір көлемін қалай жібере алады? Соңғы бөлімде мен шектеулі ресурстарға байланысты маршрутизаторда тек GET арқылы ғана жұмыс істейтін және басқа ештеңе жоқ «жұмсартылған» wget бар екенін сипаттадым; FTP клиенті немесе бұралу жоқ. Дәлірек айтқанда, кескінді құрастыру ерекшеліктеріне қарамастан бізге әмбебап әдіс қажет. Мен wget пайдалануды шештім. Дәлірек айтқанда, мен қалай «тоқтадым» - менің таңдауым болмады :)
Тек бас тартуМенің басқару шешімім жұмыс істейді, өте шектеулі емес және ол менің тұтынушыларымның көпшілігіне сәйкес келсе де, қисық екеніне сенімдімін. Мұны қалай ақылмен жасауға болады - 80 порт арқылы POST екілік деректерін жіберетін шағын утилита жазыңыз. Оны (утилитаны) маршрутизатордың микробағдарламасына қосыңыз және оған bash арқылы қол жеткізіңіз. Бірақ шындық мынада: а) бізге тез әрекет ету керек б) бізге бар «маршрутизаторлар зоопаркінде» бәрін жасау керек б) «зиян келтірме!» — маршрутизатор жұмыс істеп тұрса және басқа тапсырмаларды орындаса, бар функционалдылыққа әсер етпейтін өзгерістер енгізуге тырысыңыз.
Енді іске асыруға көшейік. Сіздің тұтынушы маршрутизаторды «тінтуірді басу» арқылы оңай және табиғи түрде zabbix жүйесінен қайта жүктегісі келеді делік. Бүгін біз Zabbix көмегімен іске асыруды сипаттай бастаймыз.
«Басқару» -> «Сценарийлер» мәзірінде жаңа сценарий қосыңыз. Біз оны «Қайта жүктеу» деп атаймыз, пәрмен ретінде «php /usr/share/zabbix/reboot.php {HOST.HOST}» енгізіңіз.
Келесі: «Мониторинг» мәзірі -> «Соңғы деректер» -> «Қажетті желі түйінін тінтуірдің оң жақ түймешігімен басыңыз. Сценарийді қосқаннан кейін мәзір осылай көрінеді.
Сәйкесінше, reboot.php сценарийін /usr/share/zabbix каталогына қоямыз (сіздікі басқаша болуы мүмкін, мен zabbixa түбірлік каталогын қолданамын).
Қауіпсіздіктен бас тартуСценарийде түсініктемені анық ету үшін мен тек маршрутизатор идентификаторын пайдаланамын, бірақ құпия сөзді пайдаланбаймын. Өндірістік нұсқада мұны істеу ұсынылмайды! Неліктен мен мұны істедім: себебі маршрутизаторлар үшін құпия сөздерді қайда сақтау керек деген үлкен сұрақ? «Түгендеу деректерінде» zabbixe өзі? Даулы тәжірибе. Немесе: reboot.php файлының өзіне сыртқы қатынасты шектеңіз
reboot.php файлы
<?php
// присваиваем параметры с консоли переменным
$user = $argv[1];
// ВНИМАНИЕ. Вот здесь в целях безопасности все-таки прописывать пароль устройства! Но для демонстрации мы будем обращаться к базе данных без использования пароля.
//$password = $argv[2];
$conn=new mysqli("localhost","db_user","db_password","db_name");
if (mysqli_connect_errno()) {
exit();
}
$conn->set_charset("utf8");
// "Отправляем" команду reboot за счет изменения поля task таблицы users. В поле task можно отправлять любую команду.
$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
$sql_users->bind_param('s', $user);
$sql_users->execute();
$sql_users->close();
?>Бар болғаны. Сұрақ ашық қалады: «құрылғыдан пәрменді орындау нәтижесін қалай алуға болады». Мысал ретінде ifconfig пәрменін қолданып тапсырманы қарастырайық. Бұл пәрменді құрылғыға жіберуге болады:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, мұнда:
message=`ifconfig` — ifconfig пәрменінің нәтижесін $message айнымалысына тағайындаймыз
wget " — маршрутизаторларды тіркейтін және олардан хабарламаларды қабылдайтын біздің a.php сценарийі
u=user&p=password!&m=$message — тіркелгі деректері және сұрау айнымалысының мәні m — $message айнымалысының мазмұнын тағайындайды
-O /tmp/out.txt — бұл жағдайда бізге /tmp/out.txt файлына шығару қажет емес, бірақ бұл параметр көрсетілмесе, wget жұмыс істемейді
Неліктен бұл жұмыс істемейді?Өйткені бұл әлеуетті қауіпсіздік тесігі. Ең зиянсыз қате, мысалы, пәрменіңіздің шығысында «&» таңбасы болса, орын алуы мүмкін. Сондықтан маршрутизаторлардан жіберілетіндердің барлығын да, серверге келетіндердің барлығын сүзгілеу қажет. Иә, мен ұялдым, шынымен. Мен өзімді қорғау үшін бүкіл мақала алдын ала анықталған микробағдарлама және алдын ала анықталмаған байланыс арналары бар маршрутизаторларды қалай басқаруға арналғанын ғана жаза аламын.
Ал, болашақтың бастамасы: серверге келетін нәтижелерді (мысалы, пәрменді орындау нәтижесі) көрсету үшін стандартты zabbix құралдарын қалай пайдалану керектігін әлі түсінген жоқпын.
Барлық дереккөздерді Git репозиторийінен мына мекенжайдан алуға болатынын еске саламын:
Ақпарат көзі: www.habr.com