Surveiller le réseau sur un serveur Linux

Twitter Facebook Google Plus Linkedin email
closeCet article a été publié il y a 4 ans 6 mois 9 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées, les commandes ne sont peut-être plus valides.

Vous avez lu avec attention ma réflexion sur la possession et la tenue d’un serveur perso, et vous avez été conquis. Bien, mais vous n’êtes pas non plus devenu ingénieur du jour au lendemain (moi non plus, et je ne le suis toujours pas), et vous aimeriez bien en savoir un peu plus sur ce que fait cette bête qui vous parait encore un peu étrange, et que vous n’avez pas encore complètement apprivoisée.

Parmi les choses que vous voudriez savoir, puisque c’est une machine connectée au réseau, ce qu’elle consomme comme réseau, voire ce que vos appareils demandent à votre serveur par le réseau, bref, comment et à quel point votre machine communique avec les autres. Il y a plein d’outils pour ça, c’est cool non ?

L’occasion de reparler vite fait des net-tools

Sous Debian, ce paquet permet d’avoir à disposition les vénérables commandes que sont netstat, ifconfig, route, et d’autres, qu’on retrouve dans un nombre incalculable d’articles sur le Web. Ces commandes, bien qu’elles soient toujours fonctionnelles, sont « abandonnées » depuis quelques années maintenant, et certains zélotes vous hurleront dessus si vous les utilisez encore. Ils n’auraient pas forcément tort : avec le temps et les évolutions du noyau, il est possible que certaines méthodes de manipulation utilisées par les « vieux » outils entraînent des dysfonctionnements. Et il n’est jamais trop tard pour apprendre de nouvelles choses.

Les quelques années correspondent à peu près à peu de temps après la sortie de la suite iproute2, soit en 1999. Oui, ça date. En pratique, quasiment toutes les commandes indépendantes de l’époque sont regroupées sous une seule, ip, à qui on donnera moultes instructions et paramètres. L’objectif, unifier la syntaxe des commandes réseau, chaque outil utilisant sa propre nomenclature différente les unes des autres.

Comme les anciennes existent toujours, fonctionnent toujours, et que certains, comme moi, auront d’abord appris celles-ci (et ont d’ailleurs tendance à toujours les utiliser), je vais les mentionner à titre de comparaison.

L’évidence : l’adresse IP

Ça parait peut-être trivial, mais avant de regarder de plus près qui communique avec qui, il serait peut-être intéressant de savoir à quel « qui » correspond notre machine. Si vous connaissez déjà le nom de votre interface réseau, vous pouvez cibler, sinon, afficher tout :

On peut remplacer le a par addr, c’est pareil (juste c’est plus rapide à taper). Quand on regarde la méthode ciblée, on peut être un peu effrayé au début. Mais quand on doit attribuer soi-même une IP ou la supprimer (le temps d’un test, avant de la configurer définitivement), on comprend  un poil mieux l’esprit d’unification de syntaxe :

On peut se dire que ça n’a pas grand intérêt pour l’instant, d’utiliser une nouvelle commande et une nouvelle syntaxe. Tiens ça me rappelle le bordel autour de Systemd. Si vous avez besoin de modifier des routes, vous comprenez à quel point la syntaxe « unifiée » prend son sens.

Netstat, voir qui est connecté sur quoi

Sans vous refaire un cours complet de réseau, les machines communiquent entre elles avec des adresses IP, et les logiciels ouvrent des « ports » pour communiquer. netstat permet d’avoir la table des ports ouverts ainsi que des connexions qui sont actives sur ces mêmes ports.

Personnellement, je suis un grand amateur des options -a, -n, -p, -t, -u, mais pour l’exemple je vais simplifier un peu (seulement les connexions TCP ouvertes). On peut les regrouper, et magie, ça marche aussi avec la nouvelle commande, prénommée ss (pour Sockets Statistics) :

Voilà, on a à peu près les mêmes informations, mais la commande est finalement plus simple, puisqu’on a filtré seulement les connexions établies, netstat étant plus verbeux dès le départ et nécessitant un grep. Pour ajouter les connexions UDP, il suffit d’inclure l’option -u dans les deux cas.

Pour voir les ports ouverts seulement, l’esprit reste le même, peu de choses diffèrent :

ss est une commande très complète, et je pense plus claire à utiliser que netstat. Guillaume Leduc en a fait une fiche pratique très complète et très explicite, je vous la recommande.

Et le trafic dans tout ça ?

Bien, on sait comment identifier les connexions actives, et bien il est possible, moyennant quelques outils, de connaître la charge sur ces connexions, ou sur la connexion (aussi appelé le lien) si on prend le trafic dans son ensemble.

