Questa è la parte finale dell'articolo, ecco l'inizio
L'ultima volta ho scritto di come ho implementato il monitoraggio dei dispositivi, ora parleremo di gestione. Nelle discussioni con i 'tecnici' da parte del Cliente, mi imbatto spesso in una percezione limitata delle capacità di questi piccoli dispositivi (con risorse di memoria e prestazioni modeste); molti ritengono che 'l'unica cosa di cui abbiamo bisogno sia inviare un reboot, per qualcosa di più serio - invieremo una squadra.'
Ma la pratica dimostra che non è proprio così. Ecco un piccolo elenco di compiti tipici frequenti:
- Diagnosi e risoluzione di rete. Dietro la porta ethernet del vostro router c'è di solito un altro dispositivo che ha il suo indirizzo IP interno. A volte, può essere (deve essere) 'pingato'. O gestione del tunnel - se sul router, che lavora tramite un modem 3G, all'improvviso il tunnel non si alza, ma vediamo comunque il router.
- Manutenzione del sistema. Aggiornamento del firmware, upgrade degli script di servizio.
- Equilibrismo. Si potrebbe definire come 'deviazioni', ma il concetto di 'equilibrista', come cito, ‘abilità di un artista circense di mantenere l'equilibrio in una posizione instabile del corpo’ si adatta meglio. Queste situazioni si presentano a causa delle limitazioni di budget del cliente. Qui di seguito ho riportato un paio di esempi, ma poiché non hanno una relazione diretta con il tema trattato, li ho posti in nota.
Monitoraggio Wi-FiNegli ultimi cinque anni, il tema è diventato molto popolare soprattutto tra le catene di retail federali. Passeggiate tranquillamente nei negozi, mentre il vostro smartphone, con il Wi-Fi attivato, cerca di connettersi a qualche rete, inviando regolarmente pacchetti Probe Request che possono essere analizzati per capire: quanto spesso visitate questo negozio, quali percorsi seguite e così via. Successivamente, i dati vengono raccolti, analizzati e si creano mappe di calore; i manager utilizzano queste immagini per ottenere fondi dai loro superiori o investitori. Ma nel frattempo... "non ci sono soldi, ma continuate a resistere...", e il risultato (reale) deve già essere mostrato, si ripete la vecchia canzone "Sì, sì, poi installeremo ovviamente i gadget che desiderate, ma ora dobbiamo mostrare al Cliente il risultato! A proposito, abbiamo dimenticato di dire che il Cliente ha consentito di collegare il nostro equipaggiamento al proprio hotspot via Wi-Fi, ma in modo comune, come se fossimo semplici clienti ospiti." Così, ci troviamo a dover creare router equilibristi: si attivano diversi sottinterfacce Wi-Fi, di cui una si connette all'hotspot e l'altra monitora l'ambiente, scaricando freneticamente i risultati di tcpdump su se stesso; poi, il contenuto del file viene compresso in un archivio e, rischiando di "morire di eccesso di dati", cerca di caricare il contenuto su un server FTP. Non sorprende che il router equilibrista spesso "fallisca" e debba essere "rianimato" in remoto.
RaggioQui la situazione può essere descritta più semplicemente con la seguente affermazione del cliente: «Vogliamo una rete decentralizzata di hotspot che funzioni su apparecchiature di modello non noto a priori, attraverso canali che non conosciamo ancora. Ah, abbiamo dimenticato di dire che oltre a mostrare pubblicità ai clienti, vogliamo anche analizzare tutto ciò che circonda il luogo di installazione dell'hotspot. No, non sappiamo ancora perché, ma lo scopriremo, non preoccupatevi, siamo stati in grado di elaborare questa idea»
E non dobbiamo dimenticare che a causa di molte circostanze impreviste, la gestione deve svolgersi in condizioni non standard, quando non possiamo connetterci direttamente al router tramite ip: porta e siamo costretti ad aspettare che si manifesti un'attività. Astrattamente, il dialogo tra server e router può essere rappresentato in questo modo:
- Router: ciao. Sono il router tale, hai incarichi per me?
- Server: router tale, ti ho registrato, sei attivo. Ecco l'incarico: mostrami il risultato del comando ifconfig?
- Router: ciao. Sono il router tale, l'ultima volta hai chiesto di mostrarti il risultato di ifconfig, ecco qui. Hai incarichi per me?
- Server: ho registrato il router tal dei tali, quindi sei attivo. Non ci sono compiti per te.
La domanda più interessante è: in che modo un router remoto può inviare un certo volume di informazioni? Nella parte precedente ho descritto che sul router, a causa dei limiti delle risorse, è presente solo una versione 'ridotta' di wget, che funziona solo tramite GET e nient'altro; non ci sono client FTP né curl. Piuttosto, abbiamo bisogno di un metodo universale, indipendentemente dalle specifiche del sistema. Ho optato per l'utilizzo di wget. In effetti, come ho 'optato' — in realtà non avevo scelta 🙂
Una nota preliminareLa mia soluzione di gestione funziona, è piuttosto limitata e sono sicuro che sia imperfetta, anche se soddisfa la maggior parte dei miei clienti. Come si potrebbe fare in modo più intelligente? Scrivere una piccola utility che invii dati binari via POST attraverso la porta 80. Integrarla nel firmware del router e poi interagirci tramite bash. Ma la realtà è che: a) è necessario farlo rapidamente, b) potrebbe essere necessario effettuare tutto con il "parco di router" esistente, c) "non nuocere!" — se il router funziona e svolge altre attività, cerca di apportare modifiche che non compromettano le funzionalità esistenti.
Passiamo all'implementazione. Supponiamo che il tuo cliente voglia riavviare il router facilmente da Zabbix, con un semplice "clic di un mouse". Oggi inizieremo la descrizione dell'implementazione con Zabbix.
Nel menu "Amministrazione" -> "Script" aggiungiamo un nuovo script. Lo chiamiamo "Reboot" e come comando scriviamo "php /usr/share/zabbix/reboot.php {HOST.HOST}".
Successivamente: Menu "Monitoraggio" -> "Dati recenti" -> "Clic destro sul nodo di rete desiderato". Ecco come apparirà il menu dopo aver aggiunto lo script.
Pertanto, il file script reboot.php deve essere collocato nella directory /usr/share/zabbix (può variare nel vostro caso, io utilizzo la directory radice di zabbix).
Clausola di sicurezzaPer chiarezza, nello script utilizzo solo l'ID del router, evitando di usare la password. Nella versione definitiva non è consigliato fare così! Il motivo è: dove conservare le password dei router? Nei 'dati di inventario' di zabbix? È una pratica controversa. Una soluzione è limitare l'accesso esterno al file reboot.php.
File reboot.php
set_charset("utf8");
// "Inviamo" il comando reboot modificando il campo task della tabella users. Nel campo task si possono inviare comandi qualsiasi.
$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();
?>Ecco fatto. Resta da chiarire come ottenere il risultato dell'esecuzione del comando dal dispositivo. Analizziamo la questione con il comando ifconfig. È possibile inviare al dispositivo questo comando:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, dove:
message=`ifconfig` — alla variabile $message assegniamo il risultato dell'output del comando ifconfig
wget « — il nostro script a.php, che registra i router e riceve i messaggi da essi
u=user&p=password!&m=$message — le credenziali e il valore della variabile della richiesta m — assegna il contenuto della variabile $message
-O /tmp/out.txt — l'output nel file /tmp/out.txt in questo caso non è necessario, ma se non si specifica questo parametro, wget non funziona
Perché non funziona benePerché rappresenta una potenziale vulnerabilità di sicurezza. L'errore più innocuo che può verificarsi è che nell'output del tuo comando ci sia ad esempio il simbolo „&“. Pertanto, è necessario filtrare tutto ciò che viene inviato dai router e tutto ciò che arriva al server. Sì, mi vergogno, davvero. A mio favore posso solo dire che l'intero articolo è dedicato a come gestire i router con firmware non definito in anticipo e canali di comunicazione non definiti.
E un'idea per il futuro: finora non ho capito come riflettere i risultati (ad esempio il risultato dell'esecuzione di un comando) che arrivano al server con gli strumenti standard di Zabbix.
Ricordo che tutte le sorgenti possono essere prelevate dal repository Git all'indirizzo:
Fonte: habr.com
