Slik binder du qBittorrent til et VPN-grensesnitt på macOS

Jeg åpnet qBittorrent på en Mac mini, satte Network Interface til utun4, startet på nytt og brukte deretter en ettermiddag på å se en torrent stå på henting av metadata mens VPN-en fortsatt viste en sunn tilkobling. Innstillingen var ikke feil i prinsippet; navnet var utdatert. macOS tildeler utun-numre når tjenester starter, så utun4 som hadde vært riktig uken før pekte på en tunnel som ikke lenger fantes, og klienten bandt socketene sine til en enhet uten rute. Rekkefølgen nedenfor er den jeg bruker nå: les grensesnittet fra den kjørende tunnelen, velg det i klienten, start økten på nytt og bevis deretter bindingen med en overføring og en bevisst frakobling.

Åpne Avansert og finn grensesnittfeltet

I qBittorrent-vinduet åpner du Innstillinger med Cmd+, og går til siden Avansert. Network Interface er feltet som betyr noe: det lister opp systemets grensesnittnavn og står som standard på Any Interface, som betyr at operativsystemet velger en rute for hver socket klienten åpner. Prosjektets oversikt over valgene dokumenterer feltet og den standarden, og det er samme innstilling på alle plattformer selv om navnene i den ikke er like.

To detaljer får folk til å snuble her. Listen viser enhetsnavn som en0, en1 og utun0 til utun9, aldri produktnavnet til VPN-leverandøren, så du trenger koblingen før du kan velge noe fornuftig. Og valget brukes når BitTorrent-økten starter, ikke i det øyeblikket du trykker OK, så en endring som ser lagret ut kan fortsatt kjøre på den gamle bindingen.

Avslutt programmet ordentlig med Cmd+Q og bekreft at prosessen er borte før du åpner det igjen. Å lukke vinduet skjuler det bare, og en skjult klient beholder økten, lyttingen på porten og det gamle grensesnittet.

pgrep -fl qbittorrent

Finn grensesnittet som VPN-en din faktisk eier

Koble til VPN-en først, via leverandørens egen klient, og les deretter systemets visning i stedet for klientens meny. Kommandoene nedenfor lister hvert grensesnitt med adressene sine, viser hvilke systemet anser som aktive og skriver ut rutetabellen; du ser etter utun-enheten som bærer det private området leverandøren din deler ut.

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

Tre lesninger forteller deg hvilken enhet som er tunnelen. utun-oppføringen trenger en inet-adresse som hører til VPN-ens basseng. scutil --nwi viser hvilke grensesnitt systemet anser som aktive og hvilket som er primært. netstat -rn viser hvor standardruten peker, og hvis den ruten fortsatt peker på en0 mens en utun har adresse, bærer ikke tunnelen all trafikk, noe som endrer hva bindingen gjør senere.

Når to tunneler kan finnes samtidig, for eksempel en jobbprofil og en personlig, er begge utun-enhetene til stede, og bare én av dem er nyttig. Byttetellere avgjør spørsmålet: noter tellerne, last en side eller start en liten overføring og se hvilken som flyttet seg.

netstat -ib | grep utun

Ikke regn nummeret som stabilt. En ny tilkobling kan gi samme tunnel et annet utun-navn, og en iCloud- eller Continuity-tjeneste kan holde utun0 lenge før VPN-en din kobler til.

Tilpass bindingen til tunnelens omfang

Feltet binder en enhet, og det er alt det gjør. Hvis VPN-en er en full tunnel som ruter 0.0.0.0/0 inn i utun, sender binding til den enheten hver peer-tilkobling og hver tracker-forespørsel gjennom VPN-en. Hvis VPN-en er en delt tunnel som bare ruter noen få subnett, sender binding til utun peer-trafikken til en enhet uten rute for disse peerne, og overføringene stopper i stedet for å lekke. Begge utfallene er sikrere enn Any Interface, men bare ett av dem holder klienten i arbeid. Ingenting utenfor klienten endres: nettlesere og andre apper beholder sine egne ruter, så et krav som dekker alle programmer må håndheves fra VPN-siden.

Les situasjonen før du velger noe:

Adressefamilien betyr også noe. En leverandør som bare tildeler IPv4, lar det bundne grensesnittet stå uten IPv6-adresse, så IPv6-peers feiler i stedet for å smette ut over Wi-Fi. Separat fester ikke binding av sockets navneoppslaget: tracker-vertsnavn løses gjennom macOS' resolver, som følger systemets DNS-konfigurasjon og ikke den valgte enheten.

Tre måter en riktig utseende innstilling feiler på

Den første feilen er å ikke starte på nytt. Feltet viser utun4, innstillingene ser konfigurert ut, og en testoverføring går likevel over Wi-Fi fordi den kjørende økten beholdt den gamle bindingen. Avslutt helt, bekreft med pgrep, åpne igjen og start overføringen på nytt.

Den andre er det utdaterte navnet etter en ny tilkobling. Så snart den bundne enheten forsvinner, feiler peer-tilkoblinger, og klienten rapporterer heller tracker-feil enn en ren melding om at grensesnittet er borte, noe som leses som en død torrent. Les ifconfig på nytt, velg det nye navnet og start på nytt.

Den tredje er å anta at bindingen feiler lukket. Å velge et grensesnitt ber systemet om å feste sockets til et enhetsnavn; hva som skjer når navnet mangler eller gjenbrukes, garanterer ikke innstillingsskjermen. Frakoblingstesten i neste avsnitt er det eneste beviset som teller.

Verifiser med en ekte overføring og en frakobling

Bruk en overføring du har lov til å kjøre, som et Linux-distribusjonsbilde, og start den med VPN-en tilkoblet. Følg tellerne per grensesnitt før og etter, og sammenlign dem med VPN-klientens egen datateller; begge bør stige sammen mens peer-listen fylles.

netstat -ib | grep utun
pgrep -fl qbittorrent

Koble deretter fra VPN-en fra sitt eget grensesnitt og følg overføringen. Peers bør falle bort, og nye tilkoblinger bør feile kort tid etter at tunnelen går ned. Hvis gjennomstrømningen fortsetter, er ikke bindingen i kraft, og du er tilbake ved omstartstrinnet, ikke ved brannmuren.

Koble til igjen og sjekk det valgte navnet på nytt, for tunnelen kan komme tilbake under en annen utun. Et kort notat med tunneltypen, grensesnittnavnet og forventet oppførsel når VPN-en faller, sparer neste økt: denne innstillingen er per maskin og per leverandør, og den overlever verken en klientoppgradering eller et bytte av VPN-app.