Surveiller le trafic réseau d’un serveur Linux avec vnStat

Sur un VPS Linux, le trafic réseau évolue avec les mises à jour, les sauvegardes, les téléchargements et les connexions des utilisateurs. Une mesure ponctuelle ne suffit pas toujours pour comprendre une consommation de bande passante. L’outil vnStat conserve des compteurs par interface réseau et permet de suivre le volume reçu et transmis sur plusieurs périodes.

Ce guide s’adresse à l’administrateur d’un serveur Linux qui veut installer vnStat, identifier la bonne interface réseau, lire ses statistiques et éviter de confondre volume de données, débit instantané, latence et capacité de la liaison.

Ce que mesure vnStat

vnStat collecte des compteurs de trafic associés à une interface réseau. Il distingue les données reçues, notées RX, des données envoyées, notées TX. Ses vues horaires, quotidiennes et mensuelles aident à repérer une tendance, une pointe de bande passante ou une anomalie de volume. Elles ne donnent pas le nom de chaque connexion et ne remplacent pas une capture de paquets.

Cette distinction est importante pour un serveur de jeu, un service d’API, un espace de sauvegarde ou une application. Un volume mensuel élevé ne signifie pas nécessairement que la liaison est saturée en permanence. Pour un diagnostic complet, associez l’historique de vnStat à un test de débit, à une mesure de latence et à l’observation des processus qui utilisent le réseau.

Vérifier l’interface réseau

Avant d’installer l’outil, listez les interfaces visibles par Linux et leurs adresses réseau :

ip -br link
ip -br address
ip route

Repérez l’interface qui porte l’adresse IP utilisée pour sortir vers Internet et la route par défaut. Selon la distribution et la virtualisation, son nom peut être différent. Ne supposez pas que l’interface s’appelle toujours eth0. Notez aussi les interfaces virtuelles, les bridges et les interfaces de conteneurs, car une mauvaise sélection peut produire une lecture incomplète.

La commande ip route montre la route par défaut et la passerelle utilisée par le serveur. Cette information aide à choisir la bonne interface lorsque plusieurs cartes Ethernet, bridges ou réseaux locaux sont présents. Sur une machine virtuelle, le nom affiché par Linux peut être une interface virtuelle, même si l’hôte physique utilise une autre carte réseau.

Installer vnStat

Sur une distribution basée sur Debian ou Ubuntu, installez le paquet fourni par les dépôts configurés sur le serveur :

sudo apt update
sudo apt install vnstat

Vérifiez ensuite que le service est actif et que le binaire répond :

systemctl status vnstat
vnstat --version

Les noms de paquets et la gestion du service peuvent différer selon la distribution. Utilisez le gestionnaire de paquets et la documentation de votre système, puis vérifiez le résultat au lieu de supposer que l’installation a créé une base de statistiques exploitable. Le service doit pouvoir lire les compteurs de l’interface et enregistrer ses données dans sa base locale.

Choisir et initialiser une interface

Affichez les interfaces suivies par vnStat :

vnstat --iflist

Si votre version demande explicitement une interface, indiquez celle identifiée précédemment. Sur les versions récentes, la création de la base est souvent gérée par le service. Après le démarrage, laissez passer suffisamment de trafic et de temps avant d’interpréter les périodes longues. Une base vide ou récemment créée ne permet pas de conclure sur un mois complet.

vnstat -i ens3

Remplacez ens3 par le nom réellement présent sur votre serveur. Si l’interface est supprimée ou renommée après une modification réseau, contrôlez la configuration du service et les interfaces suivies. Une statistique attachée à un bridge ou à une interface de conteneur ne répond pas forcément à la même question qu’une statistique attachée à la carte réseau principale.

Lire les statistiques réseau

La commande sans option affiche un résumé de l’interface sélectionnée :

vnstat -i ens3

Pour suivre les périodes courtes et longues, utilisez les vues adaptées proposées par votre version :

vnstat -i ens3 --hours
vnstat -i ens3 --days
vnstat -i ens3 --months
vnstat -i ens3 --live

Les options disponibles peuvent varier. Consultez vnstat --help si une option n’est pas reconnue. Comparez RX et TX avec votre usage réel : sauvegardes sortantes, mises à jour de jeu, téléchargement d’assets, trafic d’API, réplication ou transferts de fichiers peuvent expliquer des écarts légitimes.

