Fjärrövervakning och hantering av Linux/OpenWrt/Lede-baserade enheter via port 80, fortsättning

Detta är den sista delen av artikeln, här är början habr.com/en/post/445568
Förra gången jag skrev om hur jag implementerade enhetsövervakning, nu ska vi prata om hantering. I diskussioner med "tekniker" på kundens sida möter jag ofta en begränsad uppfattning om kapaciteten hos så små enheter (med låga minnesresurser och prestanda), många tror att "det mest vi behöver är att skicka en omstart, för något mer seriöst vi skickar ett team”.
Men praxis visar att detta inte är helt sant. Här är en liten lista över vanliga typiska uppgifter:

  1. Nätverksdiagnostik och felsökning. Bakom ethernetporten på din router finns det vanligtvis en annan hårdvara som har sin egen interna IP-adress. Ibland kan du (borde) "pinga" det. Eller tunnelhantering - om tunneln plötsligt inte reser sig på en router som fungerar via ett 3G-modem, men vi kan se själva routern.
  2. System underhåll. Firmwareuppdatering, serviceskriptuppgradering.
  3. Balansgång. Detta skulle kunna kallas "perversion", men begreppet "ekvilibrist" som, jag citerar, "en cirkusartists förmåga att upprätthålla balans i en instabil kroppsställning" - passar bättre. Sådana situationer uppstår på grund av kundens begränsade budget. Nedan gav jag ett par exempel, men... De är inte direkt relaterade till berättelsens tema, jag lägger dem i anteckningarna

Wi-Fi-övervakningEtt fashionabelt ämne de senaste fem åren, främst bland federala detaljhandelskedjor. Du promenerar lugnt genom handelsgolven, och din mobiltelefon med Wi-Fi påslagen, i ett försök att "hålla sig" till någon tråd i nätverket, skickar regelbundet ut Probe Request-paket, som kan analyseras för att beräkna för du: hur ofta kommer du till den här butiken, av vilka anledningar går du längs banor och så vidare. Sedan samlas data in, analyseras, värmekartor ritas och förvaltare ”pressar” pengar från ledningen eller investerare för sådana bilder. Nåväl, för nu... ”det finns inga pengar, men du håller i...”, och det (riktiga) resultatet måste redan visas, den gamla goda låten börjar: ”Ja, ja, då är det såklart kommer att installera cis och allt du vill, men nu måste vi visa kunden resultatet! Förresten, vi glömde att säga att kunden tillät oss att ansluta vår utrustning till sin hotspot via Wi-Fi, men på generell basis, precis som om vi vore gästkunder.” Och så måste vi göra balanserande routrar - flera WiFi-undergränssnitt höjs, varav ett klamrar sig fast vid hotspot, och det andra övervakar miljön, laddar frenetiskt upp tcpdump-resultatet till sig själv, packar sedan filens innehåll i ett arkiv och riskerar dör av "överätande" försöker spotta ut innehållet på FTP-servern. Det är inte förvånande att balanseringsroutern ofta "går sönder" och på något sätt måste "återupplivas" på distans.

RadieDet är lättare att beskriva situationen här med något i stil med detta uttalande från kunden: "Vi vill ha ett decentraliserat nätverk av hotspots som fungerar på utrustning vars modell inte är känd i förväg, via kanaler, men vilka vi ännu inte känner till. Åh, vi glömde att säga, vi vill inte bara visa reklam för kunder, utan också analysera allt runt platsen där hotspoten är installerad. Nej, vi vet inte varför ännu, men vi kommer att ta reda på det, tvivla inte på det, vi kunde komma på den här idén."

Och vi får inte glömma att på grund av många tidigare okända omständigheter måste kontroll utföras under icke-standardiserade förhållanden, när vi inte kan ansluta till routern direkt via IP:-porten och är tvungna att helt enkelt vänta på aktivitet från den. Om vi ​​abstraherar oss själva kan dialogen mellan servern och routern representeras så här:

  • Router: Hallå. Jag är en sådan och en router, finns det några uppgifter för mig?
  • Server: router så och så, jag registrerade dig, att du lever. Här är utmaningen: visa mig resultatet av ifconfig-kommandot?
  • Router: Hallå. Jag är en sådan och en router, senast du bad om att få visa resultatet av ifconfig, här är det. Finns det några uppgifter för mig?
  • Server: router så och så, jag registrerade dig, att du lever. Det finns inga uppgifter för dig.

