Com enllaçar qBittorrent a una interfície VPN al macOS
Definiu Network Interface a les opcions avançades del qBittorrent al macOS, assigneu els noms utun al túnel actiu, reinicieu el client i demostreu l'enllaç amb una transferència.
Vaig obrir el qBittorrent en un Mac mini, vaig posar Network Interface a utun4, el vaig reiniciar i després vaig passar una tarda mirant com un torrent es quedava a l'obtenció de metadades mentre la VPN encara mostrava una connexió sana. El paràmetre no era dolent de principi; el nom era obsolet. El macOS assigna números utun quan s'inicien els serveis, així que l'utun4 que era correcte la setmana anterior apuntava a un túnel que ja no existia, i el client enllaçava els seus sockets a un dispositiu sense ruta. La seqüència de sota és la que faig servir ara: llegir la interfície del túnel en funcionament, seleccionar-la al client, reiniciar la sessió i després demostrar l'enllaç amb una transferència i una desconnexió deliberada.
Obriu Avançat i trobeu el camp d'interfície
A la finestra del qBittorrent, obriu les preferències amb Cmd+, i aneu a la pàgina Avançat. Network Interface és el camp que importa: llista els noms d'interfície del sistema i per defecte és Any Interface, cosa que vol dir que el sistema operatiu tria una ruta per a cada socket que obre el client. La referència d'opcions del projecte documenta el camp i aquest valor per defecte, i és el mateix paràmetre a totes les plataformes encara que els noms que hi surten no ho siguin.
Dos detalls fan caure la gent aquí. La llista mostra noms de dispositiu com en0, en1 i utun0 fins a utun9, mai el nom del producte del proveïdor de VPN, així que necessiteu la correspondència abans de triar res sensat. I la selecció s'aplica quan comença la sessió de BitTorrent, no en el moment que premeu OK, així que un canvi que sembla desat pot estar funcionant encara amb l'enllaç antic.
Tanqueu l'aplicació correctament amb Cmd+Q i confirmeu que el procés ha desaparegut abans de tornar-la a obrir. Tancar la finestra només l'amaga, i un client amagat conserva la sessió, el port d'escolta i la interfície antiga.
pgrep -fl qbittorrentTrobeu la interfície que la vostra VPN posseeix de veritat
Connecteu primer la VPN, amb el client propi del proveïdor, i després llegiu la visió del sistema en lloc del menú del client. Les ordres de sota llisten cada interfície amb les seves adreces, mostren quines considera actives el sistema i imprimeixen la taula d'encaminament; busqueu el dispositiu utun que porta el rang privat que us assigna el proveïdor.
ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5Tres lectures us diuen quin dispositiu és el túnel. L'entrada utun necessita una adreça inet que pertanyi al pool de la VPN. scutil --nwi mostra quines interfícies considera actives el sistema i quina és la primària. netstat -rn mostra on apunta la ruta per defecte, i si aquesta ruta encara apunta a en0 mentre un utun té adreça, el túnel no porta tot el trànsit, cosa que canvia què farà l'enllaç més endavant.
Quan poden existir dos túnels alhora, per exemple un perfil de feina i un de personal, tots dos dispositius utun són presents i només un és útil. Els comptadors de bytes resolen la pregunta: anoteu els comptadors, carregueu una pàgina o inicieu una transferència petita i mireu quin s'ha mogut.
netstat -ib | grep utunNo tracteu el número com a estable. Una reconnexió pot donar al mateix túnel un nom utun diferent, i un servei d'iCloud o Continuity pot ocupar utun0 molt abans que es connecti la vostra VPN.
Ajusteu l'enllaç a l'abast del túnel
El camp enllaça un dispositiu, i no fa res més. Si la VPN és un túnel complet que encamina 0.0.0.0/0 dins de l'utun, enllaçar a aquest dispositiu envia cada connexió de pare i cada petició de tracker per la VPN. Si la VPN és un túnel dividit que només encamina unes quantes subxarxes, enllaçar a l'utun envia el trànsit de pare a un dispositiu sense ruta per a aquests parells, i les transferències s'aturen en lloc de filtrar-se. Tots dos resultats són més segurs que Any Interface, però només un manté el client funcionant. Res fora del client no canvia: els navegadors i altres aplicacions conserven les seves rutes, així que un requisit que cobreixi totes les aplicacions necessita aplicar-se des del costat de la VPN.
Llegiu la situació abans de seleccionar res:
| 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 |
La família d'adreces també importa. Un proveïdor que només assigna IPv4 deixa la interfície enllaçada sense adreça IPv6, així que els parells IPv6 fallen en lloc de sortir per Wi-Fi. Per separat, enllaçar sockets no fixa la resolució de noms: els noms d'amfitrió dels trackers es resolen pel resolutor del macOS, que segueix la configuració DNS del sistema i no el dispositiu seleccionat.
Tres maneres com falla una selecció que sembla correcta
La primera fallada és no reiniciar. El camp mostra utun4, les preferències semblen configurades, i una transferència de prova encara surt per Wi-Fi perquè la sessió en curs conservava l'enllaç antic. Tanqueu del tot, confirmeu amb pgrep, torneu a obrir i comenceu la transferència de nou.
La segona és el nom obsolet després d'una reconnexió. Quan el dispositiu enllaçat desapareix, les connexions de pare fallen i el client sol informar d'errors de tracker en lloc d'un missatge clar que la interfície ha desaparegut, cosa que sembla un torrent mort. Torneu a llegir ifconfig, seleccioneu el nom nou i reinicieu.
La tercera és suposar que l'enllaç falla tancat. Seleccionar una interfície demana al sistema que adjunti sockets a un nom de dispositiu; què passa quan aquest nom falta o es recicla no ho garanteix la pantalla de paràmetres. La prova de desconnexió de la secció següent és l'única evidència que compta.
Verifiqueu amb una transferència real i una desconnexió
Feu servir una transferència que us estigui permesa, com una imatge de distribució Linux, i inicieu-la amb la VPN connectada. Mireu els comptadors per interfície abans i després i compareu-los amb el comptador de dades del client VPN; tots dos haurien de pujar junts mentre s'omple la llista de parells.
netstat -ib | grep utun
pgrep -fl qbittorrentDesprés desconnecteu la VPN des de la seva pròpia interfície i mireu la transferència. Els parells haurien de desaparèixer, i les connexions noves haurien de fallar poc després que caigui el túnel. Si el rendiment continua, l'enllaç no està actiu i torneu al pas de reiniciar, no al tallafoc.
Reconnecteu i comproveu el nom seleccionat una altra vegada, perquè el túnel pot tornar amb un utun diferent. Una nota curta amb el tipus de túnel, el nom de la interfície i el comportament esperat quan cau la VPN estalvia la sessió següent: aquest paràmetre és per màquina i per proveïdor, i no sobreviu ni a una actualització del client ni a un canvi d'aplicació VPN.