Avec certains outils de surveillance du matériel, on a déjà ça dans de belles interfaces graphique, par exemple sur mon installation sous KDE :

network-monitoring

La magie d’une connexion ADSL branlante. 21° Siècle vous dites ?

Eh bien il est possible d’avoir la même chose dans une console ! Grâce à un petit utilitaire appelé bmon, disponible dans les dépôts Debian ainsi que Manjaro (certainement aussi sous CentOS), et aussi un dépôt Github en cas de manque. Admirez ce très moche graphique dans la lignée de l’ASCII art :

network-bmon

Pas assez précis pour vous ? Plus ciblé, iftop (également disponible dans toutes les bonnes crèmeries) affiche le trafic par connexion ouverte/active, et classé du plus actif au plus calme. Son affichage est peut-être un peu moins clair, mais il peut aussi être simplifié (l’aide est très pratique pour ça) :

network-iftop

Bien, mais ça, c’est pas du « long terme »

En effet, toutes les commandes que j’ai donné jusqu’ici ne permettent que de se pencher sur le présent. Si l’on veut surveiller une connexion à plus long terme, il faut se tourner vers d’autres outils plus complexes, du domaine de la supervision. Celui que j’utilise depuis quelques années sur mes serveurs est Munin. Il permet de collecter quantité d’informations, et de les représenter sous forme de graphique, montrant alors l’évolution de ces informations dans le temps.

network-munin

Plus que « grapher », Munin permet de définir des seuils d’alerte, avec envoi de mail à la clé (libre à vous d’agir après). Sur une même installation de Munin, on peut centraliser plusieurs « nœuds », qui ne feront alors que collecter les données et les transmettre. Sympathique, et de nombreux plugins existent pour ce système. Il est présent dans les dépôts Debian (installer munin-node pour un nœud, munin pour le grapheur), ainsi que Manjaro.

Un autre outil, qui semble plus complet, plus adapté en gros environnements, mais pas que, c’est Shinken. À l’origine, Shinken n’est ni plus ni moins qu’un « fork » d’un poids lourd de la supervision, Nagios. Mais les choix techniques de l’équipe de développement étaient contestés, et Shinken est apparu comme une réécriture complète en Python (on en fait des choses avec ce serpent hein ?). Il reste compatible avec les nombreux plugins Nagios existants sur le marché. Je dois toujours m’y coller, un de ces quatre. Il remplacera probablement Munin si mes résultats de test (que je dois faire depuis quelques mois maintenant) sont concluants (et ça sera plus pratique si l’on doit conserver la machine virtuelle Windows pour Arma 3). Contrairement à Munin, Shinken permet de prendre automatiquement des mesures en cas d’alerte (redémarrage d’un service qui ne répond plus par exemple).

network-shinken-logo

Pas que de la surveillance

Ces outils permettent non seulement de vérifier l’état du réseau quand il fonctionne bien, mais peuvent aider aussi à diagnostiquer quand il déconne. Je n’ai pas abordé les cas des protocoles un peu plus « haut niveau », comme le DNS, l’HTTP, ce genre de choses. La vérification d’une bonne configuration du pare-feu iptables est faisable aussi avec ces outils.

Si l’objectif est de faire de l’analyse poussée de trafic, Wireshark est un outil de choix. D’autres que moi ont déjà longuement écrit sur sa puissance, et ce dans beaucoup de langues. Je vous laisse chercher sur un moteur de recherche qui vous respecte.

network-wireshark

Voilà, vous avez maintenant quelques armes pour gérer votre machine, et en analyser une partie du fonctionnement 🙂

1
Poster un Commentaire

avatar
1 Fils de commentaires
0 Réponses de fil
1 Abonnés
 
Commentaire avec le plus de réactions
Le plus populaire des commentaires
1 Auteurs du commentaire
witkowski Auteurs de commentaires récents
  S’abonner  
plus récent plus ancien
Notifier de
witkowski
Invité
witkowski

bonjour, curieux que tu parles de commandes simplifiées et que tu parles d’iptable.. sous debian les commandes iptable sont dépréciées depuis 2015 et remplacées par la commande nft. La commande nft est une reecriture des commandes iptables par le même développeur associée à une nouvelle syntaxe des commandes qui permet beaucoup plus de choses (tels que l’exécution de deux actions sur le même paquet via une seule ligne, ce qui simplifies l’écriture de règles nft ou iptable). NFT a un mode de compatiblité iptables. Pour les nouvelles installation :nft + nouvelles syntaxe de règles. Pour les installation existante : nft… Lire la suite »