VPN-Bandbreite unter macOS überwachen

Sie verbinden sich mit Ihrem VPN, lassen einen Web-Check laufen, der das richtige Land meldet, und nehmen an, dass jetzt alles getunnelt ist. Zwei Tage später bemerken Sie, dass eine Ihrer Apps — sagen wir ein alter Chat-Client oder ein Sync-Agent — die ganze Zeit direkt mit dem öffentlichen Internet gesprochen hat und den Tunnel komplett ignoriert hat. Das VPN war an. Das Leck steckte in einem Prozess, der sich an die physische Schnittstelle gebunden hatte, bevor der Tunnel hochkam, und nie losgelassen hat.

VPN-Bandbreite auf macOS zu überwachen geht teils darum, zu bestätigen, dass das VPN seinen Job macht, und teils darum, die Apps zu erwischen, die es still und leise umgehen. Dieser Beitrag deckt ab, was utun-Schnittstellen wirklich sind, wie Sie VPN-Verkehr mit eingebauten Tools lesen, wie Sie Lecks erkennen und wie Sie den Overhead messen, den der Tunnel hinzufügt. Wenn Sie nach „monitor vpn bandwidth mac" gesucht haben, weil das VPN-eigene Dashboard Ihnen nicht genug sagt, beantwortet das Toolkit unten die schwierigeren Fragen.

Was utun-Schnittstellen sind

Wenn ein VPN-Client auf macOS verbindet, erzeugt er eine virtuelle Schnittstelle — meist utun0, utun1, utun2 usw. genannt. („utun" steht für „user tunnel".) Der VPN-Prozess liest Pakete, die das OS zu dieser Schnittstelle routet, verschlüsselt und kapselt sie ein und schreibt die resultierenden gewickelten Pakete über Ihre physische Schnittstelle (en0 für Wi-Fi, typischerweise) hinaus.

Führen Sie das im Terminal aus, um zu sehen, was aktuell oben ist:

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

Sie sehen so etwas wie:

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 ist Ihr echtes Netzwerk. utun0 ist das VPN. Manche VPN-Clients erzeugen mehrere utun-Schnittstellen (eine für die Datenebene, eine für die Steuerung); manche erzeugen utun9 oder höher, um Kollisionen mit iOS-artigen Hotspot-Tunneln zu vermeiden.

Wie Sie VPN-Bandbreitenverkehr auf macOS mit nettop überwachen

nettop ist in macOS eingebaut und der direkteste Weg zu sehen, welche Schnittstelle ein Prozess nutzt. Der relevante Aufruf:

sudo nettop -P -m route

Das zeigt die Verbindungen jedes Prozesses, gruppiert nach Route. Ein Prozess, der durch Ihr VPN spricht, zeigt seinen Verkehr über die utun-Schnittstelle; ein Prozess, der den Tunnel umgeht, zeigt über en0 (oder en1 bei Ethernet).

Beobachten Sie nettop eine Minute, dann fragen Sie: Welche Apps nutzen utun0 und welche nutzen en0? Wenn Sie wollen, dass alles durch den Tunnel geht, und Sie Slack auf en0 sehen, ist das ein Leck.

Das Flag -P aggregiert pro Prozess; -m route zeigt die Route-Spalte. Fügen Sie -x für Byte-Zähler hinzu. Fügen Sie -c und eine Verzögerung für periodische Aktualisierung hinzu, z. B. nettop -P -c 2.

Was ova für VPN-Verkehr zeigt

Ein Pro-App-Monitor wie ova sieht dieselben Kernel-Statistiken wie nettop und summiert sie über die Zeit. Die in ova „Slack" zugeordnete Bandbreite enthält, was auch immer Slack gesendet hat — über en0 oder utun0 ändert die Pro-Prozess-Summe nicht. Also beantwortet ova „wie viel hat Slack genutzt" sauber. Es schlüsselt die Pro-App-Zahl derzeit nicht nach Schnittstelle auf — falls Sie diesen Detailgrad brauchen, ist nettop das Tool.

Für die meisten VPN-Nutzer ist das in Ordnung. Die Fragen, die Sie meist beantwortet haben wollen, sind:

• „Nutzt mein VPN-Client selbst die Bandbreite, die ich erwarte?"
• „Hat irgendetwas in der letzten Stunde gespitzt?"
• „Welche App ist gerade die schwerste?"

ova gibt Ihnen alle drei auf einen Blick, mit Hilfsprozess-Zusammenfassung, sodass eine Slack-Helper-PID nicht als separate Zeile auftaucht. Der VPN-Client selbst (Tailscale, Mullvad, ProtonVPN, NordVPN usw.) erscheint als eigene Zeile, und seine Zahl ist die gewickelte/verschlüsselte Summe, die durch Ihre physische Verbindung hinausgeht.

