Por que a VPN do seu Mac cai quando você conecta um iPhone via USB

Você conecta um iPhone para carregá-lo e, um minuto depois, a VPN do seu Mac para de passar tráfego. Ajustes do Sistema mostra um novo serviço chamado iPhone USB, e a atitude óbvia é apagá-lo. Essa atitude costuma estar errada. O serviço pode ser o Ponto de Acesso Pessoal do telefone, ou pode ser um vínculo que o Xcode e as ferramentas de dispositivos usam para falar com o telefone, e os dois se comportam de forma bem diferente, então a identificação precisa vir antes da exclusão.

Passo 1: Leia o serviço que o telefone realmente criou

Abra Ajustes do Sistema, depois Rede, e compare a lista de serviços com o telefone desconectado e conectado. No macOS atual o serviço aparece como iPhone USB. Observe se está ativo, onde fica na ordem de serviços e se o Mac o usa para a rota padrão. A ordem dos serviços importa porque o macOS escolhe o serviço ativo mais alto que consegue alcançar um destino, não aquele cujo nome você reconhece.

O guia da Apple sobre o Ponto de Acesso Pessoal descreve o mecanismo: enquanto o Ponto de Acesso Pessoal está ativado no telefone, conectá-lo por USB pode fazer o Mac usar a conexão celular do telefone, mesmo quando você só queria carregar. Isso não é um defeito do cliente VPN; a tabela de rotas está seguindo um serviço que subiu antes do Wi-Fi.

Se o serviço existe mas permanece inativo com o telefone conectado, você provavelmente está vendo uma conexão apenas de carga ou um vínculo de dispositivo, não um hotspot. Mantenha essa distinção, porque os dois passos seguintes a testam em vez de adivinhá-la pelo ícone.

Passo 2: Verifique qual rota o endpoint da VPN usa

Leia a rota até o endereço resolvido do servidor VPN, não até um site. route -n get é somente leitura e imprime a interface e o gateway que o kernel usaria, e as duas linhas importam.

scutil --dns | head -20
route -n get 203.0.113.10

O endereço acima é um marcador de documentação. Substitua-o pelo endpoint que seu cliente mostra e use route -n get -inet6 para um endpoint IPv6. Compare a saída com o telefone desconectado e conectado, e não adicione nem remova rotas entre as duas leituras. Se a interface mudar de en0 para a interface iPhone USB, a rota do hotspot ganhou a consulta e a conexão externa da VPN agora vai pela rede celular.

Uma mudança de rota não explica toda falha. O cliente ainda pode alcançar o servidor e falhar depois no tráfego interno do túnel, porque o novo caminho tem outra MTU ou a operadora bloqueia o protocolo. Leia o erro do próprio cliente antes de mudar qualquer coisa: um tempo limite do aperto de mão externo aponta para alcançabilidade, enquanto um túnel estabelecido que deixa de passar tráfego aponta para MTU, DNS ou política.

Passo 3: Separe um hotspot de um vínculo de comunicação com o dispositivo

O Xcode 15 e posteriores falam com um dispositivo conectado por USB por um canal de rede que inclui IPv6 de link local, então um Mac de desenvolvimento pode mostrar uma interface extra que nada tem a ver com acesso à internet. A nota técnica TN3158 da Apple documenta esse comportamento e avisa que a VPN ou a filtragem de segurança podem interferir nisso. É o contrário do problema do hotspot: a VPN não quebra porque o telefone oferece internet; a conexão do dispositivo quebra porque a VPN a captura.

Duas observações separam os casos sem captura de pacotes. Primeiro, verifique se a interface tem endereço roteável e rota padrão, ou apenas um endereço fe80:: de link local; só link local significa que não há caminho para a internet. Segundo, feche a VPN e veja se o Xcode consegue alcançar o dispositivo de novo. Se conseguir, as rotas ou o filtro de conteúdo da VPN capturam o tráfego de link local, e a correção pertence à configuração do túnel dividido ou do filtro, não ao painel Rede.

ifconfig | grep -A4 -E '^en[0-9]+:'
netstat -rn -f inet6 | head

Não julgue apenas pelo nome da interface. O macOS cria e destrói essas interfaces conforme os dispositivos se conectam, e o número en é atribuído em tempo de execução, então o mesmo Mac pode mostrar um número diferente após reiniciar ou trocar o cabo.

Passo 4: Reproduza a falha com uma variável por vez

Depois de saber qual serviço está envolvido, reproduza o problema em ordem fixa. Comece com o telefone desconectado e a VPN conectada. Conecte o telefone com o Ponto de Acesso Pessoal desligado, espere a lista Rede se estabilizar e rode a consulta de rota de novo. Desconecte, ative o Ponto de Acesso Pessoal, conecte outra vez e repita. Anote interface, gateway e erro do cliente para cada um dos três estados, e você tem uma comparação em vez de uma lembrança.

Se a VPN falha só no estado de hotspot, mantenha o telefone fora desse caminho: desligue o Ponto de Acesso Pessoal enquanto carrega, ou mova o serviço iPhone USB para baixo do Wi-Fi na ordem de serviços. Se falha em todo estado conectado, inclusive com o hotspot desligado, veja como o cliente lida com uma transição de rede. Alguns clientes derrubam o túnel quando o serviço primário muda e exigem reconexão; isso é comportamento do cliente, não um defeito do telefone.

Mude uma coisa por tentativa. Apagar o serviço, redefinir a configuração da VPN e reinstalar o cliente no mesmo minuto deixam você com um Mac funcionando e nenhuma ideia de qual ação o consertou.

Passo 5: Decida o que manter e o que verificar

Deixe o vínculo do dispositivo em paz. Remover uma interface que o Xcode usa não conserta uma rota de VPN, e quebra a distribuição em dispositivos até a próxima conexão. Se o serviço de hotspot não é desejado de verdade, primeiro desligue o Ponto de Acesso Pessoal no telefone; esse é o controle documentado e ele sobrevive a um reinício.

Se você remover um serviço, remova o que identificou e depois verifique duas coisas: a rota até o endpoint da VPN voltou para a interface esperada, e o túnel passa tráfego para um endereço interno, não só para a internet. Anote a ordem dos serviços e a versão do cliente, porque uma atualização do macOS pode mudar como o telefone aparece.

Depois classifique a falha que você realmente viu. Um tempo limite do aperto de mão, um travamento de MTU depois que o túnel sobe e respostas DNS vindas da operadora são três problemas diferentes com três correções diferentes. O serviço USB é o gatilho nos três; a causa, raramente.