Comment surveiller la bande passante d'un VPN sur macOS

Vous vous connectez à votre VPN, lancez une vérification web qui rapporte le bon pays, et supposez que tout est désormais tunnelisé. Deux jours plus tard vous remarquez qu'une de vos applications — disons, un vieux client de chat ou un agent de synchro — parle directement à l'Internet public depuis le début, ignorant complètement le tunnel. Le VPN était activé. La fuite était dans un processus qui s'était lié à l'interface physique avant l'établissement du tunnel et n'a jamais lâché.

Surveiller la bande passante VPN sur macOS, c'est en partie confirmer que le VPN fait son travail et en partie attraper les applications qui le contournent silencieusement. Ce billet couvre ce que sont vraiment les interfaces utun, comment lire le trafic VPN avec les outils intégrés, comment détecter les fuites, et comment mesurer la surcharge ajoutée par le tunnel. Si vous cherchiez à surveiller la bande passante VPN sur Mac parce que le tableau de bord propre du VPN ne vous dit pas assez, la boîte à outils ci-dessous répond aux questions plus difficiles.

Ce que sont les interfaces utun

Quand un client VPN se connecte sur macOS, il crée une interface virtuelle — généralement nommée utun0, utun1, utun2, etc. (« utun » signifie « user tunnel »). Le processus VPN lit les paquets que l'OS route vers cette interface, les chiffre et les encapsule, et écrit les paquets enveloppés résultants à travers votre interface physique (en0 pour le Wi-Fi, typiquement).

Lancez ceci dans Terminal pour voir ce qui est actuellement actif :

ifconfig | grep -E "^(en|utun)" -A 3

Vous verrez quelque chose comme :

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
        inet 10.8.0.6 --> 10.8.0.1 netmask 0xffffff00

en0 est votre vrai réseau. utun0 est le VPN. Certains clients VPN créent plusieurs interfaces utun (une pour le plan de données, une pour le contrôle) ; certains créent utun9 ou plus haut pour éviter les collisions avec les tunnels de partage personnel de style iOS.

Comment surveiller le trafic de bande passante VPN avec nettop

nettop est intégré à macOS et c'est la façon la plus directe de voir quelle interface un processus utilise. L'invocation pertinente :

sudo nettop -P -m route

Ceci montre les connexions de chaque processus groupées par route. Un processus qui parle à travers votre VPN montrera son trafic via l'interface utun ; un processus contournant le tunnel montrera via en0 (ou en1 si ethernet).

Observez nettop pendant une minute, puis demandez-vous : quelles applications utilisent utun0 et quelles utilisent en0 ? Si vous comptez sur le fait que tout passe par le tunnel et que vous voyez Slack sur en0, c'est une fuite.

Le drapeau -P agrège par processus ; -m route montre la colonne de route. Ajoutez -x pour les compteurs d'octets. Ajoutez -c et un délai pour rafraîchissement périodique, par exemple nettop -P -c 2.

Ce que ova montre pour le trafic VPN

Un moniteur par application comme ova voit les mêmes statistiques noyau que nettop et les agrège dans le temps. La bande passante attribuée à « Slack » dans ova inclut tout ce que Slack a envoyé — sur en0 ou utun0 ne change pas le total par processus. Donc ova répond à « combien Slack a utilisé ? » proprement. Il ne décompose pas actuellement le nombre par application par interface — si vous avez besoin de ce niveau de détail, nettop est l'outil.

Pour la plupart des utilisateurs VPN c'est très bien. Les questions auxquelles vous voulez généralement des réponses sont :

• « Mon client VPN lui-même utilise-t-il la bande passante que j'attends ? »
• « Y a-t-il eu un pic dans la dernière heure ? »
• « Quelle application est la plus gourmande actuellement ? »

ova vous donne les trois d'un coup d'œil, avec regroupement des processus auxiliaires pour qu'un PID auxiliaire de Slack n'apparaisse pas comme une ligne séparée. Le client VPN lui-même (Tailscale, Mullvad, ProtonVPN, NordVPN, etc.) apparaît comme sa propre ligne, et son nombre est le total enveloppé/chiffré sortant par votre lien physique.

