Continua il monitoraggio e la gestione remota dei dispositivi basati su Linux/OpenWrt/Lede tramite la porta 80

Questa è la parte finale dell'articolo, ecco l'inizio habr.com/en/post/445568
L'ultima volta che ho scritto su come ho implementato il monitoraggio dei dispositivi, ora parleremo della gestione. Nelle discussioni con i “tecnici” dalla parte del Cliente, spesso incontro una percezione limitata delle capacità di dispositivi così piccoli (con risorse di memoria e prestazioni limitate), molti credono che “il massimo di cui abbiamo bisogno è inviare un riavvio, per qualcosa di più sul serio manderemo una squadra” .
Ma la pratica dimostra che questo non è del tutto vero. Ecco un piccolo elenco di attività tipiche comuni:

  1. Diagnostica di rete e risoluzione dei problemi. Dietro la porta Ethernet del router di solito c'è un altro componente hardware che ha il proprio indirizzo IP interno. A volte, puoi (dovresti) “pingarlo”. Oppure la gestione del tunnel: se il tunnel improvvisamente non si alza su un router che funziona tramite un modem 3G, ma possiamo vedere il router stesso.
  2. Sistema in manutenzione. Aggiornamento del firmware, aggiornamento dello script di servizio.
  3. Atto di equilibrio. Questa potrebbe chiamarsi “perversione”, ma il concetto di “equilibrista” come, cito, “la capacità di un artista circense di mantenere l’equilibrio in una posizione del corpo instabile” - si adatta meglio. Tali situazioni sorgono a causa del budget limitato del cliente. Qui sotto ho fatto un paio di esempi, ma... Non sono direttamente legati al tema del racconto, li metto nelle note

Monitoraggio Wi-FiUn argomento di moda negli ultimi cinque anni, soprattutto tra le catene di vendita al dettaglio federali. Stai passeggiando tranquillamente per le sale di negoziazione e il tuo telefono cellulare con il Wi-Fi acceso, nel tentativo di "attaccarsi" a qualche thread della rete, invia regolarmente pacchetti di richiesta di sonda, che possono essere analizzati per calcolare tu: quanto spesso vieni in questo negozio, per quali motivi? percorri delle traiettorie e così via. Quindi i dati vengono raccolti, analizzati, vengono disegnate mappe di calore e i manager “estorcono” denaro dal management o dagli investitori per tali immagini. Ebbene per ora.... “soldi non ci sono, ma tenete duro...”, e il risultato (vero) è già da mostrare, inizia la cara vecchia canzone: “Sì, sì, poi certo che installeremo il cis e tutto quello che vorrete, ma ora bisogna mostrare al Cliente il risultato! A proposito, ci siamo dimenticati di dire che il Cliente ci ha permesso di connettere le nostre apparecchiature al suo hotspot tramite Wi-Fi, ma in modo generale, proprio come se fossimo clienti ospiti.” E quindi dobbiamo creare router di bilanciamento: vengono generate diverse sottointerfacce WiFi, una delle quali si aggrappa all'hotspot e la seconda monitora l'ambiente, carica freneticamente il risultato tcpdump su se stessa, quindi comprime il contenuto del file in un archivio e rischia morendo per “mangiare troppo” tenta di sputare il contenuto sul server FTP. Non sorprende che il router di bilanciamento spesso “si rompa” e debba in qualche modo essere “rianimato” da remoto.

RaggioÈ più semplice descrivere la situazione qui con qualcosa di simile a questa dichiarazione del cliente: “Vogliamo una rete decentralizzata di hotspot che funzioni su apparecchiature di cui non si conosce in anticipo il modello, attraverso canali, ma quali non conosciamo ancora. Oh, abbiamo dimenticato di dire che non vogliamo solo mostrare pubblicità ai clienti, ma anche analizzare tutto ciò che riguarda il luogo in cui è installato l'hotspot. No, non sappiamo ancora perché, ma lo scopriremo, non dubitare, siamo riusciti ad avere questa idea”.

E non dobbiamo dimenticare che, a causa di molte circostanze precedentemente sconosciute, il controllo deve essere effettuato in condizioni non standard, quando non possiamo connetterci al router direttamente tramite la porta IP: e siamo costretti ad attendere semplicemente l'attività da esso. Se ci astraiamo, il dialogo tra server e router può essere rappresentato così:

  • Router: Ciao. Sono un router del genere, ci sono dei compiti per me?
  • Server: router tale e tale, ti ho registrato, che sei vivo. Ecco la sfida: mostrami il risultato del comando ifconfig?
  • Router: Ciao. Sono un router del genere, l'ultima volta che hai chiesto di mostrare il risultato di ifconfig, eccolo qui. Ci sono compiti per me?
  • Server: router tale e tale, ti ho registrato, che sei vivo. Non ci sono compiti per te.

