Toto je záverečná časť článku, tu je začiatok
Minule som písal o sledovaní zariadení, teraz sa budeme zaoberať správou. V diskusiách s „technickými“ ľuďmi zo strany objednávateľa sa často stretávam s obmedzeným vnímaním možností takýchto malých zariadení (s nízkymi pamäťovými a výkonnostnými zdrojmi), mnohí sa domnievajú, že „maximálne, čo potrebujeme, je poslať reboot, na niečo vážnejšie - pošleme tím“.
Ale prax ukazuje, že to tak celkom nie je. Tu je malý zoznam častých typických úloh:
- Sieťová diagnostika a oprava. Za ethernetovým portom vášho routera zvyčajne „žije“ iné zariadenie, ktoré má svoju vlastnú vnútornú IP adresu. Niekedy ho možno (potrebné) „pingnúť“. Alebo správa tunela — ak sa na routeri, ktorý pracuje cez 3G modem, náhle nezvyšuje tunel, ale samého routera vidíme.
- Systémová údržba. Aktualizácia firmvéru, upgrade servisných skriptov.
- Ekvilibristika. Toto by sa dalo nazvať „zvráteniami“, ale pojem „ekvilibristika“, ako citujem, „schopnosť cirkusového umelca udržiavať rovnováhu v nestabilnej pozícii tela“ — sa hodí viac. Podobné situácie vznikajú kvôli obmedzenému rozpočtu objednávateľa. Nižšie som uviedol pár príkladov, ale pretože priamo nesúvisia s témou, uviedol som ich na konci
Wi-Fi monitoringMódne téma posledných päť rokov najmä medzi federálnymi sieťami maloobchodu. Pomalými krokmi sa prechádzate po predajniach, zatiaľ čo váš mobil s aktívnym Wi-Fi sa snaží „pripojiť“ k nejakej sieti a pravidelne zasiela pakety Probe Request, ktoré sa dajú analyzovať, aby vás napočítali: ako často prichádzate do tohto obchodu, po akých trasách sa prechádzate a tak ďalej. Následne sa údaje zbierajú, analyzujú, vytvárajú sa tepelné mapy a manažéri za takéto obrázky „vydolovávajú“ peniaze od vedenia alebo investorov. No a zatiaľ…. "peňazí niet, ale vy sa držte…", a výsledok (skutočný) je potrebné už ukázať, spúšťa sa stará dobrá pieseň "Áno-áno, potom určite nainštalujeme všetko, čo si prajete, ale teraz musíme ukázať Zákazníkovi výsledok! Mimochodom, zabudli sme povedať, Zákazník povolil pripojiť našu technológiu k svojmu hotspotu cez Wi-Fi, ale na všeobecných podmienkach, jednoducho akoby sme boli hostia." A tak sa musia vyrábať routery-ekvilibristi – vytvára sa niekoľko Wi-Fi subinterfacing, z ktorých jedným sa pripojí k hotspotu a druhým monitoruje okolie, bezodná zber data tcpdump-u do seba, pričom obsah súboru zabaluje do archívu a riskujúc, že sa „preje“ sa snaží obsah nahrať na FTP server. Nie je prekvapujúce, že router-ekvilibrista sa často „zblázni“ a musí sa nejakým spôsobom „oživiť“ na diaľku.
RadiusTu je situáciu jednoduchšie opísať približne takýmto vyhlásením od zákazníka: „Chceme decentralizovanú sieť hotspotov, ktoré by fungovali na zariadení, ktorého model vopred nie je známy, cez kanály, ale aké, ešte nevieme. Ach, zabudli sme povedať, že nechceme len zobrazovať reklamu klientom, ale aj analyzovať všetko okolo miesta inštalácie hotspotu. Nie, zatiaľ nevieme prečo, ale vymyslíme to, nebojte sa, veď sme dokázali prísť s touto myšlienkou“
A nesmieme zabudnúť, že v dôsledku množstva vopred neurčených okolností musí byť správa vykonávaná v netradičných podmienkach, kedy sa nemôžeme pripojiť k routeru priamo cez IP: port a musíme len čakať na prejavy aktivity od neho. Ak sa abstrahujeme, dialóg medzi serverom a routerom môžeme predstaviť takto:
- Router: ahoj. ja som router taký a taký, mám pre mňa úlohy?
- Server: Router so-and-so, I registered you, you are alive. Here’s the task: can you show me the result of the ifconfig command?
- Router: Hello. I am the router so-and-so. Last time you asked me to show the result of ifconfig, here it is. Do you have tasks for me?
- Server: Router so-and-so, I registered you, 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 due to resource limitations, only a 'cut-down' wget works on the router, which operates solely via GET, and nothing more; there’s neither FTP client nor curl. More accurately, we need a universal method, regardless of the image build features. I settled on using wget. Well, not exactly 'settled' — I simply had no other choice 🙂
A quick caveatMy working solution for management is not overly restricted, and I’m sure — somewhat awkward, even if it suits most of my clients. The 'right' way would be to write a small utility that sends binary data via POST through port 80. This utility should be included in the router's firmware, and we could access it via bash. But the reality is: a) it needs to be fast b) it may need to be done on the existing 'zoo of routers' c) 'do no harm!' — if the router is operating and performing other tasks, try to make changes that won't affect its existing functionality.
Let’s move on to implementation. Suppose your client wants to easily restart the router from Zabbix, with just a 'click of the mouse'. Today we will start describing the implementation from Zabbix.
In the 'Administration' menu -> 'Scripts', we add a new script. We name it 'Reboot', and for the command, we write 'php /usr/share/zabbix/reboot.php {HOST.HOST}'
Next: In the 'Monitoring' menu -> 'Latest data' -> 'Right-click on the desired network node'. This is how the menu will look after adding the script.
Accordingly, the reboot.php script is placed in the /usr/share/zabbix directory (yours may be different; I use the root directory of Zabbix).
A caveat for securityNa ilustráciu vysvetlenia v skripte používam len ID routera, ale nepoužívam heslo. V pracovnej verzii to tak nerobte! Prečo som to urobil: pretože je veľká otázka, kde ukladať heslá k routerom? V samotnom Zabbixe v "inventárnych údajoch"? Protirečivá prax. Ako variant: obmedziť prístup zvonka k samotnému súboru reboot.php
Súbor reboot.php
set_charset("utf8");
// "Posielame" príkaz reboot prostredníctvom zmeny poľa task tabuľky users. Do poľa task môžeme poslať akýkoľvek príkaz.
$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();
?>Sami. Otvorenou zostáva otázka „ako získať výsledok vykonania príkazu zo strany zariadenia“. Pozrime sa na problém na príklade s príkazom ifconfig. Takýto príkaz môžeme odoslať zariadeniu:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, kde:
message=`ifconfig` — premenná $message obsahuje výsledok výstupu príkazu ifconfig
wget " — náš skript a.php, ktorý registruje routre a prijíma od nich správy
u=user&p=password!&m=$message — prihlasovacie údaje a hodnote premennej dopytu m — priraďuje obsah premennej $message
-O /tmp/out.txt — výstup do súboru /tmp/out.txt v našom prípade nie je potrebný, ale ak tento parameter neuviedete, wget nefunguje
Prečo to nefunguje dobrePretože je to potenciálna bezpečnostná diera. Najnevinnejšia chyba, ktorá sa môže stať — je, ak vo výstupe vášho príkazu bude napríklad znak „&“. Preto je potrebné filtrovať a všetko, čo posielate z routerov a všetko, čo prichádza na server. Áno, je mi to trápne, naozaj. Na svoju obranu môžem len povedať — že celý článok je venovaný tomu, ako spravovať routre s vopred neurčeným firmvérom, s vopred neurčenými komunikačnými kanálmi.
A little preparation for the future: I haven't figured out yet how to display results (for example, the outcome of a command execution) that come to the server using standard Zabbix tools.
I remind you that all source files can be retrieved from the Git repository at the address:
Zdroj: habr.com
