Nuotolinis „Linux“ / „OpenWrt“ / „Lede“ įrenginių stebėjimas ir valdymas per 80 prievadą, tęsinys

Tai yra paskutinė straipsnio dalis, čia yra pradžia habr.com/en/post/445568
Praėjusį kartą rašiau apie tai, kaip įdiegiau įrenginių stebėjimą, dabar kalbėsime apie valdymą. Diskusijose su „technikais“ iš Kliento pusės dažnai susiduriu su ribotu tokių mažų įrenginių galimybių suvokimu (su mažais atminties ištekliais ir našumu), daugelis mano, kad „labiausiai mums reikia atsiųsti perkrovimą, kad būtų kažkas daugiau. rimtai atsiųsime komandą“.
Tačiau praktika rodo, kad tai nėra visiškai tiesa. Štai nedidelis įprastų tipinių užduočių sąrašas:

  1. Tinklo diagnostika ir trikčių šalinimas. Už jūsų maršrutizatoriaus eterneto prievado paprastai yra kita techninė įranga, turinti savo vidinį IP adresą. Kartais galite (turėtumėte) jį „pinguoti“. Arba tunelio valdymas – jei ant maršrutizatoriaus, veikiančio per 3G modemą, tunelis staiga nepakyla, bet matome patį maršrutizatorių.
  2. Sistemos priežiūra. Programinės įrangos atnaujinimas, paslaugų scenarijaus atnaujinimas.
  3. Balansavimo veiksmas. Tai būtų galima pavadinti „iškrypimu“, tačiau „ekvilibristikos“ sąvoka, cituoju, „Cirko artisto gebėjimas išlaikyti pusiausvyrą nestabilioje kūno padėtyje“ - tinka geriau. Tokios situacijos susidaro dėl riboto kliento biudžeto. Žemiau pateikiau keletą pavyzdžių, bet... Jie nėra tiesiogiai susiję su pasakojimo tema, įdedu juos į pastabas

Wi-Fi stebėjimasPastaruosius penkerius metus madinga tema, daugiausia tarp federalinių mažmeninės prekybos tinklų. Neskubėdami vaikštote per prekybos aukštus, o jūsų mobilusis telefonas su įjungtu „Wi-Fi“, bandydamas „prilipti“ prie kokios nors tinklo gijos, reguliariai siunčia „Probe Request“ paketus, kuriuos galima analizuoti ir apskaičiuoti tu: kaip dažnai užsuki į šią parduotuvę, dėl kokių priežasčių?vaikštai trajektorijomis ir pan. Tada renkami, analizuojami duomenys, braižomi karščio žemėlapiai, o už tokias nuotraukas vadovai „išvilioja“ pinigus iš vadovybės ar investuotojų. Na kol kas.... „nėra pinigų, bet laikykis...“, o rezultatą (tikrą) jau reikia parodyti, prasideda sena gera daina: „Taip, taip, tada žinoma mes įdiegs cis ir viską, ko tik norite, bet dabar turime parodyti Klientui rezultatą! Beje, pamiršome pasakyti, kad Klientas leido mums prijungti įrangą prie savo viešosios interneto prieigos taško per „Wi-Fi“, bet bendrais pagrindais, lygiai taip, lyg būtume klientai svečiai. Taip ir tenka daryti balansuojančius maršrutizatorius – iškeliamos kelios WiFi antrinės sąsajos, iš kurių viena priglunda prie viešosios interneto prieigos taško, o antroji stebi aplinką, įnirtingai įkelia sau tcpdump rezultatą, tada supakuoja failo turinį į archyvą ir rizikuoja. miršta nuo „persivalgymo“ bando išspjauti turinį FTP serveryje. Nenuostabu, kad balansuojantis maršrutizatorius dažnai „sugenda“ ir jį kažkaip reikia „atgaivinti“ nuotoliniu būdu.

spindulysČia situaciją lengviau apibūdinti tokiu kliento teiginiu: „Norime decentralizuoto karštųjų taškų tinklo, kuris veiktų su įranga, kurios modelis iš anksto nežinomas, per kanalus, bet kurių mes dar nežinome. Oi, pamiršome pasakyti, kad norime ne tik rodyti reklamą klientams, bet ir išanalizuoti viską aplink vietą, kurioje įrengtas viešosios interneto prieigos taškas. Ne, kol kas nežinome kodėl, bet išsiaiškinsime, neabejokite, mums pavyko sugalvoti šią idėją.

Ir nereikia pamiršti, kad dėl daugybės anksčiau nežinomų aplinkybių valdymas turi būti vykdomas nestandartinėmis sąlygomis, kai negalime tiesiogiai prisijungti prie maršrutizatoriaus per IP: prievadą ir esame priversti tiesiog laukti veiklos iš jo. Jei abstrahuosime, dialogas tarp serverio ir maršrutizatoriaus gali būti pavaizduotas taip:

  • Maršrutizatorius: Sveiki. Aš toks ir toks maršrutizatorius, ar man yra kokių nors užduočių?
  • Serveris: maršrutizatorius toks ir toks, užregistravau tave, kad tu gyvas. Štai iššūkis: parodyti man ifconfig komandos rezultatą?
  • Maršrutizatorius: Sveiki. Aš esu toks ir toks maršrutizatorius, paskutinį kartą prašėte parodyti ifconfig rezultatą, štai jis. Ar man yra kokių nors užduočių?
  • Serveris: maršrutizatorius toks ir toks, užregistravau tave, kad tu gyvas. Užduočių jums nėra.