La domanda più interessante: come può un router remoto inviare una certa quantità di informazioni? Nell'ultima parte ho descritto che, a causa delle risorse limitate, il router ha solo un wget “ridotto”, che funziona solo tramite GET e nient'altro; non c'è client FTP o curl. Più precisamente, abbiamo bisogno di un metodo universale, indipendentemente dalle caratteristiche dell'assemblaggio dell'immagine. Ho deciso di usare wget. Più precisamente, come mi sono "fermato" - semplicemente non avevo scelta :)

Solo una dichiarazione di non responsabilitàLa mia soluzione gestionale funziona, non è molto limitata e sono sicuro che sia corrotta, anche se si adatta alla maggior parte dei miei clienti. Come potresti farlo saggiamente: scrivi una piccola utility che invia dati binari POST attraverso la porta 80. Includilo (l'utilità) nel firmware del router e accedi utilizzando bash. Ma la realtà è che: a) dobbiamo fare in fretta b) probabilmente dobbiamo fare tutto sullo “zoo di router” esistente c) “non nuocere!” — se il router funziona ed esegue altre attività, provare ad apportare modifiche che non influiscano sulla funzionalità esistente.

Passiamo alla realizzazione. Supponiamo che il tuo cliente desideri riavviare il router da zabbix in modo semplice e naturale, con un "clic del mouse". Oggi inizieremo a descrivere l'implementazione con Zabbix.
Nel menu “Amministrazione” -> “Script”, aggiungi un nuovo script. Lo chiamiamo "Reboot", inserisci "php /usr/share/zabbix/reboot.php {HOST.HOST}" come comando

Continua il monitoraggio e la gestione remota dei dispositivi basati su Linux/OpenWrt/Lede tramite la porta 80

Successivamente: Menu “Monitoraggio” -> “Dati più recenti” -> “Fare clic con il tasto destro del mouse sul nodo di rete desiderato”. Ecco come apparirà il menu dopo aver aggiunto lo script.

Continua il monitoraggio e la gestione remota dei dispositivi basati su Linux/OpenWrt/Lede tramite la porta 80
Di conseguenza, inseriamo lo script reboot.php nella directory /usr/share/zabbix (il tuo potrebbe essere diverso, io utilizzo la directory root di zabbixa).

Dichiarazione di non responsabilità sulla sicurezzaPer rendere più chiara la spiegazione nello script, utilizzo solo l'ID del router, ma non utilizzo la password. Non è consigliabile farlo nella versione di produzione! Perché l'ho fatto: perché la grande domanda è dove archiviare le password per i router? Nello stesso zabbixe nei “dati di inventario”? Pratica controversa. In alternativa: limitare l'accesso esterno al file reboot.php stesso

File riavvio.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();
?>

È tutto. Resta aperta la questione: “come ottenere il risultato dell’esecuzione di un comando dal dispositivo”. Diamo un'occhiata all'attività utilizzando il comando ifconfig come esempio. Questo comando può essere inviato al dispositivo:

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

, dove:
messaggio=`ifconfig` — assegniamo il risultato dell'output del comando ifconfig alla variabile $message
wget "xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php — il nostro script a.php che registra i router e riceve messaggi da essi
u=utente&p=password!&m=$messaggio — credenziali e valore della variabile di richiesta m — assegna il contenuto della variabile $message
-O /tmp/uscita.txt — in questo caso non abbiamo bisogno dell'output nel file /tmp/out.txt, ma se questo parametro non è specificato, wget non funziona

Perché questo non funziona?Perché è una potenziale falla di sicurezza. L'errore più innocuo che può verificarsi è se, ad esempio, è presente un carattere "&" nell'output del comando. Pertanto, è necessario filtrare sia tutto ciò che viene inviato dai router sia tutto ciò che arriva al server. Sì, mi vergogno, davvero. A mia discolpa posso solo scrivere che l'intero articolo è dedicato a come gestire router con firmware predefinito e canali di comunicazione non definiti a priori.

Bene, un inizio per il futuro: non ho ancora capito come utilizzare gli strumenti standard di Zabbix per riflettere i risultati (ad esempio, il risultato dell'esecuzione di un comando) che arrivano al server.

Ti ricordo che tutti i sorgenti possono essere ottenuti dal repository Git all'indirizzo: github.com/BazDen/iotnet.online.git

Fonte: habr.com

Aggiungi un commento