Så binder du qBittorrent till ett VPN-gränssnitt på macOS

Jag öppnade qBittorrent på en Mac mini, satte Network Interface till utun4, startade om och tillbringade sedan en eftermiddag med att se en torrent fastna på att hämta metadata medan VPN:en fortfarande visade en frisk anslutning. Inställningen var inte fel i princip; namnet var inaktuellt. macOS delar ut utun-nummer när tjänster startar, så den utun4 som var korrekt veckan innan pekade på en tunnel som inte längre fanns, och klienten band sina sockets till en enhet utan rutt. Sekvensen nedan är den jag använder nu: läs gränssnittet från den körande tunneln, välj det i klienten, starta om sessionen och bevisa sedan bindningen med en överföring och en avsiktlig frånkoppling.

Öppna Avancerat och hitta gränssnittsfältet

I qBittorrent-fönstret öppnar du Inställningar med Cmd+, och går till sidan Avancerat. Network Interface är fältet som spelar roll: det listar systemets gränssnittsnamn och står som standard på Any Interface, vilket betyder att operativsystemet väljer en rutt för varje socket som klienten öppnar. Projektets översikt över alternativen dokumenterar fältet och den standarden, och det är samma inställning på alla plattformar även om namnen i den inte är lika.

Två detaljer får folk att snubbla här. Listan visar enhetsnamn som en0, en1 och utun0 till utun9, aldrig VPN-leverantörens produktnamn, så du behöver kopplingen innan du kan välja något vettigt. Och valet tillämpas när BitTorrent-sessionen startar, inte i stunden du trycker OK, så en ändring som ser sparad ut kan fortfarande köra på den gamla bindningen.

Avsluta programmet ordentligt med Cmd+Q och bekräfta att processen är borta innan du öppnar det igen. Att stänga fönstret döljer det bara, och en dold klient behåller sin session, sin lyssnande port och sitt gamla gränssnitt.

pgrep -fl qbittorrent

Hitta gränssnittet som din VPN faktiskt äger

Anslut VPN:en först via leverantörens egen klient och läs sedan systemets vy i stället för klientens meny. Kommandona nedan listar varje gränssnitt med sina adresser, visar vilka systemet anser vara aktiva och skriver ut routingtabellen; du letar efter utun-enheten som bär det privata intervallet som din leverantör delar ut.

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

Tre läsningar säger vilken enhet som är tunneln. utun-posten behöver en inet-adress som hör till VPN:ens pool. scutil --nwi visar vilka gränssnitt systemet anser vara aktiva och vilket som är primärt. netstat -rn visar vart standardrutten pekar, och om den rutten fortfarande pekar på en0 medan en utun har adress, bär tunneln inte all trafik, vilket ändrar vad bindningen gör senare.

När två tunnlar kan finnas samtidigt, till exempel en arbetsprofil och en personlig, finns båda utun-enheterna och bara en av dem är användbar. Byteräknarna avgör frågan: notera räknarna, ladda en sida eller starta en liten överföring och se vilken som rörde sig.

netstat -ib | grep utun

Betrakta inte numret som stabilt. En återanslutning kan ge samma tunnel ett annat utun-namn, och en iCloud- eller Continuity-tjänst kan hålla utun0 långt innan din VPN ansluter.

Anpassa bindningen till tunnelns omfattning

Fältet binder en enhet, och det är allt det gör. Om VPN:en är en full tunnel som dirigerar 0.0.0.0/0 in i utun, skickar bindning till den enheten varje peer-anslutning och varje tracker-förfrågan genom VPN:en. Om VPN:en är en delad tunnel som bara dirigerar några få subnät, skickar bindning till utun peer-trafiken till en enhet utan rutt för dessa peers, och överföringarna stannar i stället för att läcka. Båda utfallen är säkrare än Any Interface, men bara ett av dem håller klienten fungerande. Inget utanför klienten ändras: webbläsare och andra appar behåller sina egna rutter, så ett krav som täcker alla program måste genomdrivas från VPN-sidan.

Läs situationen innan du väljer något:

Adressfamiljen spelar också roll. En leverantör som bara tilldelar IPv4 lämnar det bundna gränssnittet utan IPv6-adress, så IPv6-peers misslyckas i stället för att slinka ut över Wi-Fi. Separat fäster bindning av sockets inte namnuppslagningen: tracker-värdnamn löses via macOS resolver, som följer systemets DNS-konfiguration och inte den valda enheten.

Tre sätt en korrekt utseende inställning misslyckas på

Det första felet är att inte starta om. Fältet visar utun4, inställningarna ser konfigurerade ut, och en testöverföring går ändå ut över Wi-Fi eftersom den körande sessionen behöll den gamla bindningen. Avsluta helt, bekräfta med pgrep, öppna igen och starta överföringen på nytt.

Det andra är det inaktuella namnet efter en återanslutning. Så snart den bundna enheten försvinner misslyckas peer-anslutningarna och klienten tenderar att rapportera tracker-fel i stället för ett tydligt meddelande om att gränssnittet är borta, vilket läses som en död torrent. Läs ifconfig igen, välj det nya namnet och starta om.

Det tredje är att anta att bindningen misslyckas stängt. Att välja ett gränssnitt ber systemet att fästa sockets vid ett enhetsnamn; vad som händer när namnet saknas eller återanvänds garanterar inte inställningsskärmen. Frånkopplingstestet i nästa avsnitt är det enda beviset som räknas.

Verifiera med en riktig överföring och en frånkoppling

Använd en överföring du får köra, till exempel en Linux-distributionsavbild, och starta den med VPN:en ansluten. Följ räknarna per gränssnitt före och efter och jämför dem med VPN-klientens egen dataräknare; båda bör stiga tillsammans medan peer-listan fylls.

netstat -ib | grep utun
pgrep -fl qbittorrent

Koppla sedan från VPN:en från sitt eget gränssnitt och följ överföringen. Peers bör försvinna, och nya anslutningar bör misslyckas kort efter att tunneln faller. Om genomströmningen fortsätter är bindningen inte i kraft och du är tillbaka vid omstartssteget, inte vid brandväggen.

Anslut igen och kontrollera det valda namnet en gång till, eftersom tunneln kan komma tillbaka under en annan utun. En kort anteckning med tunneltyp, gränssnittsnamn och förväntat beteende när VPN:en faller sparar nästa session: den här inställningen är per maskin och per leverantör, och den överlever varken en klientuppgradering eller ett byte av VPN-app.