Ceci est la partie finale de l'article, voici le début
La dernière fois, j'ai écrit sur la façon dont j'ai mis en place le suivi des appareils, maintenant nous allons parler de la gestion. Dans les discussions avec les « techniciens » du client, je me heurte souvent à une perception limitée des capacités de ces petits appareils (avec peu de mémoire et de puissance), beaucoup pensent que « le maximum que nous aurons besoin de faire est d'envoyer un reboot, pour quelque chose de plus sérieux, nous enverrons une équipe ».
Mais la pratique montre que ce n'est pas tout à fait vrai. Voici une petite liste de tâches typiques fréquentes :
- Diagnostic et dépannage réseau. Derrière le port Ethernet de votre routeur, un autre appareil « vit », qui a sa propre adresse IP interne. Parfois, il est possible (ou nécessaire) de le « pinger ». Ou gestion de tunnel - si le tunnel ne se lève pas sur le routeur fonctionnant via un modem 3G, mais que nous voyons le routeur.
- Maintenance système. Mise à jour du firmware, mise à niveau des scripts de service.
- Équilibre. Cela pourrait être appelé « des perversions », mais le terme « équilibre » selon, je cite, « la capacité d'un artiste de cirque à maintenir l'équilibre dans une position instable du corps » — convient mieux. De telles situations se produisent en raison de la limitation du budget du client. Ci-dessous, j'ai donné quelques exemples, mais comme ils n'ont pas de lien direct avec le sujet, je les ai mis en notes
Surveillance Wi-FiLe sujet à la mode ces cinq dernières années concerne principalement les chaînes de distribution fédérales. Vous vous promenez lentement dans les rayons, tandis que votre mobile avec le Wi-Fi activé tente périodiquement de se connecter à un réseau, envoyant des paquets de requêtes Probe que l'on peut analyser pour évaluer votre fréquence de visite dans ce magasin, les trajets que vous empruntez, etc. Ensuite, les données sont collectées, analysées, des cartes thermiques sont établies et les responsables obtiennent des financements de la direction ou des investisseurs au moyen de ces graphiques. Mais pour l'instant… "il n'y a pas d'argent, mais vous vous accrochez…", et le résultat (réel) doit déjà être montré, alors on remet en route la vieille chanson : "Oui, oui, nous mettrons bien entendu tout le nécessaire, mais en attendant, il faut prouver quelque chose au client! Au fait, nous avons oublié de mentionner, le client a autorisé notre équipement à se connecter à son hotspot via Wi-Fi, mais sur une base commune, juste comme si nous étions des clients invités." Et il faut alors concevoir des routeurs acrobates - plusieurs sous-interfaces Wi-Fi sont créées, dont l'une se connecte au hotspot, tandis que l'autre surveille l'environnement, exporte frénétiquement le résultat du tcpdump vers lui-même, puis compresse le contenu du fichier et, risquant d'"exploser" de surcharge, essaie de transférer le contenu sur un serveur FTP. Il n'est donc pas surprenant que le routeur acrobate "se fasse souvent prendre" et qu'il faille d'une manière ou d'une autre le "réanimer" à distance.
RadiusIl est plus simple de décrire la situation par cette déclaration du client : "Nous voulons un réseau décentralisé de hotspots qui fonctionnerait sur un matériel dont le modèle n'est pas connu à l'avance, par des canaux que nous ne savons pas encore. Ah, nous avons oublié de dire, nous voulons non seulement afficher des publicités aux clients, mais aussi analyser tout ce qui se passe autour du point d'installation du hotspot. Non, nous ne savons pas encore pourquoi, mais nous trouverons une raison, ne vous inquiétez pas, nous avons déjà réussi à concevoir cette idée"
Et il ne faut pas oublier qu'en raison de nombreux facteurs incertains à l'avance, la gestion doit s'effectuer dans des conditions non standard, lorsque nous ne pouvons pas nous connecter directement au routeur via IP : port et sommes contraints d'attendre simplement un signe d'activité de sa part. Si l'on abstrait, le dialogue entre le serveur et le routeur peut se représenter ainsi :
- Routeur: salut. Je suis le routeur tel quel, avez-vous des tâches pour moi ?
- Serveur: routeur tel quel, je t'ai enregistré, tu es vivant. Voici la tâche : peux-tu me montrer le résultat de la commande ifconfig ?
- Routeur: salut. je suis le routeur tel quel, la dernière fois tu m'as demandé de montrer le résultat d'ifconfig, le voici. Ai-je des tâches à accomplir ?
- Serveur: routeur tel quel, je t'ai enregistré, tu es vivant. Pas de tâches pour toi.
La question la plus intéressante : comment un routeur distant peut-il envoyer un certain volume d'informations ? Dans la partie précédente, j'ai décrit que sur le routeur, en raison de la limitation des ressources, il n'y a qu'un wget « allégé » qui ne fonctionne que via GET et rien de plus, il n'y a pas de client ftp ni de curl. Plus précisément, nous avons besoin d'un moyen universel, indépendamment des spécificités de la compilation de l'image. J'ai opté pour l'utilisation de wget. Plus précisément, enfin, comment dire « opté » — je n'avais tout simplement pas le choix 🙂
Tout d'abord, une précisionMa solution de gestion fonctionne, elle est relativement limitée et je suis convaincu - même si elle satisfait la plupart de mes clients. Comment cela pourrait être fait intelligemment - écrire un petit utilitaire qui envoie des données binaires via POST sur le port 80. L'intégrer dans le firmware du routeur et pouvoir y accéder via bash. Mais la réalité est la suivante : a) il faut agir rapidement b) il peut être nécessaire de tout faire sur le « zoo de routeurs » existant c) « ne pas nuire ! » - si le routeur fonctionne et réalise d'autres tâches, essaie de faire des modifications qui ne toucheront pas la fonctionnalité existante.
Passons à la mise en œuvre. Supposons que votre client souhaite redémarrer le routeur depuis zabbix facilement et sans effort, d'un « clic de souris ». Aujourd'hui, nous allons commencer la description de la mise en œuvre avec zabbix.
Dans le menu « Administration » -> « Scripts », nous ajoutons un nouveau script. Nous l'appelons « Reboot », et comme commande, nous écrivons « php /usr/share/zabbix/reboot.php {HOST.HOST} »
Ensuite : Menu « Surveillance » -> « Dernières données » -> « Clic droit sur le nœud réseau souhaité ». Voici à quoi ressemblera le menu après l'ajout du script.
Ainsi, nous plaçons le script reboot.php dans le répertoire /usr/share/zabbix (vous pouvez avoir un autre répertoire, j'utilise le répertoire racine de zabbix).
Précision pour la sécuritéPour clarifier l'explication dans le script, j'utilise uniquement l'ID du routeur, sans utiliser de mot de passe. Dans la version fonctionnelle, cela n'est pas recommandé ! Pourquoi ai-je fait ainsi : parce que la grande question est — où stocker les mots de passe des routeurs ? Dans le Zabbix, dans les « données d'inventaire » ? Pratique controversée. Une option : limiter l'accès externe au fichier reboot.php lui-même.
Fichier reboot.php
set_charset("utf8");
// "Envoyer" la commande reboot en modifiant le champ task de la table users. Dans le champ task, on peut envoyer n'importe quelle commande.
$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();
?>Voilà tout. La question ouverte est « comment obtenir le résultat de l'exécution de la commande du côté de l'appareil ». Considérons la tâche avec la commande ifconfig. Voici une commande que l'on peut envoyer à l'appareil :
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, où :
message=`ifconfig` — nous attribuons à la variable $message le résultat de la sortie de la commande ifconfig
wget " — notre script a.php, qui enregistre les routeurs et reçoit des messages d'eux
u=user&p=password!&m=$message — les informations d'identification et la valeur de la variable de requête m — attribue le contenu de la variable $message
-O /tmp/out.txt — la sortie dans le fichier /tmp/out.txt n'est pas nécessaire dans ce cas, mais si ce paramètre n'est pas indiqué, wget ne fonctionne pas
Pourquoi cela fonctionne-t-il malParce que c'est une faille de sécurité potentielle. L'erreur la plus innocente qui peut se produire est que dans la sortie de votre commande, par exemple, il y a un caractère „&“. Par conséquent, il faut filtrer tout ce qui est envoyé par les routeurs et tout ce qui arrive sur le serveur. Oui, j'ai honte, vraiment. En ma défense, je ne peux que dire — que tout l'article est consacré à la façon de gérer les routeurs avec un firmware indéterminé à l'avance, avec des canaux de communication indéterminés à l'avance.
Et cela prépare l'avenir : je n'ai pas encore compris comment refléter les résultats (par exemple, le résultat de l'exécution d'une commande) qui arrivent sur le serveur avec les outils standards de Zabbix.
Je rappelle que tous les fichiers sources peuvent être récupérés depuis le dépôt Git à l'adresse :
Source : habr.com