Lecks erkennen

Ein VPN-Leck ist, wenn der Verkehr einer App den Tunnel umgeht und direkt ins Internet geht. Ursachen umfassen:

• Die App hat eine Route gecached, bevor das VPN hochkam, und nutzt sie noch.
• Das VPN routet bestimmte Ziele nicht (LAN, Multicast, DNS zu einem spezifischen Server).
• macOSs „Lokales Netzwerk ausschließen"-Schalter macht, was er sagt.
• Das VPN ist Split-Tunneled, und eine bestimmte App ist auf der Bypass-Liste.
• IPv6 ist aktiv und das VPN routet nur IPv4 (eine häufige Ursache).

Die Diagnoseschleife:

1. Mit verbundenem VPN führen Sie nettop -P -m route aus und achten auf jeden Prozess, der en0-Verkehr zeigt, von dem Sie erwartet haben, dass er getunnelt wird.
2. Querprüfen Sie mit ova für die Pro-Prozess-Bandbreite. Wenn ein Prozess Verkehr in ova zeigt, aber keine utun-Zeilen in nettop, dann leakt er.
3. Bestätigen Sie auf Netzwerkebene: Besuchen Sie ipleak.net oder dnsleaktest.com aus einem Browser. Die gemeldete IP sollte der VPN-Ausgang sein, nicht Ihr Zuhause/Büro.
4. Speziell für DNS: führen Sie scutil --dns | grep nameserver aus — die gelisteten Nameserver sollten die Ihres VPN sein, nicht die Ihres ISP.

Speziell für IPv6: Das sicherste Setup ist entweder ein VPN, das IPv6 explizit routet, oder IPv6 systemweit zu deaktivieren, während verbunden. Pro Netzwerk deaktivieren: Systemeinstellungen > Netzwerk > Ihr Netzwerk > Details > TCP/IP > IPv6 konfigurieren > Nur Link-local.

VPN-Overhead messen

VPNs fügen Overhead auf zwei Wegen hinzu: Durchsatz (Sie bekommen weniger Ihrer tatsächlichen Leitungsgeschwindigkeit) und Latenz (jeder Roundtrip geht durch einen zusätzlichen Hop).

Durchsatz-Overhead

Die Verschlüsselungs-Steuer hängt vom Protokoll ab:

• WireGuard: typisch 5 bis 10 Prozent Overhead auf einer schnellen Verbindung. Hardwarebeschleunigt auf Apple Silicon.
• OpenVPN: 15 bis 30 Prozent Overhead. CPU-gebunden, langsamer als WireGuard bei hohen Geschwindigkeiten.
• IKEv2/IPsec: 10 bis 20 Prozent Overhead. macOS-native Unterstützung.
• Proprietäre Protokolle (Lightway, NordLynx auf WireGuard-Basis usw.): grob WireGuard-Effizienz.

Zum Messen: Lassen Sie einen Speedtest mit ausgeschaltetem VPN laufen, notieren Sie das Ergebnis. Lassen Sie denselben Test mit eingeschaltetem VPN laufen, zu einem Server in derselben Metro-Region wie der Aus-Test-Endpunkt. Das Verhältnis ist der Overhead. Nutzen Sie ova während beider Tests — der für den Speed-Test-Client gezeigte Pro-App-Verkehr sollte der Anwendungsschicht-Durchsatz sein; die systemweite Rate während VPN-Tests ist höher wegen des Verschlüsselungs-Framings.

Latenz-Overhead

Lassen Sie ping 8.8.8.8 mit ausgeschaltetem VPN laufen, notieren Sie das stationäre RTT. VPN verbinden, ping 8.8.8.8 erneut laufen lassen. Die Differenz sind die Roundtrip-Kosten für Verschlüsseln, Reise zum VPN-Ausgang und zurück. Typische Werte:

• VPN-Ausgang in derselben Stadt: +5 bis +15 ms.
• VPN-Ausgang in einem anderen Land: +50 bis +200 ms je nach Geographie.
• VPN-Ausgang auf einem anderen Kontinent: +150 bis +400 ms.

Das ist meist unvermeidbare Physik — Sie können nicht nach Tokio tunneln und nicht den Roundtrip dafür bezahlen.

Die eigene Bandbreitennutzung des VPN identifizieren

Der VPN-Client-Prozess selbst taucht in ova als eigene Zeile auf — „Mullvad VPN", „Tailscale", „ProtonVPN" usw. Die Zahl, die Sie dort sehen, ist die verschlüsselte, gewickelte Summe, die über Ihre physische Verbindung hinausgeht. Das ist die richtige Zahl für „wie viel echte Internet-Bandbreite konsumiert das VPN".