Détecter les fuites

Une fuite VPN, c'est quand le trafic d'une application contourne le tunnel et va directement à Internet. Les causes incluent :

• L'application a mis en cache une route avant l'établissement du VPN et l'utilise encore.
• Le VPN ne route pas certaines destinations (LAN, multicast, DNS vers un serveur spécifique).
• La bascule « exclure le réseau local » de macOS fait ce qu'elle dit.
• Le VPN est en split-tunnel et une application particulière est dans la liste de contournement.
• IPv6 est activé et le VPN ne route que IPv4 (une cause courante).

La boucle de diagnostic :

1. Avec le VPN connecté, lancez nettop -P -m route et observez tout processus montrant du trafic en0 que vous attendiez tunnelisé.
2. Recoupez avec ova pour la bande passante par processus. Si un processus montre du trafic dans ova mais aucune ligne utun dans nettop, il fuit.
3. Confirmez au niveau réseau : visitez ipleak.net ou dnsleaktest.com depuis un navigateur. L'IP rapportée devrait être la sortie du VPN, pas votre maison/bureau.
4. Pour le DNS spécifiquement : lancez scutil --dns | grep nameserver — les serveurs de noms listés devraient être ceux de votre VPN, pas ceux de votre FAI.

Pour IPv6 spécifiquement, la configuration la plus sûre est soit un VPN qui route explicitement IPv6 soit la désactivation d'IPv6 à l'échelle du système pendant la connexion. Désactiver par réseau : Réglages Système > Réseau > votre réseau > Détails > TCP/IP > Configurer IPv6 > Link-local uniquement.

Mesurer la surcharge VPN

Les VPN ajoutent de la surcharge de deux façons : débit (vous obtenez moins de votre vraie vitesse de ligne) et latence (chaque round-trip passe par un saut supplémentaire).

Surcharge de débit

La taxe de chiffrement dépend du protocole :

• WireGuard : typiquement 5 à 10 % de surcharge sur un lien rapide. Accéléré matériel sur Apple Silicon.
• OpenVPN : 15 à 30 % de surcharge. CPU-bound, plus lent que WireGuard à hauts débits.
• IKEv2/IPsec : 10 à 20 % de surcharge. Support natif macOS.
• Protocoles propriétaires (Lightway, NordLynx basé sur WireGuard, etc.) : efficacité grossièrement de niveau WireGuard.

Pour mesurer : lancez un test de débit avec le VPN désactivé, notez le résultat. Lancez le même test avec le VPN activé, vers un serveur dans la même zone métropolitaine que l'endpoint du test sans VPN. Le ratio est la surcharge. Utilisez ova pendant les deux tests — le trafic par application montré pour le client de test de débit devrait être le débit au niveau application ; le débit système pendant les tests VPN est plus haut à cause du framing de chiffrement.

Surcharge de latence

Lancez ping 8.8.8.8 avec VPN désactivé, notez le RTT en régime stable. Connectez le VPN, relancez ping 8.8.8.8. La différence est le coût de round-trip pour chiffrer, voyager jusqu'à la sortie VPN, et revenir. Chiffres typiques :

• Sortie VPN dans la même ville : +5 à +15 ms.
• Sortie VPN dans un autre pays : +50 à +200 ms selon la géographie.
• Sortie VPN sur un autre continent : +150 à +400 ms.

C'est de la physique inévitable pour la plupart — vous ne pouvez pas tunnelliser vers Tokyo sans payer le round-trip.

Identifier l'usage de bande passante propre au VPN

Le processus client VPN lui-même apparaît dans ova comme sa propre ligne — « Mullvad VPN », « Tailscale », « ProtonVPN », etc. Le nombre que vous y voyez est le total chiffré et enveloppé qui sort par votre lien physique. C'est le bon nombre pour « combien de vraie bande passante Internet le VPN consomme-t-il ».

