To jest ostatnia część artykułu, oto początek
W poprzedniej części opisałem, jak zrealizowałem monitoring urządzeń, a teraz przejdziemy do zarządzania. W dyskusjach z „technicznymi” przedstawicielami Klienta często spotykam się z ograniczonym postrzeganiem możliwości takich małych urządzeń (z ograniczonymi zasobami pamięci i wydajnością), wielu uważa, że „maksimum, czego potrzebujemy, to wysłać reboot, a do czegoś poważniejszego wyślemy ekipę”.
Jednak praktyka pokazuje, że to nie do końca prawda. Oto krótka lista często występujących typowych zadań:
- Diagnostyka sieci i rozwiązywanie problemów. Za portem ethernetowym Twojego routera zwykle znajduje się inne urządzenie, które ma swój własny wewnętrzny adres ip. Czasami można (a nawet trzeba) je „pingować”. Lub zarządzanie tunelami — jeśli na routerze działającym przez modem 3G nagle nie uruchamia się tunel, ale sam router jest widoczny.
- Utrzymanie systemu. Aktualizacja oprogramowania, usprawnienie skryptów pomocniczych.
- Akrobatyka. Można by to nazwać „perwersjami”, ale pojęcie „akrobatyka”, jak cytuję, „zdolność artysty cyrkowego do utrzymywania równowagi w niestabilnej pozycji ciała” — bardziej pasuje. Takie sytuacje pojawiają się z powodu ograniczonego budżetu klienta. Poniżej podaję kilka przykładów, ale ponieważ nie mają one bezpośredniego związku z tematem, umieściłem je w przypisach.
Monitoring Wi-FiTemat, który był na fali przez ostatnie pięć lat, głównie wśród krajowych sieci detalicznych. Spacerujesz po salach handlowych, a Twój telefon komórkowy z włączonym Wi-Fi próbuje „przyłączyć się” do jakiejś sieci, regularnie wysyłając pakiety Probe Request, które można analizować, aby policzyć: jak często odwiedzasz ten sklep, jakie trasy przechodzisz i tak dalej. Następnie dane są zbierane, analizowane, tworzone są mapy cieplne, a menedżerowie na podstawie tych obrazków „wyciągają” pieniądze od kierownictwa lub inwestorów. A na razie... „pieniędzy nie ma, ale jakoś sobie radzicie...”, a rezultat (rzeczywisty) już trzeba pokazać, włącza się stara dobra piosenka: „Tak, tak, potem oczywiście zainstalujemy cokolwiek zechcesz, ale teraz musimy pokazać Klientowi rezultat! Swoją drogą zapomnieliśmy wspomnieć, że Klient pozwolił na podłączenie naszego sprzętu do jego hotspota przez Wi-Fi, ale na ogólnych zasadach, po prostu jakbyśmy byli gościem”. I tak trzeba robić routery-ekwilibrystów — uruchamia się kilka interfejsów sub- WiFi, jednym z nich podłączają się do hotspota, a drugim monitorują otoczenie, nerwowo przesyłając wynik tcpdumpu do samego siebie, następnie zawartość pliku pakują w archiwum i ryzykując „przejedzenie”, próbują wypluć zawartość na serwer FTP. Nic dziwnego, że router-ekwilibrysta często się „przewraca” i czasami trzeba go zdalnie „reanimować”.
RadiusW tej sytuacji łatwiej opisać sytuację mniej więcej w następujący sposób: „Chcemy zdecentralizowanej sieci hotspotów, które będą działały na sprzęcie, którego model jest wcześniej nieznany, przez kanały, które jeszcze nie są ustalone. A, zapomnieliśmy powiedzieć, chcemy nie tylko pokazywać reklamy klientom, ale również analizować wszystko wokół miejsca instalacji hotspotu. Nie, na razie nie wiemy po co, ale wymyślimy to, nie wątpicie, potrafiliśmy wymyślić ten pomysł”.
Nie należy zapominać, że z powodu wielu nieznanych z góry okoliczności, zarządzanie musi odbywać się w niestandardowych warunkach, kiedy nie możemy bezpośrednio połączyć się z routerem przez IP: port i musimy po prostu czekać na manifestację aktywności z jego strony. Z perspektywy abstrakcyjnej, dialog między serwerem a routerem można przedstawić w ten sposób:
- Router: cześć. jestem routerem takim i takim, czy masz dla mnie jakieś zadania?
- Serwer: Router such-and-such, I have registered you, so you are alive. Here’s the task: can you show me the result of the ifconfig command?
- Router: Hello. I am the router such-and-such, last time you asked me to show the result of ifconfig, here it is. Do you have any tasks for me?
- Serwer: Router such-and-such, I have registered you, so you are alive. There are no tasks for you.
The most interesting question is: how can a remote router send a specific amount of information? In the previous part, I described that on the router, due to resource limitations, there is only a ‘trimmed’ wget, which works only through GET and nothing else, no FTP client or curl. Specifically, we need a universal way, regardless of the specifics of the image build. I have stopped at using wget. More precisely, well, how to say 'stopped' — I just had no choice 🙂.
A quick noteMy management solution is operational, somewhat limited, and I am sure — crooked, even if it satisfies most of my clients. How it could ideally be done — is to write a small utility that sends binary data via POST through port 80. Include this utility in the router's firmware and then access it using bash. But the reality is that: a) it needs to be done quickly b) it may all need to be done on the existing 'zoo of routers' c) 'do no harm!' — if the router is working and performing other tasks, try to make changes that do not affect existing functionality.
Let's move on to the implementation. Suppose your client wants to easily and effortlessly reboot the router from Zabbix, with a 'click of a mouse'. Today we will begin to describe the implementation with Zabbix.
In the 'Administration' menu -> 'Scripts', we add a new script. We name it 'Reboot', and in the command, we write 'php /usr/share/zabbix/reboot.php {HOST.HOST}'.
Next: Menu 'Monitoring' -> 'Latest Data' -> 'Right-click on the required network node'. This is how the menu will look after adding the script.
Accordingly, we place the script reboot.php in the directory /usr/share/zabbix (yours may be different, I use the root directory of Zabbix).
A note for securityDla lepszego zrozumienia wyjaśnienia w skrypcie używam tylko id routera, ale nie korzystam z hasła. W wersji roboczej nie zaleca się tego robić! Dlaczego tak uczyniłem: ponieważ pojawia się ważne pytanie — gdzie przechowywać hasła do routerów? W samej bazie Zabbix w „danych inwentarzowych”? Sprzeczna praktyka. Jako alternatywę: ograniczyć dostęp zewnętrzny do samego pliku reboot.php
Plik reboot.php
set_charset("utf8");
// "Wysyłamy" polecenie reboot za pomocą zmiany pola task w tabeli users. W polu task można wysyłać dowolne polecenie.
$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();
?>Właściwie to wszystko. Otwartym pozostaje pytanie „jak uzyskać wynik wykonania polecenia z strony urządzenia”. Rozważmy zadanie na przykładzie z poleceniem ifconfig. Takie polecenie można wysłać do urządzenia:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, gdzie:
message=`ifconfig` — zmiennej $message przypisujemy wynik polecenia ifconfig
wget " — nasz skrypt a.php, rejestrujący routery i przyjmujący od nich wiadomości
u=user&p=password!&m=$message — dane uwierzytelniające, a wartość zmiennej zapytania m — przypisuje zawartość zmiennej $message
-O /tmp/out.txt — wyjście do pliku /tmp/out.txt w tym przypadku nie jest nam potrzebne, ale jeśli nie podamy tego parametru, wget nie zadziała
Dlaczego to działa źlePonieważ to potencjalna luka w bezpieczeństwie. Najbezpieczniejszy błąd, który może wystąpić — to jeśli w wyniku waszego polecenia znajdzie się na przykład znak „&”. Dlatego należy filtrować wszystko, co jest wysyłane z routerów i wszystko, co przychodzi na serwer. Tak, wstyd mi, prawda. W swoim usprawiedliwieniu mogę tylko napisać — że cały artykuł poświęcony jest temu, jak zarządzać routerami z nieznanym wcześniej oprogramowaniem, z nieznanymi wcześniej kanałami komunikacyjnymi.
A więc jest to też inwestycja na przyszłość: na razie nie rozgryzłem, jak standardowymi narzędziami Zabbix-a odzwierciedlać wyniki (na przykład wyniki wykonywania komendy), które przychodzą na serwer.
Przypominam, że wszystkie źródła można pobrać z repozytorium Git pod adresem:
Źródło: habr.com
