Como monitorar a largura de banda de VPN no macOS

Você conecta sua VPN, roda um teste web que reporta o país certo e assume que tudo agora está tunelado. Dois dias depois, você nota que um dos seus apps — digamos, um cliente de chat antigo ou um agente de sync — esteve falando direto com a internet pública o tempo todo, ignorando o túnel completamente. A VPN estava ligada. O vazamento estava num processo que se ligou à interface física antes do túnel subir e nunca soltou.

Monitorar banda de VPN no macOS é em parte confirmar que a VPN está fazendo seu trabalho e em parte flagrar os apps que silenciosamente passam por fora dela. Este post cobre o que são interfaces utun, como ler tráfego de VPN com ferramentas built-in, como detectar vazamentos e como medir o overhead que o túnel adiciona. Se você esteve procurando "monitor de banda de VPN no Mac" porque o dashboard da própria VPN não te conta o suficiente, o toolkit abaixo responde as perguntas mais difíceis.

O que são interfaces utun

Quando um cliente VPN conecta no macOS, ele cria uma interface virtual — geralmente chamada utun0, utun1, utun2, etc. ("utun" significa "user tunnel"). O processo da VPN lê pacotes que o SO roteia para aquela interface, criptografa e encapsula, e escreve os pacotes resultantes pela sua interface física (en0 para Wi-Fi, tipicamente).

Rode isso no Terminal para ver o que está ativo agora:

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

Você vai ver algo como:

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 é sua rede real. utun0 é a VPN. Alguns clientes de VPN criam várias interfaces utun (uma para o plano de dados, outra para controle); alguns criam utun9 ou maior para evitar colisões com túneis estilo Personal Hotspot do iOS.

Como monitorar tráfego de VPN no Mac com nettop

nettop é built-in no macOS e é a forma mais direta de ver qual interface um processo está usando. A invocação relevante:

sudo nettop -P -m route

Isso mostra as conexões de cada processo agrupadas por rota. Um processo falando pela sua VPN vai mostrar tráfego pela interface utun; um processo passando por fora do túnel vai mostrar via en0 (ou en1 se ethernet).

Observe o nettop por um minuto, então pergunte: quais apps estão usando utun0 e quais estão usando en0? Se você pretende que tudo passe pelo túnel e vê o Slack no en0, isso é vazamento.

A flag -P agrega por processo; -m route mostra a coluna de rota. Adicione -x para contagens de bytes. Adicione -c e um delay para refresh periódico, por exemplo nettop -P -c 2.

O que o ova mostra para tráfego de VPN

Um monitor por app como o ova vê as mesmas estatísticas de kernel que o nettop e as agrega no tempo. A banda atribuída ao "Slack" no ova inclui o que o Slack enviou — por en0 ou utun0 não muda o total por processo. Então o ova responde "quanto o Slack usou?" de forma limpa. Atualmente ele não detalha o número por app por interface — se você precisa desse nível de detalhe, o nettop é a ferramenta.

Para a maior parte dos usuários de VPN, isso está bom. As perguntas que você costuma querer responder são:

• "Meu próprio cliente VPN está usando a banda que espero?"
• "Algo deu pico na última hora?"
• "Qual app é o mais pesado agora?"

ova te dá os três de relance, com agrupamento de processos auxiliares para que um PID auxiliar do Slack não vire uma linha separada. O próprio cliente VPN (Tailscale, Mullvad, ProtonVPN, NordVPN, etc.) aparece como sua própria linha, e o número dele é o total empacotado/criptografado saindo pelo seu link físico.

Detectando vazamentos

Um vazamento de VPN é quando o tráfego de um app passa por fora do túnel e vai direto para a internet. Causas incluem:

• O app cacheou uma rota antes da VPN subir e ainda está usando.
• A VPN não roteia certos destinos (LAN, multicast, DNS para um servidor específico).
• O toggle "excluir rede local" do macOS está fazendo o que diz.
• A VPN está com split tunneling e um app específico está na lista de bypass.
• IPv6 está habilitado e a VPN só roteia IPv4 (causa comum).

O loop de diagnóstico:

1. Com a VPN conectada, rode nettop -P -m route e observe se algum processo mostra tráfego en0 que você esperava estar tunelado.
2. Cruze com ova para a banda por processo. Se um processo mostra tráfego no ova mas nenhuma linha utun no nettop, está vazando.
3. Confirme no nível de rede: visite ipleak.net ou dnsleaktest.com num navegador. O IP reportado deve ser a saída da VPN, não sua casa/escritório.
4. Para DNS especificamente: rode scutil --dns | grep nameserver — os nameservers listados devem ser os da sua VPN, não os do ISP.

Para IPv6 especificamente, a configuração mais segura é uma VPN que rotie IPv6 explicitamente ou desabilitar IPv6 no sistema enquanto conectado. Desabilitar por rede: Ajustes do Sistema > Rede > sua rede > Detalhes > TCP/IP > Configurar IPv6 > Apenas link-local.

Medindo o overhead da VPN

VPNs adicionam overhead de duas formas: throughput (você recebe menos da sua velocidade de linha real) e latência (cada round trip passa por um hop a mais).

Overhead de throughput

O imposto de criptografia depende do protocolo:

• WireGuard: tipicamente 5 a 10 por cento de overhead num link rápido. Acelerado por hardware no Apple Silicon.
• OpenVPN: 15 a 30 por cento de overhead. Limitado por CPU, mais lento que WireGuard em altas velocidades.
• IKEv2/IPsec: 10 a 20 por cento de overhead. Suporte nativo no macOS.
• Protocolos proprietários (Lightway, NordLynx baseado em WireGuard, etc.): eficiência aproximada de WireGuard.

