Toto je závěrečná část článku, zde je začátek
V minulém článku jsem psal o tom, jak jsem realizoval monitoring zařízení, nyní se budeme zabývat řízením. V diskusích s „techničkami“ ze strany Zadavatele se často setkávám s omezeným vnímáním možností těchto malých zařízení (s nízkými paměťovými a výpočetními zdroji); mnozí se domnívají, že „maximálně, co potřebujeme, je poslat restart, na něco vážnějšího - pošleme brigádu.“
Ale praxe ukazuje, že to není zcela pravda. Zde je malý seznam častých typických úkolů:
- Síťová diagnostika a odstranění problémů. Za ethernetovým portem vašeho routeru obvykle „žije“ jiné zařízení, které má svou vlastní interní ip adresu. Někdy je možné (nutné) ho „pingnout“. Nebo řízení tunelu - pokud na routeru, který pracuje přes 3G modem, se náhle nezvedá tunel, ale samotný router vidíme.
- Systémová údržba. Aktualizace firmwaru, upgrade služebních skriptů.
- Akrobatika. Mohlo by se to nazvat „úchylností“, ale pojem „akrobatika“ jako, cituji, „schopnost cirkusového umělce udržovat rovnováhu v nestabilní poloze těla“ — lépe vyhovuje. Takové situace vznikají z důvodu omezeného rozpočtu zadavatele. Níže uvádím pár příkladů, ale protože nemají přímý vztah k tématu vyprávění, uvedl jsem je v poznámkách.
Wi-Fi monitoringMódní téma posledních pěti let, zejména mezi federálními maloobchodními sítěmi. Pomalu se procházíte obchodními sály, zatímco váš mobilní telefon se zapnutým Wi-Fi se pokouší "připojit" k nějaké síti a pravidelně vysílá pakety Probe Request, které je možné analyzovat, abyste zjistili, jak často přicházíte do tohoto obchodu, jakými trasami se procházíte a podobně. Data se shromažďují, analyzují, vytvářejí se tepelné mapy a manažeři za takové obrázky "vydolovávají" peníze od vedení nebo investorů. A zatím... "peníze nejsou, ale vy se držte...", a skutečný výsledek už je potřeba ukázat, vybírá se stará dobrá píseň: "Ano, ano, samozřejmě, že později nainstalujeme cizí zařízení a vše, co si přejete, ale teď je potřeba ukázat objednavateli výsledek! Mimochodem, zapomněli jsme říci, že objednavatel povolil naše zařízení připojit k jeho hotspotu přes Wi-Fi, ale na společných základech, prostě jako bychom byli hostujícími klienty." A tak se musí dělat routery-ekvilibristi — nastavuje se několik WiFi subinterfaců, z nichž jeden se připojuje k hotspotu a druhý monitoruje okolní prostředí, zoufale ukládá výsledky tcpdumpu do sebe, následně obsah souboru balí do archivu a riskuje, že "přejíždí" se snaží vyplivnout obsah na ftp-server. Není překvapivé, že router-ekvilibrista často "selže" a nějak ho musíme vzdáleně "oživit".
RadiusZde je snazší popsat situaci přibližně takto: "Chceme decentralizovanou síť hotspotů, které by pracovaly na zařízeních, jejichž model předem neznáme, přes kanály, ale které zatím neznáme. Aha, zapomněli jsme říci, že nejen chceme zobrazovat reklamu klientům, ale také analyzovat vše kolem místa instalace hotspotu. Ne, zatím nevíme proč, ale vymyslíme to, nebojte se, dokázali jsme vymyslet tuto myšlenku."
A nesmíme zapomínat, že vzhledem k mnoha nepředvídatelným okolnostem musí řízení probíhat v nestandardních podmínkách, kdy se nemůžeme připojit k routeru přímo přes IP: port a musíme prostě čekat na projev aktivity z jeho strany. Pokud se odabstrahujeme, lze dialog mezi serverem a routerem představit takto:
- Router: Ahoj, já jsem router, existují pro mě nějaké úkoly?
- Server: router such-and-such, I registered you, you are alive. Here’s the task: show me the result of the ifconfig command?
- Router: hello. I am router such-and-such, last time you asked to show the result of ifconfig, here it is. Do you have tasks for me?
- Server: router such-and-such, I registered you, you are alive. There are no tasks for you.
The most interesting question is: how can a remote router send a certain amount of information? In the previous part, I described that due to resource limitations, only a 'trimmed' version of wget is available on the router, which only works through GET and nothing more. There’s no FTP client or curl. More precisely, we need a universal method, regardless of the image build features. I settled on using wget. To be precise, well, how should I say ‘settled’ — I simply had no other choice 🙂
A quick caveatMy management solution works, it's not heavily limited, and I am sure — it's clunky, even if it suits most of my clients. How it could be done properly — to write a small utility that sends binary data via POST through port 80. To include this utility in the router's firmware and then access it using bash. But the reality is: a) it needs to be done quickly b) it may be necessary to do everything on the existing ‘zoo of routers’ c) ‘do no harm!’ — if the router is up and running and performing other tasks, try to make changes that won’t affect existing functionality.
Let’s move on to implementation. Suppose your client wants to reboot the router from Zabbix easily and effortlessly, with a ‘click of the mouse’. Today we will start describing the implementation with Zabbix.
In the 'Administration' menu -> 'Scripts', we add a new script. We name it 'Reboot', and as the command we write 'php /usr/share/zabbix/reboot.php {HOST.HOST}'
Next: Menu 'Monitoring' -> 'Latest Data' -> 'Right-click on the necessary network node'. This is what the menu will look like after adding the script.
Accordingly, we place the reboot.php script in the directory /usr/share/zabbix (yours may be different, I use the root directory of Zabbix).
Caveat for safetyPro přehlednost ve skriptu používám pouze ID routeru, ale nezadávám heslo. V produkční verzi to takto nedoporučuji! Proč jsem to udělal: protože je velká otázka, kde uchovávat hesla k routerům? Přímo v Zabbixu v 'inventárních datech'? Rozporuplná praxe. Jako alternativu: omezit přístup zvnějšku k samotnému souboru reboot.php.
Soubor reboot.php
set_charset("utf8");
// "Odesíláme" příkaz reboot změnou pole task v tabulce users. Do pole task lze odesílat libovolný pří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();
?>To je vše. Otevřenou zůstává otázka „jak získat výsledek provedení příkazu ze strany zařízení“. Podívejme se na úlohu na příkladu s příkazem ifconfig. Takový příkaz lze odeslat zařízení:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, kde:
message=`ifconfig` — přiřazujeme proměnné $message výstup příkazu ifconfig
wget " — náš skript a.php, který registruje routery a přijímá zprávy od nich
u=user&p=password!&m=$message — přihlašovací údaje a hodnotě proměnné dotazu m — přiřazuje obsah proměnné $message
-O /tmp/out.txt — výstup do souboru /tmp/out.txt v našem případě není potřeba, ale pokud tento parametr nezadáte, wget nefunguje
Proč to nefunguje správněProtože to představuje potenciální bezpečnostní otvor. Nejbezpečnější chyba, která se může stát, je, když se ve výstupu vašeho příkazu objeví znak „&“. Proto je třeba filtrovat všechno, co se odesílá z routerů, a všechno, co přichází na server. Ano, cítím se špatně, opravdu. Na svou obhajobu mohu pouze napsat — že celý článek se věnuje tomu, jak řídit routery s neznámým firmwarem a neznámými komunikačními kanály.
A little preparation for the future: I haven't figured out how to standardly reflect results (for example, the result of a command execution) coming to the server through Zabbix yet.
I remind you that all the source codes can be retrieved from the Git repository at the address:
Zdroj: habr.com
