Dit is het laatste deel van het artikel, hier is het begin
Laatstelijk schreef ik over hoe ik het apparaatmonitoring implementeerde, nu gaat het over beheer. In discussies met 'technici' van de Opdrachtgever kom ik vaak een beperkte perceptie tegen van de mogelijkheden van dergelijke kleine apparaten (met beperkte geheugenbronnen en prestaties); velen denken dat 'het maximum wat we nodig hebben is om een reboot te versturen, voor iets serieus sturen we een team'.
Maar de praktijk leert dat dit niet helemaal waar is. Hier is een korte lijst van veelvoorkomende typische taken:
- Netwerkdiagnose en probleemoplossing. Achter de ethernetpoort van uw router 'woont' meestal een ander apparaat, dat een eigen intern ip-adres heeft. Soms is het nodig (of nuttig) om het apparaat te 'pingen'. Of tunnelbeheer â als de tunnel op de router die via een 3G-modem werkt plots niet opkomt, maar we de router nog wel zien.
- Systeemonderhoud. Firmware-updates, upgrades van hulpscripts.
- Equilibristiek. Dit zou je 'verdraaiingen' kunnen noemen, maar het begrip 'equilibristiek', zoals ik citeer, âde vaardigheid van een circusartist om het evenwicht te bewaren in een onzekere lichaamshoudingâ â past beter. Dit soort situaties komt voor vanwege de beperkte budgetten van de opdrachtgever. Hieronder heb ik een paar voorbeelden gegeven, maar omdat ze niet direct gerelateerd zijn aan het onderwerp, heb ik ze in de notities geplaatst.
Wi-Fi monitoringDe laatste vijf jaar is er een trendy onderwerp, vooral onder de federale retailketens. Je wandelt lauw door de winkels, terwijl je mobiel met ingeschakelde Wi-Fi probeert verbinding te maken met een of ander netwerk en regelmatig Probe Request-pakketten verzendt, die kunnen worden geanalyseerd om je te tellen: hoe vaak je deze winkel bezoekt, welke routes je loopt, enzovoort. Vervolgens worden de gegevens verzameld, geanalyseerd, en worden er heatmaps gemaakt waarmee managers geld van het management of investeerders proberen te verkrijgen. En ondertussen... "er is geen geld, maar houd vol...", terwijl het resultaat (in werkelijkheid) al moet worden getoond, start het oude bekende liedje "Ja, ja, later plaatsen we natuurlijk alles wat je maar wilt, maar nu moeten we een resultaat aan de Klant laten zien! Trouwens, we zijn vergeten te zeggen dat de Klant toestemming heeft gegeven om onze apparatuur aan zijn hotspot via Wi-Fi te verbinden, maar op een gezamenlijke basis, gewoon alsof we gasten zijn." En zo worden er router-equilibristen gemaakt - er worden verschillende WiFi-subreeksen opgezet, waarvan er een verbinding maakt met de hotspot, terwijl de andere de omgeving monitort, wanhopig de tcpdump-resultaten in zichzelf afvoert, vervolgens de inhoud van het bestand in een archief verpakt en, riskerend om te 'overeten', probeert de inhoud naar de ftp-server uit te spugen. Het is niet verwonderlijk dat de router-equilibrist vaak 'afhaakt' en op de een of andere manier op afstand 'geheranimeerd' moet worden.
RadiusHier kan de situatie worden beschreven met de volgende uitspraak van de klant: "We willen een gedecentraliseerd netwerk van hotspots die moeten werken op apparatuur waarvan het model van tevoren niet bekend is, via kanalen die we nog niet kennen. Oh, we zijn vergeten te vermelden dat we niet alleen reclame aan klanten willen tonen, maar ook alles rondom de plek van installatie van de hotspot willen analyseren. Nee, we weten nog niet waarom, maar we zullen het bedenken, twijfel er niet aan, we hebben immers deze idee kunnen bedenken."
En we moeten niet vergeten dat door de massa onzekere omstandigheden die van tevoren bekend zijn, het beheer moet plaatsvinden onder niet-standaardomstandigheden, wanneer we ons niet rechtstreeks via ip: poort met de router kunnen verbinden en eenvoudigweg moeten wachten tot er activiteit van hem komt. Als we ons abstraheren, kan de dialoog tussen de server en de router als volgt worden voorgesteld:
- Router: hallo. ik ben router x, zijn er taken voor mij?
- Server: router zo en zo, ik heb je geregistreerd, dus je werkt. Hier is de taak: laat me het resultaat van het ifconfig-commando zien?
- Router: hallo. ik ben router zo en zo, de vorige keer vroeg je om het resultaat van ifconfig, hier is het. Heb je taken voor mij?
- Server: router zo en zo, ik heb je geregistreerd, dus je werkt. Er zijn geen taken voor jou.
De interessantste vraag is: hoe kan een externe router een bepaalde hoeveelheid informatie verzenden? In het vorige deel beschreef ik dat op de router vanwege beperkte middelen alleen een "gereduceerde" wget werkt, die alleen via GET functioneert en verder niets, er is geen ftp-client of curl. Sterker nog, we hebben een universele manier nodig, ongeacht de specifieke kenmerken van de image-build. Ik stopte met het gebruik van wget. Sterker nog, âstopteâ is misschien niet het juiste woord â ik had gewoon geen keuze đ
Een eerste opmerkingMijn oplossing voor beheer werkt, is niet te beperkt en ik ben ervan overtuigd â het is rommelig, zelfs als het de meeste van mijn klanten bevalt. Hoe het slimmere alternatief eruit zou zien â schrijf een kleine utility die via poort 80 binaire gegevens via POST verstuurt. Voeg deze utility toe aan de firmware van de router en benader deze via bash. Maar de realiteit is: a) snel zijn b) mogelijk alles doen op de bestaande âzoo van routersâ c) âdoe geen kwaad!â â als de router werkt en andere taken uitvoert, probeer wijzigingen aan te brengen die de bestaande functionaliteit niet aantasten.
Laten we overgaan tot implementatie. Stel dat uw klant vanuit zabbix de router eenvoudig en zonder moeite wil herstarten, met Ă©Ă©n muisklik. Vandaag beginnen we de implementatiebeschrijving vanuit zabbix.
In het menu âBeheerâ -> âScriptsâ voegen we een nieuw script toe. We noemen het âRebootâ, en als commando schrijven we âphp /usr/share/zabbix/reboot.php {HOST.HOST}â
Vervolgens: Menu âMonitoringâ -> âLaatste gegevensâ -> âRechtermuisklik op de gewenste netwerkknoopâ. Zo zal het menu eruitzien na het toevoegen van het script.
Uiteraard plaatsen we het script reboot.php in de map /usr/share/zabbix (de jouwe kan anders zijn, ik gebruik de hoofdmap van zabbix).
Opmerking voor de veiligheidVoor de duidelijkheid in de uitleg in het script gebruik ik alleen de id van de router, maar gebruik ik geen wachtwoord. In de werkversie is dit niet aan te raden! Waarom ik het zo heb gedaan: omdat er een grote vraag is â waar de wachtwoorden van de routers te bewaren? In de âinventarisgegevensâ van zabbix? Tegenstrijdige praktijk. Een optie is om de toegang van buitenaf tot het bestand reboot.php te beperken.
Bestand reboot.php
set_charset("utf8");
// We âversturenâ het reboot-commando door het veld task van de tabel users te wijzigen. In het veld task kunnen we elk commando versturen.
$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();
?>Dat is alles. De open vraag blijft âhoe we het resultaat van de uitvoering van het commando van het apparaat kunnen ontvangenâ. Laten we de taak onderzoeken met het commando ifconfig. Dit is een commando dat we naar het apparaat kunnen sturen:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, waar:
message=`ifconfig` â we wijzen de variabele $message de uitvoer van het commando ifconfig toe
wget « â ons script a.php, dat routers registreert en berichten van hen ontvangt
u=user&p=password!&m=$message â gebruiksgegevens en de waarde van de aanvraagparameter m â wijst de inhoud van de variabele $message toe
-O /tmp/out.txt â de uitvoer naar het bestand /tmp/out.txt is in dit geval niet nodig, maar als deze parameter niet wordt opgegeven, werkt wget niet
Waarom werkt dit krom?Omdat dit een potentiĂ«le beveiligingslek is. De minst onschuldige fout die kan optreden is als het teken â&â in de uitvoer van uw commando voorkomt. Daarom is het nodig om te filteren wat met de routers wordt verzonden en wat op de server aankomt. Ja, ik schaam me, echt. Als rechtvaardiging kan ik alleen zeggen â dat het gehele artikel is gewijd aan hoe routers te beheren met een onbekende firmware en onbekende verbindingskanalen.
En ook een toekomstgerichte aanpak: ik heb nog niet uitgevonden hoe ik met de standaard middelen van Zabbix de resultaten (bijvoorbeeld het resultaat van de uitvoering van een commando) die op de server aankomen kan weergeven.
Ik herinner je eraan dat alle bronbestanden gedownload kunnen worden vanuit de Git-repository, op het adres:
Bron: habr.com
