Un VPN inactif consomme-t-il de la bande passante ? Lisez le bon compteur

Votre tunnel est resté ouvert toute la nuit, rien n'a été diffusé, et pourtant le graphique d'usage a bougé. C'est normal : un VPN maintient une conversation ouverte au lieu de réserver une partie de votre ligne, donc la part réservée est nulle tandis que les octets sont petits et réels. Les deux idées sont constamment interverties, et c'est pourquoi la question "un VPN inactif consomme-t-il de la bande passante" reçoit une mauvaise réponse dans les deux sens. Mesurer le bon compteur sur une fenêtre que vous pouvez décrire règle cela en un après-midi.

Pourquoi un tunnel inactif déplace encore des octets

Un tunnel est une correspondance avec une durée de vie, et quelque chose doit garder cette correspondance vivante. Les poignées de main expirent, les appareils NAT abandonnent les traductions inactives, et un pair qui reste silencieux assez longtemps peut devenir injoignable sans que rien n'échoue à aucun bout. Les protocoles diffèrent dans ce qu'ils envoient quand il n'y a rien à envoyer : WireGuard ne transmet rien par défaut une fois la poignée de main stabilisée, et le réglage facultatif PersistentKeepalive ajoute un paquet périodique pour qu'un pair derrière une traduction reste joignable. Activez-le délibérément et l'intervalle devient visible dans un compteur.

OpenVPN — son assistant de maintien fonctionne autrement : il définit des vérifications façon appel pour que les deux extrémités distinguent une session vivante d'une morte, et les clients qui embarquent leur propre transport ont des minuteries équivalentes sous d'autres noms. Rien de tout cela n'apparaît dans une fenêtre d'application, et c'est pourquoi un écran vide ne dit rien de ce qui passe sur le fil.

Une application inactive n'est pas un appareil inactif

Un tunnel ouvert sert chaque client qui y est rattaché, et les clients s'arrêtent rarement. La synchronisation de photos, les requêtes du résolveur, les vérifications de mise à jour et un agent de supervision suivent l'itinéraire par défaut, et sur un profil de tunnel complet cet itinéraire est le tunnel. Un téléphone endormi dans une poche interroge encore, et une tâche de sauvegarde se moque que personne ne regarde une vidéo. Le tunnel est inactif au sens où vous ne l'utilisez pas alors que vos appareils l'utilisent.

Les profils pontés et routés transportent un trafic différent, donc la même observation peut donner une réponse différente sur chacun. Notez qui était connecté avant de mesurer, car un seul client de synchronisation peut peser plus que tous les signaux de maintien de l'intervalle.

Choisissez un compteur et dites ce qu'il compte

Il existe trois totaux et chacun répond à une question différente : ce qui a traversé le tunnel, ce qui a traversé la liaison physique et ce que le fournisseur a décidé de facturer. Compter sur la liaison montante compte aussi tout ce qui n'est jamais entré dans le tunnel, du brassage ARP au flux d'un voisin. Compter sur l'interface du tunnel manque l'en-tête externe, les nouvelles tentatives de poignée de main et les signaux de maintien qui gardent une traduction ouverte. Lire les deux est bon marché, et c'est la seule façon de voir de quel côté du tunnel un octet a été compté.

ip -s link show wg0
ip -s link show eth0

Décidez de laquelle des deux porte votre question avant de citer l'une ou l'autre, car les additionner compte deux fois un travail lié. La comptabilité du fournisseur peut se clôturer sur une période plus tardive que celle que vous avez mesurée, donc un total qui ne concorde pas avec la facture n'est pas automatiquement faux. Joignez l'interface, la direction et la fenêtre à tout chiffre que vous publiez.

Faites une courte mesure encadrée

Laissez le tunnel et sa protection exactement comme ils fonctionnent un jour normal, sautez les transferts facultatifs et notez qui est resté connecté. Lisez les compteurs, attendez une fenêtre assez longue pour valoir la lecture, relisez-les et gardez le temps écoulé à côté de la différence. Un grand test de vitesse répond à une autre question : il sature la liaison et ne dit rien du coût de l'inactivité.

Répétez la fenêtre une fois si le premier résultat semble impossible, car un seul échantillon peut attraper une tâche planifiée en pleine exécution. Deux intervalles qui concordent sont une preuve ; un intervalle est une anecdote avec des unités.

N'achetez pas un zéro plus propre avec un tunnel pire

Couper un signal de maintien ou une vérification de vie pour ranger le graphique change le déploiement que vous mesurez, et le tunnel peut ne pas revenir après la période d'inactivité suivante. Demandez si le mécanisme sert la joignabilité ou la maintenance avant d'y toucher, et mesurez avec lui actif s'il la sert, car c'est la configuration que vous allez prendre en charge. Un zéro plus propre qui cache un chemin de reprise cassé est le résultat le plus coûteux de cet exercice.

Quand le chiffre est vraiment grand, trouvez le processus ou le client qui l'a produit au lieu de supposer que le protocole remplit la ligne. Comparez les compteurs interne et externe pour voir de quel côté sont les octets, puis rendez compte de l'usage de cette période au lieu de la capacité que vous croyez posséder.