Come monitorare la larghezza di banda della VPN su macOS

Ti connetti alla VPN, fai un controllo web che riporta il paese giusto, e dai per scontato che tutto sia ora tunnellato. Due giorni dopo noti che una delle tue app — diciamo, un vecchio client di chat o un agent di sync — ha parlato direttamente con l'internet pubblico tutto il tempo, ignorando del tutto il tunnel. La VPN era attiva. La fuga era in un processo che si era legato all'interfaccia fisica prima che il tunnel salisse e non l'ha mai mollata.

Monitorare la banda VPN su macOS è in parte confermare che la VPN stia facendo il suo lavoro e in parte beccare le app che la bypassano silenziosamente. Questo articolo copre cosa sono davvero le interfacce utun, come leggere il traffico VPN con strumenti integrati, come rilevare le fughe, e come misurare l'overhead aggiunto dal tunnel. Se hai cercato come monitorare la banda VPN su Mac perché la dashboard della VPN stessa non ti dice abbastanza, il toolkit qui sotto risponde alle domande più difficili.

Cosa sono le interfacce utun

Quando un client VPN si connette su macOS, crea un'interfaccia virtuale — di solito chiamata utun0, utun1, utun2, ecc. ("utun" sta per "user tunnel"). Il processo VPN legge i pacchetti che l'OS instrada a quell'interfaccia, li cifra e incapsula, e scrive i pacchetti incapsulati risultanti attraverso la tua interfaccia fisica (en0 per Wi-Fi, tipicamente).

Esegui questo nel Terminale per vedere cosa è attivo:

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

Vedrai qualcosa tipo:

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 è la tua rete reale. utun0 è la VPN. Alcuni client VPN creano più interfacce utun (una per il piano dati, una per il controllo); alcuni creano utun9 o superiore per evitare collisioni con tunnel di hotspot personale stile iOS.

Come monitorare il traffico della banda VPN su Mac con nettop

nettop è integrato in macOS ed è il modo più diretto per vedere quale interfaccia sta usando un processo. L'invocazione rilevante:

sudo nettop -P -m route

Questo mostra le connessioni di ogni processo raggruppate per route. Un processo che parla attraverso la VPN mostrerà il suo traffico via l'interfaccia utun; un processo che bypassa il tunnel mostrerà via en0 (o en1 se ethernet).

Guarda nettop per un minuto, poi chiediti: quali app stanno usando utun0 e quali en0? Se intendi che tutto vada attraverso il tunnel e vedi Slack su en0, è una fuga.

Il flag -P aggrega per processo; -m route mostra la colonna route. Aggiungi -x per i conteggi byte. Aggiungi -c e un delay per il refresh periodico, es. nettop -P -c 2.

Cosa mostra ova per il traffico VPN

Un monitor per app come ova vede le stesse statistiche del kernel che vede nettop e le aggrega nel tempo. La banda attribuita a "Slack" in ova include qualunque cosa Slack abbia inviato — su en0 o utun0 non cambia il totale per processo. Quindi ova risponde "quanto ha usato Slack?" in modo pulito. Attualmente non scompone il numero per app per interfaccia — se ti serve quel livello di dettaglio, nettop è lo strumento.

Per la maggior parte degli utenti VPN va bene. Le domande a cui di solito vuoi rispondere sono:

• "Il client VPN stesso sta usando la banda che mi aspetto?"
• "Qualcosa è schizzato nell'ultima ora?"
• "Quale app è attualmente la più pesante?"

ova ti dà tutte e tre a colpo d'occhio, con il raggruppamento dei processi ausiliari così un PID di Slack helper non appare come riga separata. Il client VPN stesso (Tailscale, Mullvad, ProtonVPN, NordVPN, ecc.) appare come la sua riga, e il suo numero è il totale incapsulato/cifrato che esce dal tuo link fisico.

Rilevare le fughe

Una fuga VPN è quando il traffico di un'app bypassa il tunnel e va direttamente a internet. Le cause includono:

• L'app ha cachato una route prima che la VPN salisse e la sta ancora usando.
• La VPN non instrada certe destinazioni (LAN, multicast, DNS verso un server specifico).
• L'interruttore "exclude local network" di macOS sta facendo quello che dice.
• La VPN è split-tunnel e una particolare app è nella lista bypass.
• IPv6 è abilitato e la VPN instrada solo IPv4 (causa comune).

Il loop diagnostico:

1. Con la VPN connessa, esegui nettop -P -m route e osserva qualsiasi processo che mostri traffico en0 che ti aspettavi tunnellato.
2. Incrocia con ova per la banda per processo. Se un processo mostra traffico in ova ma nessuna riga utun in nettop, sta perdendo.
3. Conferma a livello di rete: visita ipleak.net o dnsleaktest.com da un browser. L'IP riportato dovrebbe essere l'uscita VPN, non casa/ufficio.
4. Per il DNS specificamente: esegui scutil --dns | grep nameserver — i nameserver elencati dovrebbero essere quelli della VPN, non del tuo ISP.

Per IPv6 specificamente, il setup più sicuro è una VPN che instrada esplicitamente IPv6 o disabilitare IPv6 a livello di sistema mentre sei connesso. Disabilitazione per rete: Impostazioni di Sistema > Rete > la tua rete > Dettagli > TCP/IP > Configura IPv6 > Solo link-local.

Misurare l'overhead della VPN

Le VPN aggiungono overhead in due modi: throughput (ottieni meno della tua velocità di linea reale) e latenza (ogni round trip va attraverso un hop in più).

Overhead di throughput

La tassa di cifratura dipende dal protocollo:

