Abri o qBittorrent num Mac mini, coloquei Network Interface em utun4, reiniciei e depois passei uma tarde a ver um torrent parado na obtenção de metadados enquanto a VPN continuava a mostrar uma ligação saudável. A definição não estava errada em princípio; o nome estava desatualizado. O macOS atribui números utun quando os serviços arrancam, por isso o utun4 que estava correto na semana anterior apontava para um túnel que já não existia, e o cliente estava a ligar os seus sockets a um dispositivo sem rota. A sequência abaixo é a que uso agora: ler a interface a partir do túnel em execução, selecioná-la no cliente, reiniciar a sessão e depois comprovar a ligação com uma transferência e uma desconexão deliberada.

Abra Avançado e encontre o campo da interface

Na janela do qBittorrent, abra as Preferências com Cmd+, e vá à página Avançado. Network Interface é o campo que importa: lista os nomes das interfaces do sistema e, por predefinição, está em Any Interface, o que significa que o sistema operativo escolhe uma rota para cada socket que o cliente abre. A referência de opções do projeto documenta o campo e esse valor predefinido, e é a mesma definição em todas as plataformas, embora os nomes lá dentro não sejam iguais.

Dois detalhes fazem tropeçar aqui. A lista mostra nomes de dispositivos como en0, en1 e utun0 até utun9, nunca o nome do produto do fornecedor de VPN, por isso precisa da correspondência antes de escolher algo sensato. E a seleção é aplicada quando a sessão BitTorrent arranca, não no momento em que prime OK, por isso uma alteração que parece guardada pode ainda estar a correr na ligação antiga.

Saia da aplicação corretamente com Cmd+Q e confirme que o processo desapareceu antes de a reabrir. Fechar a janela apenas a esconde, e um cliente escondido mantém a sessão, a porta de escuta e a interface antiga.

pgrep -fl qbittorrent

Encontre a interface que a sua VPN possui de facto

Ligue primeiro a VPN, através do cliente do próprio fornecedor, e depois leia a visão do sistema em vez do menu do cliente. Os comandos abaixo listam cada interface com os seus endereços, mostram quais o sistema considera ativas e imprimem a tabela de rotas; está à procura do dispositivo utun que transporta o intervalo privado que o seu fornecedor atribui.

ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5

Três leituras dizem-lhe qual dispositivo é o túnel. A entrada utun precisa de um endereço inet que pertença ao pool da VPN. scutil --nwi mostra quais interfaces o sistema considera ativas e qual é a primária. netstat -rn mostra para onde aponta a rota predefinida, e se essa rota ainda aponta para en0 enquanto um utun tem endereço, o túnel não transporta todo o tráfego, o que altera o que a ligação fará mais tarde.

Quando podem existir dois túneis ao mesmo tempo, por exemplo um perfil de trabalho e um pessoal, ambos os dispositivos utun estão presentes e só um é útil. Os contadores de bytes decidem a questão: anote os contadores, carregue uma página ou inicie uma transferência pequena e veja qual se moveu.

netstat -ib | grep utun

Também não trate o número como estável. Uma reconexão pode dar ao mesmo túnel outro nome utun, e um serviço iCloud ou Continuity pode ocupar utun0 muito antes de a sua VPN se ligar.

Ajuste a ligação ao âmbito do túnel

O campo liga um dispositivo, e é tudo o que faz. Se a VPN for um túnel completo que encaminha 0.0.0.0/0 para o utun, ligar a esse dispositivo envia cada ligação de par e cada pedido de tracker pela VPN. Se a VPN for um túnel dividido que só encaminha algumas sub-redes, ligar ao utun envia o tráfego dos pares para um dispositivo sem rota para esses pares, e as transferências param em vez de fugirem. Ambos os resultados são mais seguros do que Any Interface, mas só um mantém o cliente a funcionar. Nada fora do cliente muda: os navegadores e outras aplicações mantêm as suas próprias rotas, por isso um requisito que cubra todas as aplicações tem de ser imposto do lado da VPN.

Leia a situação antes de selecionar seja o que for:

What you seeWhat it means for the bind
A utun with a provider address and the default route pointing at itFull tunnel; the bind covers peer and tracker traffic
A utun with a provider address but the default route still on en0Split tunnel; the bind will stall transfers unless the provider routes 0.0.0.0/0
No utun carrying a provider addressThe VPN is down or connects on demand; bring it up before selecting
A utun number that changed since the last sessionThe saved name is stale; reselect and restart

A família de endereços também importa. Um fornecedor que só atribui IPv4 deixa a interface ligada sem endereço IPv6, por isso os pares IPv6 falham em vez de escaparem pelo Wi-Fi. Separadamente, ligar sockets não fixa a resolução de nomes: os nomes de anfitrião dos trackers são resolvidos pelo resolvedor do macOS, que segue a configuração DNS do sistema e não o dispositivo selecionado.

Três formas como uma seleção que parece correta falha

A primeira falha é não reiniciar. O campo mostra utun4, as preferências parecem configuradas, e uma transferência de teste continua a sair pelo Wi-Fi porque a sessão em curso manteve a ligação antiga. Feche por completo, confirme com pgrep, reabra e comece a transferência de novo.

A segunda é o nome desatualizado após uma reconexão. Assim que o dispositivo ligado desaparece, as ligações de par falham e o cliente tende a reportar erros de tracker em vez de uma mensagem limpa de que a interface desapareceu, o que se lê como um torrent morto. Volte a ler ifconfig, selecione o novo nome e reinicie.

A terceira é assumir que a ligação falha fechada. Selecionar uma interface pede ao sistema que associe sockets a um nome de dispositivo; o que acontece quando esse nome falta ou é reciclado não é garantido pelo ecrã de definições. O teste de desconexão da secção seguinte é a única prova que conta.

Verifique com uma transferência real e uma desconexão

Use uma transferência que lhe seja permitida, como uma imagem de distribuição Linux, e inicie-a com a VPN ligada. Observe os contadores por interface antes e depois e compare-os com o contador de dados do próprio cliente VPN; ambos devem subir em conjunto enquanto a lista de pares enche.

netstat -ib | grep utun
pgrep -fl qbittorrent

Depois desligue a VPN a partir da sua própria interface e observe a transferência. Os pares devem desaparecer, e as novas ligações devem falhar pouco depois de o túnel cair. Se o débito continuar, a ligação não está em vigor e está de volta ao passo de reiniciar, não à firewall.

Volte a ligar e confirme o nome selecionado outra vez, porque o túnel pode regressar com outro utun. Uma nota curta com o tipo de túnel, o nome da interface e o comportamento esperado quando a VPN cai poupa a sessão seguinte: esta definição é por máquina e por fornecedor, e não sobrevive nem a uma atualização do cliente nem a uma mudança de aplicação VPN.

Artigos relacionados