Interface utun da VPN no Mac ativa mas o tráfego falha? Verifique o ifconfig

Você conectou a VPN, executou ifconfig e encontrou uma entrada utun4 com um endereço. O site de que você precisava continua dando time-out. Essa lacuna é normal: a listagem prova que existe uma interface virtual, não que o seu cliente a possua, que a rota que você considera escolha essa interface nem que os pacotes a atravessem. Deixei de confiar no nome da interface depois de passar uma tarde culpando o túnel errado em um laptop que já tinha três entradas utun antes de eu instalar qualquer coisa.

O que uma linha utun realmente contém

Execute ifconfig -a quando quiser o quadro completo. Chamado sem argumentos, ifconfig imprime apenas interfaces que estão ativas agora, e é por isso que um túnel que falhou ao iniciar pode faltar na saída que as pessoas colam nos tickets. ifconfig -l retorna apenas os nomes, e essa é a forma mais rápida de saber se um novo utun apareceu depois que você conectou.

Ler uma única interface é onde mora o detalhe útil, e um túnel conectado costuma parecer assim.

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Três campos carregam a resposta. UP e RUNNING dizem que o kernel está disposto a usar a interface. POINTOPOINT mais o --> endereço do par é a assinatura de um túnel e não de um link físico. O mtu valor explica uma classe inteira de relatos de "conecta, então trava", porque interfaces utun costumam subir com MTU reduzida, 1380 em várias builds do macOS, e o cliente pode sobrescrevê-la. A lista de campos é curta o bastante para folhear uma vez no manual do ifconfig que a Apple distribui.

Encontre o processo por trás da interface

ifconfig não tem o conceito de aplicação dona. Dois clientes VPN, um serviço do sistema e um túnel sobrando da semana passada produzem entradas que parecem idênticas neste nível. No meu próprio Mac, utun0 até utun3 já existiam antes de eu configurar qualquer coisa; o Continuity e o iCloud Private Relay também usam túneis, e nenhum deles é a conexão que você está diagnosticando.

Para túneis que registram uma configuração no sistema, scutil --nc list é a correlação mais rápida, imprime cada configuração com o status e o ID de serviço, e uma conectada é marcada como tal.

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Clientes que rodam o próprio processo de túnel em vez de registrar uma configuração nunca aparecem ali. O Tunnelblick e uma instância de openvpn pela linha de comando entram nesse grupo, então verifique também a tabela de processos: ps -Ao pid,comm | grep -i openvpn. Quando um processo é dono do túnel, o número utun pertence a esse processo e a mais nada.

Teste o endereço antes de testar a rota

Uma interface pode estar ativa sem endereço utilizável. Um perfil só IPv6 mostra uma entrada fe80:: link-local e nada na linha inet, e um cliente que falhou ao aplicar um endereço empurrado deixa exatamente a mesma forma. Se o seu destino é IPv4 e o túnel não tem endereço IPv4, a questão de roteamento já está resolvida.

A MTU merece uma verificação separada, porque a falha não parece um problema de tamanho. Parece uma conexão que autentica e então fica silenciosa assim que começa uma transferência grande. Envie uma sonda que não pode ser fragmentada, dimensionada para que o pacote caiba na MTU da interface; para uma MTU de 1400, o payload é de 1372 bytes:

ping -D -s 1372 10.8.0.5

Uma resposta significa que pacotes desse tamanho atravessam o túnel. Silêncio enquanto pings pequenos funcionam aponta para a MTU ou para algo que descarta ICMP no caminho, não para a autenticação, que já terminou antes de você sequer ter uma interface.

Prove que o destino escolhe o túnel

A pergunta que importa não é se utun4 existe, mas se o tráfego para um endereço específico sai por ele. route -n get responde isso para um único destino e imprime o gateway e a interface que usaria:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Se o mesmo comando relatar en0, sua configuração de split tunneling está fazendo o que lhe foi dito e nenhuma inspeção da interface vai mudar isso. Use netstat -rn -f inet quando precisar da rota padrão e da tabela inteira em uma só visão.

Os contadores decidem se os pacotes realmente se movem. netstat -ib relata totais de pacotes e bytes por interface, incluindo entradas utun; os números são cumulativos, então leia duas vezes com um intervalo e compare:

netstat -ib | grep utun4

Contadores congelados enquanto a aplicação continua tentando significam que o kernel nunca entregou um pacote à interface. Contadores subindo nos dois sentidos enquanto a aplicação ainda falha levam a investigação para a outra ponta do túnel.

Quando nenhum utun aparece

Uma lista de interfaces vazia depois de um login que pareceu bem-sucedido geralmente significa que o túnel nunca iniciou, não que ifconfig o esteja escondendo. Verifique o status do cliente, depois o do sistema: uma Network Extension que nunca foi aprovada, ou que o macOS desativou depois de uma atualização, não deixa interface para trás. A aprovação fica nos Ajustes do Sistema em Itens de Login e Extensões, e uma entrada obsoleta ali vale uma nova alternada antes de reinstalar qualquer coisa.

A numeração utun não é estável entre reconexões. Você pode obter utun5 onde utun4 existia dez minutos atrás, porque a interface antiga é desmontada e o kernel entrega o próximo índice livre. Scripts que fixam um nome quebram em silêncio naquele momento; combine pelo endereço ou pela rota.

Mantenha o lado da leitura como somente leitura. sudo ifconfig utun4 down interrompe o túnel, e em um perfil de túnel completo leva junto sua sessão remota, o que é uma troca ruim quando você só estava coletando evidências. Nada do que você precisa aqui exige root: ler flags, endereços e contadores funciona com seu usuário normal.

Faça as verificações em ordem na próxima vez que um túnel no Mac se comportar mal: confirme que um utun apareceu com ifconfig -l, leia as flags, os endereços e a MTU, atribua-o a um processo, pergunte ao route -n get qual interface o destino usa e observe o netstat -ib se mover. Cada passo elimina uma camada diferente, e o primeiro que voltar errado é onde a correção deve entrar.