Como vincular qBittorrent a unha interface VPN en macOS
Configure Network Interface nas opcións avanzadas de qBittorrent en macOS, asigne os nomes utun ao túnel activo, reinicie o cliente e demostre a vinculación cunha transferencia.
Abrín qBittorrent nun Mac mini, puxen Network Interface en utun4, reiniciei e despois pasei unha tarde vendo como un torrent quedaba na obtención de metadatos mentres a VPN seguía mostrando unha conexión sa. O axuste non era incorrecto en principio; o nome estaba obsoleto. macOS asigna números utun cando arrincan os servizos, así que o utun4 que fora correcto a semana anterior apuntaba a un túnel que xa non existía, e o cliente vinculaba os seus sockets a un dispositivo sen ruta. A secuencia de abaixo é a que uso agora: ler a interface do túnel en funcionamento, seleccionala no cliente, reiniciar a sesión e despois demostrar a vinculación cunha transferencia e unha desconexión deliberada.
Abra Avanzado e atope o campo de interface
Na xanela de qBittorrent, abra Preferencias con Cmd+, e vaia á páxina Avanzado. Network Interface é o campo que importa: lista os nomes de interface do sistema e por defecto está en Any Interface, o que significa que o sistema operativo escolle unha ruta para cada socket que abre o cliente. A referencia de opcións do proxecto documenta o campo e ese valor por defecto, e é o mesmo axuste en todas as plataformas aínda que os nomes que contén non o sexan.
Dous detalles fan tropezar aquí. A lista mostra nomes de dispositivo como en0, en1 e utun0 ata utun9, nunca o nome do produto do provedor de VPN, así que necesita a correspondencia antes de escoller algo sensato. E a selección aplícase cando arrinca a sesión de BitTorrent, non no momento de premer OK, así que un cambio que parece gardado pode seguir funcionando coa vinculación antiga.
Pechar a aplicación correctamente con Cmd+Q e confirme que o proceso desapareceu antes de volver abrila. Pechar a xanela só a oculta, e un cliente oculto conserva a súa sesión, o seu porto de escoita e a súa interface antiga.
pgrep -fl qbittorrentAtope a interface que o seu VPN posúe de verdade
Conecte primeiro a VPN, co cliente propio do provedor, e despois lea a visión do sistema en lugar do menú do cliente. Os comandos de abaixo listan cada interface coas súas direccións, mostran cales considera activas o sistema e imprimen a táboa de rutas; busque o dispositivo utun que leva o rango privado que lle asigna o seu provedor.
ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5Tres lecturas dinlle que dispositivo é o túnel. A entrada utun necesita unha dirección inet que pertenza ao pool da VPN. scutil --nwi mostra que interfaces considera activas o sistema e cal é a primaria. netstat -rn mostra cara a onde apunta a ruta por defecto, e se esa ruta segue apuntando a en0 mentres un utun ten dirección, o túnel non leva todo o tráfico, o que cambia o que fará a vinculación máis adiante.
Cando poden existir dous túneles á vez, por exemplo un perfil de traballo e un persoal, ambos os dispositivos utun están presentes e só un é útil. Os contadores de bytes resolven a pregunta: anote os contadores, cargue unha páxina ou inicie unha transferencia pequena e vexa cal se moveu.
netstat -ib | grep utunTampouco trate o número como estable. Unha reconexión pode dar ao mesmo túnel outro nome utun, e un servizo de iCloud ou Continuity pode ocupar utun0 moito antes de que se conecte o seu VPN.
Axuste a vinculación ao alcance do túnel
O campo vincula un dispositivo, e iso é todo o que fai. Se a VPN é un túnel completo que encamiña 0.0.0.0/0 dentro do utun, vincular a ese dispositivo envía cada conexión de par e cada petición de tracker pola VPN. Se a VPN é un túnel dividido que só encamiña unhas poucas subredes, vincular ao utun envía o tráfico de pares a un dispositivo sen ruta para eses pares, e as transferencias detéñense en lugar de filtrarse. Ambos os resultados son máis seguros que Any Interface, pero só un mantén o cliente funcionando. Nada fóra do cliente cambia: os navegadores e outras aplicacións conservan as súas propias rutas, así que un requisito que cubra todas as aplicacións necesita aplicarse desde o lado da VPN.
Lea a situación antes de seleccionar nada:
| 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 familia de direccións tamén importa. Un provedor que só asigna IPv4 deixa a interface vinculada sen dirección IPv6, así que os pares IPv6 fallan en lugar de escaparse polo Wi-Fi. Por separado, vincular sockets non fixa a resolución de nomes: os nomes de host dos trackers resólvense polo resolutor de macOS, que segue a configuración DNS do sistema e non o dispositivo seleccionado.
Tres formas en que falla unha selección que parece correcta
O primeiro fallo é non reiniciar. O campo mostra utun4, as preferencias parecen configuradas, e unha transferencia de proba segue saíndo polo Wi-Fi porque a sesión en curso conservou a vinculación antiga. Peche de todo, confirme con pgrep, volva abrir e comece a transferencia de novo.
O segundo é o nome obsoleto tras unha reconexión. Cando o dispositivo vinculado desaparece, as conexións de pares fallan e o cliente tende a informar de erros de tracker en lugar dunha mensaxe limpa de que a interface se foi, o que se le como un torrent morto. Volva ler ifconfig, seleccione o nome novo e reinicie.
O terceiro é supoñer que a vinculación falla pechada. Seleccionar unha interface pide ao sistema que adjunte sockets a un nome de dispositivo; o que ocorre cando ese nome falta ou se recicla non o garante a pantalla de axustes. A proba de desconexión da sección seguinte é a única evidencia que conta.
Verifique cunha transferencia real e unha desconexión
Use unha transferencia que teña permitido executar, como unha imaxe de distribución Linux, e comece coa VPN conectada. Observe os contadores por interface antes e despois e compáreos co contador de datos do propio cliente VPN; ambos deberían subir xuntos mentres se enche a lista de pares.
netstat -ib | grep utun
pgrep -fl qbittorrentDespois desconecte a VPN desde a súa propia interface e observe a transferencia. Os pares deberían desaparecer, e as conexións novas deberían fallar pouco despois de que caia o túnel. Se o rendemento continúa, a vinculación non está en efecto e volve ao paso de reiniciar, non ao cortafogos.
Reconecte e comprobe o nome seleccionado outra vez, porque o túnel pode volver con outro utun. Unha nota breve co tipo de túnel, o nome da interface e o comportamento esperado cando cae a VPN aforra a sesión seguinte: este axuste é por máquina e por provedor, e non sobrevive nin a unha actualización do cliente nin a un cambio de aplicación VPN.