Eine nützliche Plausibilitätsprüfung: Zu jedem Zeitpunkt sollte die gemeldete Bandbreite des VPN ungefähr der Summe aller anderen Apps, die es nutzen, plus einem kleinen Prozentsatz für Verschlüsselungs-Overhead entsprechen. Wenn sie wild unterschiedlich sind, geht etwas anderes vor — Split-Tunneling, Leakage, oder der VPN-Client macht Wartungsarbeit (Schlüsselrotation, Peer-Discovery).

Sehen Sie ova in Aktion

Ein auf einen Blick erfassbarer Menüleisten-Bandbreitenmonitor — lokal, signiert, ~3 MB.

Für macOS herunterladen

Always-On-VPN: Fallstricke

Mehrere VPN-Clients bieten einen „Kill Switch" oder „Always-On"-Modus, der allen Verkehr blockiert, wenn der Tunnel abreißt. Nützlich, aber mit Überraschungen:

• Die ersten paar Sekunden nach dem Wake-from-Sleep haben möglicherweise unblockierten Verkehr, bevor der Tunnel sich neu etabliert. Manche Clients halten das explizit; andere nicht.
• Wi-Fi-Netzwerkwechsel (von Zuhause zum Café) lösen einen kurzen Disconnect aus. Der Kill Switch sollte halten, aber die Implementierung variiert.
• Manche Apps haben aggressive Reconnect-Logik — sie wiederholen alle 100 ms, wenn der Tunnel unten ist. Das ist eine Bandbreitenspitze beim Reconnect, sobald der Tunnel zurückkommt.

Beobachten Sie ova im Moment nach dem Aufwachen mit eingeschaltetem VPN. Das Muster ist meist: Der VPN-Client selbst zeigt einen kleinen Anstieg, während er erneut handshaket, dann beginnen innerhalb von 5 bis 30 Sekunden einzelne Apps zu spitzen, während sie ihre eigenen Sockets neu verbinden. Wenn Sie eine 200-MB-Spitze beim Wake sehen, ist das typisch Slack/Discord/iMessage, die alle gleichzeitig nachholen.

Pro-App-Routing und Split-Tunnel

Manche VPN-Clients unterstützen das Routing nur spezifischer Apps durch den Tunnel. Der Anwendungsfall ist „schicke meinen Torrent-Client durch Mullvad, aber lass Slack direkt gehen, damit Videoanrufe keine VPN-Latenz hinzufügen".

Split-Tunnel-Regeln mit nettop verifizieren:

sudo nettop -P -m route

Die Split-Tunnel-Apps sollten nur en0-Verkehr zeigen; die getunnelten sollten nur utun zeigen. Wenn beide für denselben Prozess auftauchen, werden die Regeln nicht sauber durchgesetzt — meist, weil die App langlebige Sockets hält, die der Regeländerung vorausgehen. App neu starten, um sie zu löschen.

Mehrere VPN-Verbindungen überwachen

Power-User betreiben manchmal zwei VPNs gleichzeitig — etwa Tailscale für den Zugriff auf interne Firmen-Dienste plus ein kommerzielles VPN (Mullvad, Proton) für allgemeine Internet-Privatsphäre. macOS handhabt das über Routing-Tabellen: spezifischere Routen (Tailscales 100.64.0.0/10) gewinnen über breitere (die Default-Route des kommerziellen VPN).

Sie sehen mehrere utun-Schnittstellen in ifconfig. Nutzen Sie netstat -rn | head -30, um die Routing-Tabelle zu lesen — die erste passende Route gewinnt. ova zeigt Gesamt-Pro-App-Bandbreite ohne Unterscheidung, welcher Tunnel; dafür ist nettops -m route-Sicht die Referenz.

Was als Nächstes zu tun

Eine 10-minütige Prüfung, um die VPN-Bandbreite auf macOS Ende-zu-Ende zu überwachen:

1. VPN verbinden.
2. ova in der Menüleiste öffnen, aktive Apps notieren.
3. sudo nettop -P -m route im Terminal ausführen.
4. Querprüfen: Jede App, die signifikante Bandbreite in ova zeigt, sollte ihre Verbindungen unter utun0 (oder welchem utun Ihr VPN auch nutzt) in nettop haben. Jeder en0-Verkehr von diesen Prozessen ist ein Leck-Kandidat.
5. ipleak.net besuchen, um IP- und DNS-Ausgang über das VPN zu bestätigen.
6. Trennen, Speedtest laufen lassen, neu verbinden, einen weiteren laufen lassen. Den Overhead berechnen.

Sie kommen daraus mit dem Wissen, ob Ihr VPN tatsächlich tut, was Sie denken, was sein Overhead wirklich kostet und welche Apps Sie im Auge behalten sollten. Das ist eine stärkere Antwort als die „Verbunden"-Anzeige in der Menüleiste Ihres VPN-Clients.