Ez a cikk utolsó része, itt a kezdet
Múltkor arról írtam, hogyan valósítottam meg az eszközfelügyeletet, most a menedzsmentről fogunk beszélni. Az Ügyfél oldalán a „technikusokkal” folytatott megbeszélések során gyakran találkozom az ilyen kis (alacsony memória-erőforrásokkal és teljesítménnyel rendelkező) eszközök képességeinek korlátozott felfogásával, sokan úgy gondolják, hogy „leginkább egy újraindításra van szükségünk valami többért. komolyan küldünk egy csapatot” .
De a gyakorlat azt mutatja, hogy ez nem teljesen igaz. Íme egy kis lista a gyakori tipikus feladatokról:
- Hálózati diagnosztika és hibaelhárítás. Az útválasztó Ethernet-portja mögött általában egy másik hardver található, amelynek saját belső IP-címe van. Néha lehet (kellene) „pingelni”. Vagy alagútkezelés – ha egy 3G modemen keresztül működő routeren hirtelen nem emelkedik ki az alagút, de magát a routert látjuk.
- Rendszerkarbantartás. Firmware frissítés, szervizszkript frissítés.
- Kiegyensúlyozó tevékenység. Ezt „perverziónak” lehetne nevezni, de az „ekvilibrista” fogalma, mint idézem, „egy cirkuszi előadó képessége az egyensúly megtartására instabil testhelyzetben” - jobban illeszkedik. Az ilyen helyzetek az ügyfél korlátozott költségvetése miatt merülnek fel. Az alábbiakban hoztam néhány példát, de... Közvetlenül nem kapcsolódnak a történet témájához, a jegyzetek közé tettem
Wi-Fi figyelésAz elmúlt öt év divatos témája, főleg a szövetségi kiskereskedelmi láncok körében. Nyugodtan sétálgatsz a kereskedési szinteken, és a bekapcsolt Wi-Fi-vel ellátott mobiltelefonod, hogy megpróbáljon „ragadni” a hálózat valamelyik szálához, rendszeresen Probe Request csomagokat küld, amelyek elemzésével kiszámítható te: milyen gyakran jössz ebbe az üzletbe, milyen indokkal?, pályákon sétálsz és így tovább. Ezután összegyűjtik, elemzik az adatokat, hőtérképeket készítenek, és a menedzserek pénzt „zsarolnak ki” a menedzsmenttől vagy a befektetőktől az ilyen képekért. Na, egyelőre.... „nincs pénz, de kapaszkodj...”, és az eredményt (igazi) már meg kell mutatni, indul a jó öreg dal: „Igen, igen, akkor persze mi telepíteni fogja a cis-t és mindent, amit akar, de most meg kell mutatnunk az eredményt az Ügyfélnek! Azt egyébként elfelejtettük mondani, hogy az Ügyfél megengedte, hogy Wi-Fi-n keresztül csatlakoztassuk a berendezéseinket a hotspotjához, de általánosságban úgy, mintha vendégkliensek lennénk.” És ezért kell kiegyenlítő útválasztókat készítenünk - több WiFi alinterfész is felkerül, amelyek közül az egyik a hotspothoz tapad, a másik pedig a környezetet figyeli, őrjöngve feltölti magához a tcpdump eredményt, majd a fájl tartalmát archívumba csomagolja és kockáztat. a „túlevéstől” meghalva megpróbálja kiköpni az FTP-szerveren lévő tartalmat. Nem meglepő, hogy a kiegyenlítő útválasztó gyakran „elromlik”, és valahogy távolról „újra kell éleszteni”.
SugárItt könnyebb leírni a helyzetet valami ilyesmivel az ügyféltől: „Szeretnénk egy decentralizált hotspot-hálózatot, amely olyan berendezéseken működne, amelyek modellje előre nem ismert, csatornákon keresztül, de melyeket még nem ismerünk. Ó, elfelejtettük mondani, nem csak reklámot akarunk megjeleníteni az ügyfeleknek, hanem mindent elemezni szeretnénk a hotspot telepítési helye körül. Nem, még nem tudjuk, miért, de majd kitaláljuk, ne kételkedjetek benne, sikerült kitalálni ezt az ötletet.”
És nem szabad elfelejteni, hogy sok eddig ismeretlen körülmény miatt a vezérlést nem szabványos körülmények között kell végrehajtani, amikor az IP: porton keresztül nem tudunk közvetlenül csatlakozni a routerhez, és kénytelenek vagyunk egyszerűen megvárni a tevékenységet. Ha elvonatkoztatjuk magunkat, a szerver és a router közötti párbeszéd a következőképpen ábrázolható:
- router: Helló. Én ilyen-olyan router vagyok, vannak nekem feladatok?
- Сервер: router ilyen-olyan, regisztráltalak, hogy élsz. Íme a kihívás: mutasd meg az ifconfig parancs eredményét?
- router: Helló. Én ilyen-olyan router vagyok, legutóbb az ifconfig eredményét kérted, itt van. Vannak számomra feladatok?
- Сервер: router ilyen-olyan, regisztráltalak, hogy élsz. Nincsenek számodra feladatok.
A legérdekesebb kérdés: hogyan tud egy távoli útválasztó bizonyos mennyiségű információt küldeni? Az utolsó részben leírtam, hogy a korlátozott erőforrások miatt a routernek csak egy „lecsupaszított” wgetje van, ami csak GET-en keresztül működik, semmi más, nincs FTP kliens vagy curl. Pontosabban egy univerzális módszerre van szükségünk, függetlenül a képösszeállítás jellemzőitől. Elfogadtam a wget használatát. Pontosabban, hogyan "álltam meg" - egyszerűen nem volt más választásom :)
Csak egy felelősségkizárásA felügyeleti megoldásom működik, nem nagyon korlátozott, és biztos vagyok benne, hogy ferde, még akkor is, ha a legtöbb ügyfelemnek megfelel. Hogyan tehetné ezt bölcsen - írjon egy kis segédprogramot, amely a 80-as porton keresztül küldi a POST bináris adatokat. Szerelje be (a segédprogramot) az útválasztó firmware-ébe, és érje el a bash segítségével. De a valóság az, hogy: a) gyorsan kell b) valószínűleg mindent meg kell tennünk a meglévő „routerek állatkertjén” c) „ne ártsunk!” — ha az útválasztó működik és más feladatokat is végrehajt, próbáljon meg olyan változtatásokat végrehajtani, amelyek nem befolyásolják a meglévő funkcionalitást.
Térjünk át a megvalósításra. Tegyük fel, hogy ügyfele egyszerűen és természetesen, „egérkattintással” szeretné újraindítani az útválasztót a zabbix-ról. Ma elkezdjük a megvalósítás leírását a Zabbixszel.
Az „Adminisztráció” -> „Szkriptek” menüben adjon hozzá egy új szkriptet. „Reboot”-nak hívjuk, parancsként írja be a „php /usr/share/zabbix/reboot.php {HOST.HOST}” parancsot.
Következő: „Monitoring” menü -> „Legfrissebb adatok” -> „Kattintson jobb gombbal a kívánt hálózati csomópontra.” Így fog kinézni a menü a szkript hozzáadása után.
Ennek megfelelően a /usr/share/zabbix könyvtárba tesszük a reboot.php szkriptet (a tiéd más lehet, én a zabbixa gyökérkönyvtárat használom).
Biztonsági felelősség kizárásaHogy érthetőbb legyen a magyarázat a szkriptben, csak a router azonosítóját használom, de a jelszót nem. Ezt a gyártási verzióban nem javasolt megtenni! Miért tettem ezt: mert a nagy kérdés az, hogy hol tároljam a routerek jelszavait? Magában a zabbixe-ban a „leltári adatokban”? Ellentmondásos gyakorlat. Alternatív megoldásként korlátozza a külső hozzáférést a reboot.php fájlhoz
Reboot.php fájl
<?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();
?>Ez minden. A kérdés továbbra is nyitva marad: „hogyan lehet elérni a parancs végrehajtásának eredményét az eszközről”. Nézzük meg a feladatot az ifconfig paranccsal példaként. Ez a parancs elküldhető az eszközre:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, ahol:
message=`ifconfig` — az ifconfig parancs kimenetének eredményét a $message változóhoz rendeljük
wget " — az a.php szkriptünk, amely regisztrálja a routereket, és fogad tőlük üzeneteket
u=felhasználó&p=jelszó!&m=$üzenet — hitelesítő adatok és az m kérési változó értéke — hozzárendeli a $message változó tartalmát
-O /tmp/out.txt — ebben az esetben nincs szükségünk a /tmp/out.txt fájlba történő kimenetre, de ha ez a paraméter nincs megadva, a wget nem működik
Miért nem működik ez?Mert ez egy potenciális biztonsági rés. A legártalmatlanabb hiba, ami előfordulhat, ha például „&” karakter van a parancs kimenetében. Ezért ki kell szűrni mindazt, amit az útválasztók küldenek, és mindent, ami a szerverre érkezik. Igen, szégyellem, tényleg. Védekezésemre csak annyit írhatok, hogy az egész cikk annak szentelt, hogy hogyan lehet előre definiált firmware-rel és előre meg nem definiált kommunikációs csatornákkal kezelni az útválasztókat.
Nos, kezdés a jövőnek: még nem jöttem rá, hogyan használjam a szabványos zabbix eszközöket a szerverhez érkező eredmények (például egy parancs végrehajtásának eredménye) tükrözésére.
Emlékeztetlek arra, hogy minden forrás beszerezhető a Git tárházból a következő címen:
Forrás: will.com