TCP, UDP, ports et paquets

Le compteur d’interface agrège le trafic qui passe par la carte ou l’interface virtuelle. Il ne sépare pas automatiquement les protocoles TCP et UDP, les ports, les adresses IP distantes ou les applications. Les paquets d’un serveur de jeu peuvent donc apparaître dans le même compteur que ceux d’une mise à jour, d’une sauvegarde ou d’un service web.

Pour relier un port à un processus, utilisez un outil de sockets comme ss. Pour comprendre le chemin réseau, vérifiez l’adresse IP, la route, la passerelle et, si nécessaire, la résolution DNS. Un pare-feu peut autoriser ou bloquer un flux, mais vnStat ne remplace pas la lecture de la configuration du pare-feu. Ces contrôles expliquent pourquoi le volume observé et le volume attendu ne coïncident pas toujours.

Distinguer pic instantané et volume cumulé

Le volume cumulé est exprimé sur une période, tandis qu’un débit décrit une vitesse à un instant donné. Un serveur peut transférer un gros fichier rapidement puis rester presque inactif. À l’inverse, de petites requêtes continues peuvent générer un volume modéré mais solliciter régulièrement la connexion.

La latence, la perte de paquets et le débit sont trois indicateurs différents. vnStat est pertinent pour l’historique de volume. Il ne mesure pas à lui seul le temps de réponse d’un hôte distant, la perte de paquets ou le chemin réseau. Pour un contrôle complémentaire, mesurez le débit dans une fenêtre maîtrisée avec un outil prévu à cet effet et évitez de lancer un test pendant une sauvegarde ou une session de jeu. Le guide mesurer le débit réseau avec iperf3 traite cette mesure séparément.

Investiguer une consommation inhabituelle

Si l’historique révèle une hausse que vous ne pouvez pas expliquer, commencez par dater le changement. Vérifiez les tâches planifiées, les sauvegardes, les mises à jour, les téléchargements et les journaux du service concerné. Comparez le trafic entrant et sortant, puis regardez si le pic est continu ou limité à une heure.

La liste des sockets aide à relier les ports ouverts aux services locaux. Elle complète vnStat, qui mesure des compteurs mais n’attribue pas chaque octet à un processus. Consultez le guide pour lister les ports en écoute avec ss. Si le serveur est inaccessible, commencez par le triage décrit dans le diagnostic réseau d’un VPS inaccessible.

Ne concluez pas immédiatement à une attaque à partir d’un seul pic. Conservez l’heure, l’interface, le volume RX/TX, les journaux disponibles et les changements effectués récemment. Ces éléments permettent de distinguer une tâche attendue d’un comportement à examiner.

Organiser la surveillance

Conservez une convention d’interface et relevez les statistiques à intervalle régulier. Une alerte utile doit comparer une période comparable, par exemple une journée habituelle avec la même période précédente, plutôt que de déclencher sur un seul compteur après un redémarrage.

Définissez des seuils séparés pour le volume entrant, le volume sortant, le débit observé et la latence. Documentez la fréquence des sauvegardes, la fenêtre de maintenance et les téléchargements importants. Cette méthode réduit les faux positifs et facilite l’analyse d’un incident réseau.

Associez cette mesure à la surveillance de l’espace disque, car les journaux, fichiers temporaires et sauvegardes peuvent remplir un VPS indépendamment du réseau. Le guide surveiller l’espace disque d’un VPS Linux présente ce contrôle. Pour comprendre un service qui redémarre ou cesse de répondre, utilisez aussi la détection d’un serveur de jeu hors service.

Bonnes pratiques et limites

• identifiez l’interface réelle avec ip avant toute lecture ;
• attendez que la base collecte des données avant de conclure sur une période longue ;
• notez séparément trafic entrant, trafic sortant, volume cumulé, débit et latence ;
• ne déduisez pas le processus responsable à partir de vnStat seul ;
• documentez les sauvegardes et tâches planifiées qui expliquent les pics attendus ;
• conservez une période de référence pour comparer les évolutions ;
• contrôlez le nom de l’interface après une migration, un changement de réseau ou une modification de virtualisation.

Si vous administrez plusieurs services, centralisez les seuils, les horaires de collecte et les unités utilisées. Une mesure cohérente est plus utile qu’une succession de commandes lancées uniquement après un incident.