• WireGuard: tipicamente 5-10 percento di overhead su un link veloce. Accelerato hardware su Apple Silicon.
• OpenVPN: 15-30 percento di overhead. CPU-bound, più lento di WireGuard ad alte velocità.
• IKEv2/IPsec: 10-20 percento di overhead. Supporto nativo macOS.
• Protocolli proprietari (Lightway, NordLynx basato su WireGuard, ecc.): efficienza grossomodo a livello WireGuard.

Per misurare: esegui uno speed test con la VPN spenta, annota il risultato. Esegui lo stesso test con la VPN attiva, su un server nella stessa area metropolitana dell'endpoint del test off. Il rapporto è l'overhead. Usa ova durante entrambi i test — il traffico per app mostrato per il client speed test dovrebbe essere il throughput a livello applicativo; il rate di sistema durante i test VPN è più alto per il framing di cifratura.

Overhead di latenza

Esegui ping 8.8.8.8 con VPN spenta, annota l'RTT a regime. Connetti VPN, esegui di nuovo ping 8.8.8.8. La differenza è il costo round-trip di cifrare, viaggiare all'uscita VPN e tornare. Cifre tipiche:

• Uscita VPN nella stessa città: +5 a +15 ms.
• Uscita VPN in un altro paese: +50 a +200 ms a seconda della geografia.
• Uscita VPN su un altro continente: +150 a +400 ms.

È fisica inevitabile per la maggior parte — non puoi tunnellare a Tokyo e non pagarne il round trip.

Identificare l'uso di banda della VPN stessa

Il processo del client VPN appare in ova come la sua riga — "Mullvad VPN," "Tailscale," "ProtonVPN," ecc. Il numero che vedi lì è il totale cifrato e incapsulato che esce dal tuo link fisico. Quello è il numero giusto per "quanta banda internet reale sta consumando la VPN".

Un sanity check utile: in qualsiasi momento, la banda riportata dalla VPN dovrebbe essere approssimativamente uguale alla somma di tutte le altre app che la usano, più una piccola percentuale per l'overhead di cifratura. Se sono molto diverse, sta succedendo qualcos'altro — split tunneling, fuga, o il client VPN che fa lavoro di manutenzione (rotazione delle chiavi, peer discovery).

Vedi ova in azione

Un monitor della larghezza di banda nella barra dei menu visibile a colpo d'occhio — locale, firmato, ~3 MB.

Scarica per macOS

VPN sempre attiva: insidie

Diversi client VPN offrono una modalità "kill switch" o "always-on" che blocca tutto il traffico se il tunnel cade. Utile, ma con sorprese:

• I primi secondi dopo il risveglio dallo sleep possono avere traffico sbloccato prima che il tunnel si ristabilisca. Alcuni client lo trattengono esplicitamente; altri no.
• I cambi di rete Wi-Fi (passare da casa al bar) fanno scattare una breve disconnessione. Il kill switch dovrebbe tenere ma l'implementazione varia.
• Alcune app hanno una logica di riconnessione aggressiva — riprovano ogni 100 ms quando il tunnel è giù. Questo è un picco di banda al momento della riconnessione una volta che il tunnel torna.

Guarda ova il momento dopo il risveglio dallo sleep con VPN attiva. Il pattern è di solito: il client VPN stesso mostra una piccola ondata mentre fa ri-handshake, poi entro 5-30 secondi le singole app iniziano a fare ondate mentre riconnettono i propri socket. Se vedi un picco da 200 MB al risveglio, sono tipicamente Slack/Discord/iMessage che recuperano tutti insieme.

Routing per app e split tunnel

Alcuni client VPN supportano l'instradamento di solo app specifiche attraverso il tunnel. Il caso d'uso è "manda il mio client torrent attraverso Mullvad, ma fai andare Slack diretto così le videochiamate non aggiungono latenza VPN".

Verificare le regole di split tunnel con nettop:

sudo nettop -P -m route

Le app split-tunnellate dovrebbero mostrare solo traffico en0; quelle tunnellate dovrebbero mostrare solo utun. Se entrambe appaiono per lo stesso processo, le regole non vengono applicate in modo pulito — di solito perché l'app tiene socket di lunga durata che precedono il cambio di regola. Riavvia l'app per ripulirli.

Monitorare più connessioni VPN

I power user a volte eseguono due VPN contemporaneamente — per esempio, Tailscale per accedere ai servizi interni aziendali più una VPN commerciale (Mullvad, Proton) per la privacy generale di internet. macOS gestisce questo via le tabelle di routing: le route più specifiche (Tailscale 100.64.0.0/10) vincono su quelle più ampie (la route default della VPN commerciale).

Vedrai più interfacce utun in ifconfig. Usa netstat -rn | head -30 per leggere la tabella di routing — la prima route che combacia vince. ova mostra la banda totale per app senza distinguere quale tunnel; per quello, la vista -m route di nettop è il riferimento.

Cosa fare dopo

Un audit di 10 minuti per monitorare la banda VPN su Mac end-to-end:

1. Connetti la VPN.
2. Apri ova nella barra dei menu, annota le app attualmente attive.
3. Esegui sudo nettop -P -m route nel Terminale.
4. Incrocia: ogni app che mostra banda significativa in ova dovrebbe avere le sue connessioni che appaiono sotto utun0 (o qualunque utun usi la tua VPN) in nettop. Qualsiasi traffico en0 da quei processi è candidato a fuga.
5. Visita ipleak.net per confermare che IP e DNS escano attraverso la VPN.
6. Disconnetti, esegui uno speed test, riconnetti, esegui un altro. Calcola l'overhead.

Uscirai da questo sapendo se la tua VPN sta davvero facendo quello che pensi, quanto costa davvero il suo overhead, e quali app tenere d'occhio. È una risposta più solida dell'indicatore "Connesso" nella barra dei menu del tuo client VPN.