Įdomiausias klausimas: kaip nuotolinis maršrutizatorius gali siųsti tam tikrą informacijos kiekį? Paskutinėje dalyje aprašiau, kad dėl ribotų resursų maršrutizatorius turi tik „nuplėštą“ wget, kuris veikia tik per GET ir nieko daugiau, nėra FTP kliento ar curl. Tiksliau, mums reikia universalaus metodo, neatsižvelgiant į vaizdo surinkimo ypatybes. Aš apsisprendžiau naudoti wget. Tiksliau, kaip aš "sustabdžiau" - tiesiog neturėjau pasirinkimo :)

Tiesiog atsisakymasMano valdymo sprendimas veikia, nėra labai ribotas, ir esu tikras, kad jis kreivas, net jei jis tinka daugumai mano klientų. Kaip galėtumėte tai padaryti protingai – parašykite nedidelę programą, kuri siunčia POST dvejetainius duomenis per 80 prievadą. Įtraukite jį (įrankį) į maršrutizatoriaus programinę-aparatinę įrangą ir pasiekite ją naudodami bash. Tačiau realybė tokia: a) turime greitai b) tikriausiai turime padaryti viską esamame „maršrutizatorių zoologijos sode“ c) „nepadaryti žalos! — jei maršrutizatorius veikia ir atlieka kitas užduotis, pabandykite atlikti pakeitimus, kurie neturės įtakos esamoms funkcijoms.

Pereikime prie įgyvendinimo. Tarkime, kad jūsų klientas nori lengvai ir natūraliai iš naujo paleisti maršruto parinktuvą iš „zabbix“, „spustelėjus pelę“. Šiandien pradėsime apibūdinti diegimą su Zabbix.
Meniu „Administravimas“ -> „Scenarijai“ pridėkite naują scenarijų. Mes tai vadiname „Reboot“, įveskite „php /usr/share/zabbix/reboot.php {HOST.HOST}“ kaip komandą

Nuotolinis „Linux“ / „OpenWrt“ / „Lede“ įrenginių stebėjimas ir valdymas per 80 prievadą, tęsinys

Kitas: meniu „Stebėjimas“ -> „Naujausi duomenys“ -> „Dešiniuoju pelės mygtuku spustelėkite norimą tinklo mazgą“. Taip atrodys meniu pridėjus scenarijų.

Nuotolinis „Linux“ / „OpenWrt“ / „Lede“ įrenginių stebėjimas ir valdymas per 80 prievadą, tęsinys
Atitinkamai, mes įdedame reboot.php scenarijų į /usr/share/zabbix katalogą (jūsų gali būti kitoks, aš naudoju zabbixa šakninį katalogą).

Saugos atsisakymasKad paaiškinimas būtų aiškesnis scenarijuje, naudoju tik maršrutizatoriaus ID, bet nenaudoju slaptažodžio. Gamybinėje versijoje to daryti nerekomenduojama! Kodėl aš tai padariau: nes didelis klausimas yra, kur laikyti maršrutizatorių slaptažodžius? Pačiame zabbixe „inventoriaus duomenyse“? Prieštaringa praktika. Arba: apribokite išorinę prieigą prie paties reboot.php failo

Failas reboot.php

<?php
	// присваиваем параметры с консоли переменным
	$user = $argv[1];
	// ВНИМАНИЕ. Вот здесь в целях безопасности все-таки прописывать пароль устройства! Но для демонстрации мы будем обращаться к базе данных без использования пароля. 
	//$password = $argv[2];
		
	$conn=new mysqli("localhost","db_user","db_password","db_name");
	if (mysqli_connect_errno()) {
		exit();
	}
	$conn->set_charset("utf8");
			
	// "Отправляем" команду reboot за счет изменения поля task таблицы users. В поле task можно отправлять любую команду.
	$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();
?>

Tai viskas. Klausimas lieka atviras: „kaip gauti komandos vykdymo rezultatą iš įrenginio“. Pažiūrėkime į užduotį naudodami komandą ifconfig kaip pavyzdį. Šią komandą galima išsiųsti į įrenginį:

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

kur:
message=`ifconfig` — komandos ifconfig išvesties rezultatą priskiriame kintamajam $message
wget "xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php - mūsų a.php scenarijus, kuris registruoja maršrutizatorius ir gauna iš jų pranešimus
u=vartotojas&p=slaptažodis!&m=$pranešimas — kredencialai ir užklausos kintamojo m reikšmė — priskiria $pranešimo kintamojo turinį
-O /tmp/out.txt - šiuo atveju mums nereikia išvesties į failą /tmp/out.txt, bet jei šis parametras nenurodytas, wget neveikia

Kodėl tai neveikia?Nes tai potenciali saugumo spraga. Pati nekenksmingiausia klaida, kuri gali atsitikti, jei, pavyzdžiui, jūsų komandos išvestyje yra simbolis „&“. Todėl reikia filtruoti ir viską, kas siunčiama iš maršrutizatorių, ir viską, kas ateina į serverį. Taip, man gėda, tikrai. Gindamasis galiu tik parašyti, kad visas straipsnis skirtas kaip valdyti maršrutizatorius su iš anksto nustatyta programine įranga ir komunikacijos kanalais, kurie nėra apibrėžti iš anksto.

Na, pradžia ateičiai: dar nesugalvojau, kaip naudoti standartinius zabbix įrankius, kad atspindėtų rezultatus (pavyzdžiui, komandos vykdymo rezultatą), kurie ateina į serverį.

Primenu, kad visus šaltinius galima gauti iš Git saugyklos adresu: github.com/BazDen/iotnet.online.git

Šaltinis: www.habr.com

Добавить комментарий