Ovo je završni deo članka, evo početka
Prošli put sam pisao o tome kako sam realizovao praćenje uređaja, sada ćemo govoriti o upravljanju. U diskusijama sa „tehničarima“ s druge strane, često se susrećem s ograničenim razumevanjem mogućnosti takvih malih uređaja (s niskim resursima memorije i performansi), mnogi smatraju da je „maksimum što nam treba slanje reboot-a, za nešto ozbiljnije — poslaćemo ekipu.“
Ali praksa pokazuje da to nije sasvim tačno. Evo malog popisa čestih tipičnih zadataka:
- Mrežna dijagnostika i otklanjanje grešaka. Iza ethernet porta vašeg routera obično „živi“ druga oprema, koja ima svoju internu ip adresu. Ponekad, treba je „pingati“. Ili upravljanje tunelom — ako na routeru koji radi preko 3G modema iznenada ne uspostavi tunel, a sam router vidimo.
- Sistemsko održavanje. Ažuriranje firmvera, nadogradnja servisnih skripti.
- Ekvilibristika. Ovo bi se moglo nazvati „izvrnutim stvarima“, ali pojam „ekvilibristika“ kao, citiram, „sposobnost cirkuske umetnice da održi ravnotežu u nestabilnom položaju tela“ — više odgovara. Slične situacije nastaju zbog ograničenosti budžeta naručioca. U nastavku sam naveo nekoliko primera, ali pošto nemaju direktne veze sa temom, izdvojio sam ih u napomenu
Wi-Fi praćenjeModerna tema koja je pet godina popularna, prvenstveno među federalnim mrežama maloprodaje. Polako šetate trgovinama dok vaš mobilni uređaj s uključenim Wi-Fi-em pokušava „priključiti“ neku mrežu, redovito šaljući Probe Request pakete koji se mogu analizirati kako bi se utvrdilo koliko često dolazite u ovu prodavaonicu, koji putanjama se krećete i slično. Dalje se podaci prikupljaju, analiziraju, stvaraju se toplotne karte i menadžeri na temelju tih slika „dobivaju“ novac od uprave ili investitora. A dok... „nema novca, ali vi se držite...“, a rezultat (stvarni) već treba pokazati, uključuje se stara dobra pjesma „Da, da, naravno, postavit ćemo ciske i sve što želite, ali sada moramo pokazati naručitelju rezultat! Usput, zaboravili smo reći, naručitelj je dozvolio da naše opreme povežemo s njegovim hot spotom putem wifi-a, ali na zajedničkom osnovu, jednostavno kao da smo gosti.“ I tako imamo routere-žonglere - podiže se nekoliko WiFi subinterfejsa, jedan od njih povezuje s hot spotom, a drugi nadgleda okolinu, očajnički prebacuje tcpdump rezultate u sebe, zatim sadržaj datoteke pakira u arhivu i, riskirajući „prejedanje“, pokušava ispljunuti sadržaj na ftp server. Nije iznenađujuće da se router-žongler često „sruši“ i mora se na neki način daljinski „oživjeti“.
RadiusOvdje situaciju možemo opisati jednostavno ovim izjavom naručitelja: „Želimo decentraliziranu mrežu hot spotova koja bi radila na opremi čiji model unaprijed nije poznat, preko kanala, ali koje još ne znamo. Ah, zaboravili smo reći, ne želimo samo prikazivati reklame klijentima, već i analizirati sve oko mjesta postavljanja hot spot-a. Ne, još ne znamo zašto, ali smislit ćemo, ne sumnjajte, uspjeli smo smisliti ovu ideju“
I ne smijemo zaboraviti da zbog niza unaprijed neodređenih okolnosti, upravljanje treba provoditi u nekonvencionalnim uvjetima, kada se ne možemo izravno povezati s routerom putem ip: porta i prisiljeni smo jednostavno čekati na manifestaciju aktivnosti s njegove strane. Ako se abstrahiramo, dijalog između servera i routera može se predstaviti ovako:
- Router: pozdrav. ja sam router, imaš li za mene zadatke?
- Server: Router such-and-such, I have registered you, so you are alive. Here is the task: show me the result of the ifconfig command?
- Router: Hello. I am router such-and-such, last time you asked me to show the result of ifconfig, here it is. Do you have any tasks for me?
- Server: Router such-and-such, I have registered you, so you are alive. There are no tasks for you.
The most interesting question is: how can the remote router send a specific amount of information? In the previous part, I described that due to resource limitations on the router, there is only a 'trimmed' wget that works only via GET and nothing else; there is no FTP client or curl. More precisely, we need a universal way, regardless of the specifics of the image assembly. I settled on using wget. Actually, well, how should I say 'settled' — I simply had no choice 🙂
A quick caveatMy management solution is functional, somewhat limited, and I am sure — crude, even if it satisfies most of my clients. How it could be done properly would be to write a small utility that sends binary data via POST through port 80. To include this utility in the router's firmware and to interact with it using bash. But the reality is that: a) it needs to be done quickly b) possibly all tasks need to be done on the existing 'zoo of routers' c) 'do no harm!' — if the router is working and performing other tasks, try to make changes that do not affect existing functionality.
Let's move on to the implementation. Suppose your client wants to restart the router from zabbix easily and effortlessly, with 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 as the command we write 'php /usr/share/zabbix/reboot.php {HOST.HOST}'
Next: Menu 'Monitoring' -> 'Latest Data' -> 'Right-click on the required 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 am using the root directory of zabbix).
Caveat for safetyZa jasno objašnjenje u skripti koristim samo ID usmjerivača, ali ne koristim lozinku. U radnoj verziji to nije preporučljivo! Zašto? Zato što je veliko pitanje - gdje čuvati lozinke za usmjerivače? U samom Zabbixu u "inventar podacima"? Protivrječna praksa. Kao opcija: ograničiti vanjski pristup samom datoteci reboot.php
Datoteka reboot.php
set_charset("utf8");
// "Šaljemo" komandu reboot izmjenom polja task u tablici users. U polju task možemo slati bilo koju komandu.
$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 to. Otvoren je još uvijek pitanje „kako dobiti rezultat izvršenja komande sa strane uređaja“. Razmotrimo zadatak na primjeru s komandom ifconfig. Takvu komandu možemo poslati uređaju:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, gdje:
message=`ifconfig` — varijabli $message dodjeljujemo rezultat izlaza komande ifconfig
wget " — naš skript a.php, koji registrira usmjerivače i prima poruke od njih
u=user&p=password!&m=$message — vjerodajnice i vrijednosti varijable zahtjeva m — dodjeljuje sadržaj varijable $message
-O /tmp/out.txt — ispis u datoteku /tmp/out.txt nam u ovom slučaju nije potreban, ali ako ovaj parametar ne navedemo, wget ne radi
Zašto ovo ne funkcionira kako treba?Zato što to predstavlja potencijalnu sigurnosnu rupu. Najbezazlenija greška koja se može dogoditi je ako u izlazu vaše komande bude simbol „&“. Stoga je važno filtrirati sve što se šalje s usmjerivača i sve što dolazi na server. Da, sramim se, zaista. Na svoju obranu mogu samo napisati — da je cijeli članak posvećen tome kako upravljati usmjerivačima s unaprijed neodređenim firmwareom, s unaprijed neodređenim komunikacijskim kanalima.
A potential future project: I haven't figured out yet how to reflect results (like command execution outcomes) that come to the server using standard Zabbix tools.
Just a reminder that all source files can be retrieved from the Git repository at the following address:
Izvor: habr.com