Para medir: rode um teste de velocidade com a VPN desligada, anote o resultado. Rode o mesmo teste com a VPN ligada, para um servidor na mesma região metropolitana do endpoint do teste sem VPN. A razão é o overhead. Use o ova durante ambos os testes — o tráfego por app mostrado para o cliente do teste de velocidade deve ser o throughput de camada de aplicação; a taxa do sistema durante testes com VPN é maior por causa do framing de criptografia.

Overhead de latência

Rode ping 8.8.8.8 com VPN desligada, anote o RTT em estado estacionário. Conecte a VPN, rode ping 8.8.8.8 de novo. A diferença é o custo de round-trip de criptografar, ir até a saída da VPN e voltar. Números típicos:

• Saída da VPN na mesma cidade: +5 a +15 ms.
• Saída da VPN em outro país: +50 a +200 ms dependendo da geografia.
• Saída da VPN em outro continente: +150 a +400 ms.

Isso é física inevitável em sua maior parte — você não pode tunelar para Tóquio e não pagar o round trip.

Identificando o uso de banda da própria VPN

O processo do cliente VPN aparece no ova como sua própria linha — "Mullvad VPN", "Tailscale", "ProtonVPN", etc. O número que você vê ali é o total criptografado e empacotado saindo pelo seu link físico. Esse é o número certo para "quanta banda real de internet a VPN está consumindo".

Uma checagem útil de sanidade: a qualquer momento, a banda reportada da VPN deve ser aproximadamente igual à soma de todos os outros apps usando, mais um pequeno percentual de overhead de criptografia. Se forem muito diferentes, algo mais está acontecendo — split tunneling, vazamento ou o cliente VPN fazendo trabalho de manutenção (rotação de chaves, descoberta de peers).

Veja o ova em ação

Um monitor de banda na barra de menu para olhar de relance — local, assinado, ~3 MB.

Baixar para macOS

VPN sempre ligada: armadilhas

Vários clientes de VPN oferecem um modo "kill switch" ou "sempre ligado" que bloqueia todo o tráfego se o túnel cair. Útil, mas com surpresas:

• Os primeiros segundos depois do wake-from-sleep podem ter tráfego desbloqueado antes do túnel se re-estabelecer. Alguns clientes seguram explicitamente; outros não.
• Mudanças de rede Wi-Fi (sair de casa para a cafeteria) disparam uma desconexão breve. O kill switch deveria segurar mas a implementação varia.
• Alguns apps têm lógica de reconexão agressiva — fazem retry a cada 100 ms quando o túnel está desligado. Isso é um pico de banda no momento da reconexão quando o túnel volta.

Observe o ova no momento depois de acordar do sleep com a VPN ligada. O padrão costuma ser: o próprio cliente VPN mostra um pequeno surto enquanto re-handshake, então em 5 a 30 segundos apps individuais começam a surtar enquanto reconectam seus próprios sockets. Se você vê um pico de 200 MB no wake, costuma ser Slack/Discord/iMessage todos se atualizando ao mesmo tempo.

Roteamento por app e split tunnels

Alguns clientes de VPN suportam rotear só apps específicos pelo túnel. O caso de uso é "manda meu cliente de torrent pela Mullvad, mas deixa o Slack ir direto para chamadas de vídeo não somarem latência da VPN".

Verificando regras de split tunnel com nettop:

sudo nettop -P -m route

Os apps em split tunnel devem mostrar só tráfego en0; os tunelados devem mostrar só utun. Se ambos aparecem para o mesmo processo, as regras não estão sendo aplicadas de forma limpa — geralmente porque o app mantém sockets de longa duração que precedem a mudança de regra. Reinicie o app para limpar.

Monitorando múltiplas conexões VPN

Usuários avançados às vezes rodam duas VPNs ao mesmo tempo — por exemplo, Tailscale para acessar serviços internos da empresa mais uma VPN comercial (Mullvad, Proton) para privacidade geral de internet. O macOS lida com isso via tabelas de roteamento: rotas mais específicas (100.64.0.0/10 do Tailscale) ganham sobre as mais amplas (a rota padrão da VPN comercial).

Você vai ver várias interfaces utun em ifconfig. Use netstat -rn | head -30 para ler a tabela de roteamento — a primeira rota correspondente ganha. ova mostra banda total por app sem distinguir qual túnel; para isso, a visão -m route do nettop é a referência.

O que fazer a seguir

Uma auditoria de 10 minutos para monitorar banda de VPN no Mac de ponta a ponta:

1. Conecte a VPN.
2. Abra o ova na barra de menu, anote os apps atualmente ativos.
3. Rode sudo nettop -P -m route no Terminal.
4. Cruze: cada app mostrando banda significativa no ova deve ter suas conexões aparecendo sob utun0 (ou qual utun sua VPN usa) no nettop. Qualquer tráfego en0 desses processos é candidato a vazamento.
5. Visite ipleak.net para confirmar IP e DNS saindo pela VPN.
6. Desconecte, rode um teste de velocidade, reconecte, rode outro. Compute o overhead.

Você sai disso sabendo se sua VPN está de fato fazendo o que você acha que está, quanto o overhead realmente custa e quais apps vigiar. Essa é uma resposta mais forte do que o indicador "Conectado" na barra de menu do seu cliente VPN.