Kaugjuhtimine ja haldamine Linux/OpenWrt/Lede seadmetest 80. pordi kaudu, jätk

See on artikli viimane osa, siin on algus habr.com/et/post/445568
Eelmisel korral kirjutasin, kuidas rakendasin seadmete jälgimist, nüüd räägime juhtimisest. Aruteludes „tehnilise poole“ esindajatega tellija poolt kohtan sageli piiratud arusaama nende väikeste seadmete (madala mälu- ja töötlusvõimega) võimalustest; paljud arvavad, et „kõige rohkem, mida me vajame, on saata reboot, tõsisemate probleemide jaoks saadame me meeskonna“.
Kuid praktika näitab, et see pole päris nii. Siin on väike nimekiri sagedastest tüüpilistest ülesannetest:

1. Võrgu diagnostika ja tõrkeotsing. Teie ruuteri ethernet-porti taha "elab" tavaliselt teine seade, millel on oma sisemine IP-aadress. Mõnikord võib seda "pingida". Või tunnelihalduse juhtimine — kui ruuter, mis töötab 3G-mooduli kaudu, ei tõuse äkki tunnel, aga ruuterit ise näeme.
2. Süsteemi hooldus. Firmware'i värskendamine, teenuse skriptide uuendamine.
3. Ekvilibristika. Seda võiks nimetada „vääritamiseks“, kuid mõiste „ekvilibristika“, nagu tsiteerin, „tsirkuseartistide oskus hoida tasakaalu ebastabiilse kehaasendi juures“ on ilmselt sobivam. Sellised olukorrad tekivad tellija eelarve piirangute tõttu. Olen toonud allpool paar näidet, kuid kuna neil ei ole otsest seost jutu teemaga, olen need pannud märkustesse

Wi-Fi jälgimineViimase viie aasta jooksul on see teema peamiselt olnud populaarne riikliku jaekaubanduse seas. Te jalutate rahulikult kaupluse vahel ja teie telefon Wi-Fi sisse lülitatuna püüab pidevalt «ühenduda» mingi võrku, saates regulaarselt Probe Request pakette, mida saab analüüsida, et jälgida teid: kui sagedasti te sellele kauplusele külastate, millistel trajektooridel liigute jne. Seejärel kogutakse andmed, analüüsitakse, joonistatakse soojuskaardid ja juhatajad nõuavad selliste piltide tõttu raha oma juhtkonnalt või investoritelt. Ja seni… «raha ei ole, aga te hoidke end…», samas peab juba näitama reaalset tulemust ja siseneb vana hea laulusalm «Jah, jah, hiljem me kindlasti paigaldame kõik soovitud seadmed, aga praegu tuleb klientidele tulemust näidata! Üks asi, et klient võimaldas meil oma seadmed oma võrku Wi-Fi kaudu ühendada, aga ühiste põhimõtete alusel, just nagu oleksime külastajad». Nii tuleb hakata tegema ekviliibristest ruutereid — seadistatakse mitu WiFi alam-interfääsi, millest üks ühendub hotspotiga ja teine jälgib ümbritsevat keskkonda, laadides välkkiirusel tcpdumpi tulemusi enda sisse, seejärel pakib faili sisu arhiivi ja riskides «üle sööma», üritab sisu FTP-serverisse edastada. Pole üllatav, et ekviliibristest ruuterid kirjeldavad sageli «katkestusi» ja neid tuleb kuidagi kaugelt «elustada».

RadiusSiin on olukorda lihtsam kirjeldada kliendi järgmise väitega: «Me tahame tsentraliseerimata hotspot-võrku, mis töötaks seadmetel, mille mudel on eelnevalt teadmata, kanalite kaudu, aga me ei tea veel, milliseid. Ah, unustasime öelda, et soovime mitte ainult klientidele reklaami näidata, vaid ka analüüsida kõike hotspoti paigaldamise ümber. Ei, me ei tea veel, milleks, aga me leiame selle välja, ärge kahtlege, me suutsime ju selle idee välja mõelda!»

Ja ei tohi unustada, et paljude ettenägematute asjaolude tõttu peab juhtimine toimuma ebatavalistes tingimustes, kui me ei saa ruuteriga otse IP kaudu ühendust võtta: port ja peame lihtsalt ootama aktiivsuse ilmnemist. Kui abstraktseks minna, siis serveri ja ruuteri vahelise dialooge saab esitada järgmiselt:

