Linux/OpenWrt/Lede seadmete kaugmonitorimine ja -haldamine 80. porta kaudu, jätk

See on artikli viimane osa, siin on algus habr.com/ru/post/445568
Viimati kirjutasin, kuidas seadmete jälgimist rakendada, nüüd räägime haldamisest. Kliendi "tehnikutega" aruteludes kohtan tihti piiratud arusaama, mida sellised väikesed seadmed (madala mälu ja jõudlusega) suudavad, paljud arvavad, et "kõige rohkem, mida me vajame, on saata reboot, tõsisemate asjade jaoks saadame meeskonna".
Kuid praktika näitab, et see ei ole päris tõsi. Siin on väike nimekiri sagedastest tüüpilistest ülesannetest:

1. Võrgud diagnostika ja tõrkeotsingu. Teie ruuteri ethernet-pordi taha elab tavaliselt teine seade, millel on oma sisemine IP-aadress. Mõnikord võib seda "pingida". Või tunnelihaldus — kui ruuter, mis töötab 3G-mooduliga, ei hakka äkki tunnelit üles, kuid me näeme ise ruuterit.
2. Süsteemi hooldus. Firmware värskendamine, teenuseskriptide uuendamine.
3. Ekvilibristika. Seda võiks nimetada "väänamiseks", kuid mõiste "ekvilibrist" tähendab, tsiteerides, "tsirkusekunstniku võimet hoida tasakaalu ebastabiilses kehaasendis" — sobib paremini. Sellised olukorrad tekivad tellija eelarve piirangute tõttu. Allpool olen välja toonud paar näidet, kuid kuna need ei ole otseselt seotud narratiiviga, tõin need välja eraldi märkustes.

Wi-Fi jälgimineViimase viie aasta jooksul on see teema muutunud eriti aktuaalseks riiklike jaotussüsteemide seas. Te jalutate rahulikult kauplustes, samas kui teie mobiiltelefon, millel on sisse lülitatud Wi-Fi, saadab pidevalt Probe Request pakette, et «kinnituda» mõnda võrku, mis võimaldab analüüsida, kui sageli te sellesse poodi tulete, milliseid teid mööda jalutate jne. Seejärel kogutakse ja analüüsitakse andmeid, joonistatakse soojuskaarte ning juhid saavavad selliste piltide abil rahastust juhtkonnalt või investoritelt. Ja seni, kuni… "raha pole, aga te ikka püsige…", tuleb näidata tegelikku tulemust, lastakse mängu vana hea laulusalm: "Jah, jah, hiljem me muidugi paigaldame kõik soovitud seadmed, aga praegu peab näitama Kliendile tulemust! Muide, unustasime mainida, et Klient lubas meie seadmeid oma hotspotiga Wi-Fi kaudu ühendada, aga ka ühiselt, nagu oleksime külaliskliendid." Ja nii tuleb teha ekvilibristist ruutereid — tõstetakse mitu WiFi alaliidest, millest üks ühendub hotspotiga, samas kui teine jälgib ümbritsevat keskkonda, tõmbab tcpdumpi tulemusi ning üritab pakitud faili FTP-serverisse saata, riskides „liigne kurnatus“. Pole üllatav, et ekvilibristist ruuter puruneb sageli ning seda tuleb kuidagi eemalt "elustada".

RaadiusSiin on olukord lihtsam kirjeldada järgmisel nõudmisel: «Me tahame detsentraliseeritud hotspotide võrku, mis töötaks seadmetel, mille mudel ei ole eelnevalt teada, läbi kanalite, kuid millised need on, me veel ei tea. Ah, unustasime mainida, et me tahame mitte ainult reklaami klientidele kuvada, vaid analüüsida ka kõike hotspot'i paigalduskoha ümber. Ei, me veel ei tea, milleks me seda vajalikuks peame, aga leiame välja, ärge muretsege, me suutsime ju selle idee välja mõelda!»

Ja ei tohi unustada, et paljude määramatute eelnevalt määratlemata asjaolude tõttu peab juhtimine toimuma mittestandardses olukorras, kus me ei saa otse ruuterisse IP: porti ühenduda ja oleme sunnitud lihtsalt ootama tema aktiivsuse ilmingut. Kui abstraktselt vaadata, siis dialogi serveri ja ruuteri vahel võib kujutada nii:

• Ruuter: tere. ma olen selline ruuter, kas mul on ülesandeid?
• Server: ruuter, ma olen sind registreerinud, et sa oled elus. Siin on ülesanne: näita mulle ifconfig käsu tulemust?
• Ruuter: tere. ma olen selline ruuter, eelmisel korral palusid sa näidata ifconfigi tulemust, siin see on. Kas mul on ülesandeid?
• Server: ma router on registreeritud, et sa oled elus. Sul ei ole ülesandeid.