Den mest intressanta frågan: hur kan en fjärrrouter skicka en viss mängd information? I den sista delen beskrev jag att på grund av begränsade resurser har routern bara en "avskalad" wget, som bara fungerar via GET och inget annat; det finns ingen FTP-klient eller curl. Mer exakt behöver vi en universell metod, oavsett funktionerna i bildmontering. Jag bestämde mig för att använda wget. Mer exakt, hur jag "stoppade" - jag hade helt enkelt inget val :)

Bara en ansvarsfriskrivningMin hanteringslösning fungerar, inte särskilt begränsad, och jag är säker på att den är sned, även om den passar de flesta av mina kunder. Hur skulle du kunna göra det på ett klokt sätt - skriv ett litet verktyg som skickar binär POST-data via port 80. Inkludera det (verktyget) i routerns firmware och få tillgång till det med bash. Men verkligheten är att: a) vi måste snabbt b) vi måste förmodligen göra allt på den befintliga "zoo av routrar" c) "göra ingen skada!" — om routern fungerar och utför andra uppgifter, försök att göra ändringar som inte påverkar den befintliga funktionaliteten.

Låt oss gå vidare till genomförandet. Låt oss säga att din kund vill starta om routern från zabbix enkelt och naturligt, med ett "klick med musen." Idag börjar vi beskriva implementeringen med Zabbix.
I menyn "Administration" -> "Skript", lägg till ett nytt skript. Vi kallar det "Starta om", ange "php /usr/share/zabbix/reboot.php {HOST.HOST}" som ett kommando

Fjärrövervakning och hantering av Linux/OpenWrt/Lede-baserade enheter via port 80, fortsättning

Nästa: Meny "Övervakning" -> "Senaste data" -> "Högerklicka på önskad nätverksnod." Så här kommer menyn att se ut efter att du har lagt till skriptet.

Fjärrövervakning och hantering av Linux/OpenWrt/Lede-baserade enheter via port 80, fortsättning
Följaktligen lägger vi reboot.php-skriptet i katalogen /usr/share/zabbix (din kan vara annorlunda, jag använder zabbixas rotkatalog).

SäkerhetsfriskrivningFör att göra förklaringen tydligare i skriptet använder jag bara router-id, men använder inte lösenordet. Det rekommenderas inte att göra detta i produktionsversionen! Varför gjorde jag detta: eftersom den stora frågan är var man lagrar lösenord för routrar? I zabbixe sig i "inventering data"? Kontroversiell praxis. Alternativt: begränsa extern åtkomst till själva filen reboot.php

Filen 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();
?>

Det är allt. Frågan är fortfarande öppen: "hur man får resultatet av att köra ett kommando från enheten." Låt oss titta på uppgiften med kommandot ifconfig som exempel. Detta kommando kan skickas till enheten:

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

, Var:
message=`ifconfig` — vi tilldelar resultatet av kommandot ifconfig till variabeln $message
wget"xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php — vårt a.php-skript som registrerar routrar och tar emot meddelanden från dem
u=användare&p=lösenord!&m=$meddelande — referenser och värdet på begäranvariabeln m — tilldelar innehållet i $message-variabeln
-O /tmp/out.txt — vi behöver inte utdata till filen /tmp/out.txt i det här fallet, men om denna parameter inte anges fungerar inte wget

Varför fungerar inte detta?För det är ett potentiellt säkerhetshål. Det mest ofarliga felet som kan hända är om det till exempel finns ett "&"-tecken i utmatningen av ditt kommando. Därför är det nödvändigt att filtrera både allt som skickas från routrar och allt som kommer till servern. Ja, jag skäms verkligen. Till mitt försvar kan jag bara skriva att hela artikeln ägnas åt hur man hanterar routrar med fördefinierad firmware och kommunikationskanaler som inte är definierade i förväg.

Nåväl, en början för framtiden: jag har ännu inte kommit på hur jag ska använda vanliga zabbix-verktyg för att återspegla resultaten (till exempel resultatet av att köra ett kommando) som kommer till servern.

Jag påminner dig om att alla källor kan erhållas från Git-förvaret på: github.com/BazDen/iotnet.online.git

Källa: will.com

Lägg en kommentar