Une vérification de bon sens utile : à tout moment, la bande passante rapportée par le VPN devrait être approximativement égale à la somme de toutes les autres applications qui l'utilisent, plus un petit pourcentage pour la surcharge de chiffrement. Si elles sont sauvagement différentes, autre chose se passe — split tunneling, fuite, ou le client VPN faisant du travail de maintenance (rotation de clés, découverte de pairs).

Voyez ova en action

Un moniteur de bande passante en barre de menu consultable d'un coup d'œil — local, signé, ~3 Mo.

Télécharger pour macOS

VPN toujours actif : pièges

Plusieurs clients VPN offrent un « kill switch » ou un mode « always-on » qui bloque tout le trafic si le tunnel tombe. Utile, mais avec des surprises :

• Les premières secondes après le réveil peuvent avoir du trafic non bloqué avant le rétablissement du tunnel. Certains clients tiennent ce blocage explicitement ; d'autres non.
• Les changements de réseau Wi-Fi (de la maison au café) déclenchent une brève déconnexion. Le kill switch devrait tenir mais l'implémentation varie.
• Certaines applications ont une logique de reconnexion agressive — elles réessaient toutes les 100 ms quand le tunnel est tombé. C'est un pic de bande passante au moment de la reconnexion une fois le tunnel revenu.

Observez ova au moment du réveil avec VPN activé. Le motif est généralement : le client VPN lui-même montre une petite poussée pendant qu'il refait sa poignée de main, puis dans les 5 à 30 secondes les applications individuelles commencent à pousser au fur et à mesure qu'elles reconnectent leurs propres sockets. Si vous voyez un pic de 200 Mo au réveil, c'est typiquement Slack/Discord/iMessage qui rattrapent tous d'un coup.

Routage par application et split tunnels

Certains clients VPN supportent le routage de seules applications spécifiques à travers le tunnel. Le cas d'usage est « envoyer mon client torrent par Mullvad, mais laisser Slack passer en direct pour que les appels vidéo n'ajoutent pas de latence VPN ».

Vérifier les règles de split tunnel avec nettop :

sudo nettop -P -m route

Les applications en split tunnel devraient montrer seulement du trafic en0 ; celles tunnelisées devraient montrer seulement utun. Si les deux apparaissent pour le même processus, les règles ne sont pas appliquées proprement — généralement parce que l'application maintient des sockets longue durée antérieures au changement de règle. Redémarrez l'application pour les nettoyer.

Surveiller plusieurs connexions VPN

Les utilisateurs avancés font parfois tourner deux VPN à la fois — par exemple, Tailscale pour accéder aux services internes de l'entreprise plus un VPN commercial (Mullvad, Proton) pour la confidentialité Internet générale. macOS gère cela via les tables de routage : les routes plus spécifiques (le 100.64.0.0/10 de Tailscale) gagnent sur les plus larges (la route par défaut du VPN commercial).

Vous verrez plusieurs interfaces utun dans ifconfig. Utilisez netstat -rn | head -30 pour lire la table de routage — la première route qui correspond gagne. ova montre la bande passante totale par application sans distinguer quel tunnel ; pour cela, la vue -m route de nettop est la référence.

Que faire ensuite

Un audit de 10 minutes pour surveiller la bande passante VPN sur Mac de bout en bout :

1. Connectez le VPN.
2. Ouvrez ova dans la barre de menu, notez les applications actuellement actives.
3. Lancez sudo nettop -P -m route dans Terminal.
4. Recoupez : chaque application montrant une bande passante significative dans ova devrait avoir ses connexions apparaissant sous utun0 (ou quel que soit l'utun qu'utilise votre VPN) dans nettop. Tout trafic en0 de ces processus est un candidat à la fuite.
5. Visitez ipleak.net pour confirmer IP et sortie DNS via le VPN.
6. Déconnectez, lancez un test de débit, reconnectez, lancez-en un autre. Calculez la surcharge.

Vous sortirez de cela en sachant si votre VPN fait réellement ce que vous pensez qu'il fait, ce que sa surcharge coûte réellement, et quelles applications garder à l'œil. C'est une réponse plus forte que l'indicateur « Connecté » dans la barre de menu de votre client VPN.