Selle huvitav küsimus: kuidas saab eemalolev ruuter saata teatud hulga teavet? Eelmises osas kirjeldasin, et ruuteri piiratud ressursside tõttu on seal ainult «lõigatud» wget, mis töötab ainult läbi GET ja rohkem mitte midagi, ei ole ftp-klienti ega curl. Täpsemalt öeldes, vajame universaalset viisi, mis ei sõltu pildi koostamise omadustest. Peatusin wget'i kasutamise juures. Täpsemalt, kuidas «peatusin» — mul polnud lihtsalt valikut 🙂

Esiteks üks väike märkusMinu lahendus haldamiseks on töökindel, küll pigem piiratud ja olen kindel, et see ei ole täiuslik, isegi kui see sobib enamikule minu klientidest. Kuidas oleks mõistlikum seda teha — kirjutada väike utiliit, mis saadab porti 80 kaudu POST-iga binaardata. Lisada see (utiliit) ruuteri tarkvarasse ja kutsuda seda esile bash-i kaudu. Kuid reaalsus on see, et: a) peab olema kiire b) võib-olla tuleb kasutada olemasolevat 'ruuteri loomaaeda' c) 'ära tee vigade!' — kui ruuter töötab ja täidab muid ülesandeid, püüa teha muudatusi, mis ei mõjutaks olemasolevat funktsionaalsust.

Liigume edasi rakendamise juurde. Oletame, et teie klient soovib zabbixist ruuteri taaskäivitamist, et see oleks lihtne ja mugav, 'hiireklõpsuga'. Täna alustame rakenduse kirjeldust zabbixist.
Administratsiooni menüüs -> Skriptid lisame uue skripti. Nimeks paneme 'Reboot', käsuks kirjutame 'php /usr/share/zabbix/reboot.php {HOST.HOST}'

Edasi: Jälgimise menüüs -> Viimased andmed -> 'Paremklõps vajalikule võrgu sõlmele'. Nii näeb menüü välja pärast skripti lisamist.

Seega paneme skripti reboot.php katalooge, mis asub /usr/share/zabbix (Teie puhul võib see olla teine, mina kasutan zabbixi juurkatalooge).

OhutusmärkusedSelguse huvides kasutan skriptis ainult ruuteri ID-d, kuid ei kasuta parooli. Tööversioonis ei soovitata nii teha! Miks nii tegin: suur küsimus on, kus hoida ruuterite paroole? Kas Zabbixis «inventarimaterjalides»? Vastuolu praktika. Ühe võimalusena: piirata juurdepääsu väljastpoolt failile reboot.php

Fail reboot.php

set_charset("utf8");
			
	// "Saadame" käsku reboot läbi muutes ülesande välja tabelis users. Ülesande välja saab saata ükskõik millise käsu.
	$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();
?>

Küsimus on selles, kuidas saada seadme poolt käskude täitmise tulemusi. Vaadake ülesannet, kasutades käsku ifconfig. Siin on näide, mille saab seadmele saata:

message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt

, kus:
message=`ifconfig` — me määrame muutuja $message väärtuseks käsku ifconfig täitmise tulemus
wget "xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php — meie skript a.php, mis registreerib ruutereid ja võtab neilt sõnumeid vastu
u=user&p=password!&m=$message — autentimise andmed ja muutuja m väärtus määratakse muutuja $message sisu järgi
-O /tmp/out.txt — väljund failiks /tmp/out.txt ei ole antud juhul vajalik, kuid kui seda parameetrit ei määrata, siis wget ei toimi

Miks see ei töötaKuna see on potentsiaalne turvaauk. Kõige kahjutum viga, mis võib juhtuda, on see, et teie käsu väljundis on näiteks märk „&“. Seetõttu tuleb filtreerida kõik, mis saadetakse ruuteritest ja kõik, mis serverisse saabub. Jaa, mul on tõesti piinlik. Kaitseks võin vaid öelda, et kogu artikkel on pühendatud sellele, kuidas hallata ruutereid, millel on ette teadmata tarkvara ja ette teadmata sidekanaleid.

Ja tulevikuks: ma ei ole veel aru saanud, kuidas zabbixi standardsete vahenditega kajastada tulemusi (näiteks käsu täitmise tulemust), mis serverisse saadetakse.

Tuletan meelde, et kõik lähtekoodid on saadaval Git-repositooriumis aadressil: github.com/BazDen/iotnet.online.git

Allikas: habr.com