Como ligar o qBittorrent a uma interface VPN no macOS
Defina Network Interface nas opções avançadas do qBittorrent no macOS, mapeie os nomes utun ao túnel ativo, reinicie o cliente e comprove a ligação com uma transferência.
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 qbittorrentEncontre 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 5Trê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 utunTambé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 see | What it means for the bind |
|---|---|
| A utun with a provider address and the default route pointing at it | Full tunnel; the bind covers peer and tracker traffic |
| A utun with a provider address but the default route still on en0 | Split tunnel; the bind will stall transfers unless the provider routes 0.0.0.0/0 |
| No utun carrying a provider address | The VPN is down or connects on demand; bring it up before selecting |
| A utun number that changed since the last session | The 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 qbittorrentDepois 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.