• Ruuter: tere. mina olen ruuter, kas mul on ülesandeid?
• Server: Ruuter, selline nagu sina, registreerisin sind, et sa elad. Siin on ülesanne: näita mulle ifconfig käsu tulemust?
• Ruuter: Tere. Mina olen ruuter, selline nagu sina, eelmisel korral palusid sa näidata ifconfigi tulemust, siin see on. Kas sul on minu jaoks ülesandeid?
• Server: Ruuter, selline nagu sina, registreerisin sind, et sa elad. Ülesandeid ei ole.

Kõige huvitavam küsimus: kuidas saab eemalolev ruuter saata teatud hulga teavet? Eelmises osas kirjeldasin, et ruuteril, piiratud ressursside tõttu, on ainult "lõigatud" wget, mis töötab ainult GET kaudu ja mitte midagi muud, ei ole FTP-klienti, ei curl’i. Täpsemalt, meil on vaja universaalset viisi, sõltumatult kujunduse omadustest. Otsustasin kasutada wget’i. Täpsemalt, noh, kuidas öelda, sõnasin "otsustasin" — mul polnud lihtsalt valikut 🙂

Koheselt selgitusMinu lahendus haldamiseks töötab, on vaid pisut piiratud ja ma olen kindel — vildakas, isegi kui see rahuldab enamikku minu klientidest. Kuidas võiks õigesti teha — kirjutada väike utiliit, mis saadab 80. pordi kaudu POST-iga binaarandmeid. Lisada see (utiliit) ruuteri mitteprogrammeeritavasse tarkvarasse ja sealt edasine suhtlemine bash’i kaudu. Kuid reaalsus on selline, et: a) peab olema kiire b) võib-olla peab tegema see olemasoleval "loomade aed" ruuterite kogumil c) "ära korda!" — kui ruuter töötab ja täidab muid ülesandeid, püüa teha muudatusi, mis ei mõjuta olemasolevat funktsionaalsust.

Liigume elluviimise juurde. Oletame, et teie klient soovib zabbixist ruuteri taaskäivitada lihtsalt ja mugavalt, "hiireklõpsuga". Täna alustame elluviimise kirjeldusega zabbixist.
Menüüs «Haldus» -> «Skriptid» lisame uue skripti. Nimeks paneme «Taaskäivita», käsuks kirjutame «php /usr/share/zabbix/reboot.php {HOST.HOST}»

Edasi: Menüü «Jälgimine» -> «Viimased andmed» -> «Paremklõps vajalikul võrgu sõlmel». Nii näeb menüü välja pärast skripti lisamist.

Seega paneme skripti reboot.php katalooge /usr/share/zabbix (teie kataloog võib olla erinev, ma kasutan zabbixi juurkatalooge).

Selgitus turvalisuse huvidesSelgituseks kasutan skripti jaoks ainult ruuteri ID-d, kuid parooli ei kasuta. Tööversioonis ei ole see soovitatav! Miks ma nii tegin: sest suur küsimus on – kus hoida ruuterite paroole? Zabbixis „inventeerimisandmetes”? Vaieldav praktika. Üks võimalus: piirata väljuvat ligipääsu failile reboot.php

Fail reboot.php

set_charset("utf8");
			
	// „Saatke“ käsk reboot, muutes users tabelis task välja. Task välja saab saata mis tahes käsku.
	$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();
?>

Sellel juhul on kõik. Avatud jääb küsimus, „kuidas saada seadme käskude täitmise tulemust“. Vaadakem ülesannet näite põhjal käsu ifconfig puhul. Sellise käsu 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 muutujale $message käsu ifconfig väljundi tulemuse
wget „xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php — meie skript a.php, mis registreerib ruuterid ja võtab neilt sõnumeid vastu
u=user&p=password!&m=$message — autentimistunnused ja muutuja m – määrab $message muutuja sisu
-O /tmp/out.txt — väljund failisse /tmp/out.txt pole antud juhul vajalik, kuid kui seda parameetrit ei määrata, ei toimi wget

Miks see valesti töötabSest see on potentsiaalne turvaauk. Kõige ohutum viga, mis võib juhtuda, on see, kui teie käsu väljundis on näiteks sümbol „&“. Seetõttu tuleb filtreerida kõik, mis saadetakse ruuteritest ja kõik, mis serverisse tuleb. Jah, ma tunnen end tõeliselt häbenevat. Oma kaitseks võin vaid kirjutada – et kogu artikkel on pühendatud sellele, kuidas juhtida ruutereid, millel on eelnevalt määramata tarkvaraversioon ja teadmatud sidekanalid.

Ja tuleviku jaoks: ma ei ole veel aru saanud, kuidas Zabbixi tavaliste vahenditega kuvada tulemusi (näiteks käsu täitmise tulemus), mis serverisse saadetakse.

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

Allikas: habr.com