Slik bind du qBittorrent til eit VPN-grensesnitt på macOS

Eg opna qBittorrent på ein Mac mini, sette Network Interface til utun4, starta på nytt og brukte deretter ein ettermiddag på å sjå ein torrent stå på henting av metadata medan VPN-en framleis viste ei sunn tilkopling. Innstillinga var ikkje feil i prinsippet; namnet var utdatert. macOS deler ut utun-nummer når tenester startar, så utun4 som hadde vore rett veka før peika på ein tunnel som ikkje fanst lenger, og klienten batt sokkane sine til ein eining utan rute. Rekkjefølgja nedanfor er den eg brukar no: les grensesnittet frå den køyrande tunnelen, vel det i klienten, start økta på nytt og prov deretter bindinga med ei overføring og ei medviten fråkopling.

Opne Avansert og finn grensesnittfeltet

I qBittorrent-vindauget opnar du Innstillingar med Cmd+, og går til sida Avansert. Network Interface er feltet som tel: det listar opp grensesnittnamna til systemet og står som standard på Any Interface, som tyder at operativsystemet vel ei rute for kvar sokkel klienten opnar. Prosjektet sin oversikt over vala dokumenterer feltet og den standarden, og det er same innstillinga på alle plattformer sjølv om namna i henne ikkje er like.

To detaljar får folk til å snuble her. Lista viser einingnamn som en0, en1 og utun0 til utun9, aldri produktnamnet til VPN-leverandøren, så du treng koplinga før du kan velje noko fornuftig. Og valet blir brukt når BitTorrent-økta startar, ikkje i augneblinken du trykkjer OK, så ei endring som ser lagra ut kan framleis køyre på den gamle bindinga.

Avslutt programmet ordentleg med Cmd+Q og stadfest at prosessen er borte før du opnar det igjen. Å lukke vindauget berre skjuler det, og ein skjult klient held på økta, lyttinga på porten og det gamle grensesnittet.

pgrep -fl qbittorrent

Finn grensesnittet som VPN-en din faktisk eig

Kople til VPN-en først, via leverandøren sin eigen klient, og les deretter visinga til systemet i staden for menyen til klienten. Kommandoane nedanfor listar kvart grensesnitt med adressene sine, viser kva systemet reknar som aktive og skriv ut rutetabellen; du leitar etter utun-eininga som ber det private området leverandøren din deler ut.

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

Tre lesingar fortel deg kva eining som er tunnelen. utun-oppføringa treng ei inet-adresse som høyrer til bassenget til VPN-en. scutil --nwi viser kva grensesnitt systemet reknar som aktive og kva som er primært. netstat -rn viser kvar standardruta peikar, og om den ruta framleis peikar på en0 medan ein utun har adresse, ber ikkje tunnelen all trafikk, noko som endrar kva bindinga gjer seinare.

Når to tunnelar kan finnast samtidig, til dømes ein jobbprofil og ein personleg, er begge utun-einingane til stades, og berre éin av dei er nyttig. Bytteteljarar avgjer spørsmålet: noter teljarane, last ei side eller start ei lita overføring og sjå kva som flytta seg.

netstat -ib | grep utun

Ikkje rekn nummeret som stabilt. Ei ny tilkopling kan gje same tunnel eit anna utun-namn, og ein iCloud- eller Continuity-teneste kan halde utun0 lenge før VPN-en din koplar til.

Tilpass bindinga til omfanget av tunnelen

Feltet bind ei eining, og det er alt det gjer. Om VPN-en er ein full tunnel som ruter 0.0.0.0/0 inn i utun, sender binding til den eininga kvar peer-tilkopling og kvar tracker-førespurnad gjennom VPN-en. Om VPN-en er ein delt tunnel som berre ruter nokre få subnett, sender binding til utun peer-trafikken til ei eining utan rute for desse peerane, og overføringane stoppar i staden for å leke. Begge utfalla er tryggare enn Any Interface, men berre eitt av dei held klienten i arbeid. Ingenting utanfor klienten blir endra: nettlesarar og andre apper held på sine eigne ruter, så eit krav som dekkjer alle program må handhevast frå VPN-sida.

Les situasjonen før du vel noko:

Adressefamilien har også noko å seie. Ein leverandør som berre tildeler IPv4, lèt det bundne grensesnittet stå utan IPv6-adresse, så IPv6-peers feilar i staden for å smette ut over Wi-Fi. Separat festar ikkje binding av sokklar namneoppslaget: tracker-vertsnamn blir løyste gjennom resolveren til macOS, som følgjer DNS-konfigurasjonen til systemet og ikkje den valde eininga.

Tre måtar ei rett utsjanande innstilling feilar på

Den første feilen er å ikkje starte på nytt. Feltet viser utun4, innstillingane ser konfigurerte ut, og ei testoverføring går likevel over Wi-Fi fordi den køyrande økta heldt på den gamle bindinga. Avslutt heilt, stadfest med pgrep, opne igjen og start overføringa på nytt.

Den andre er det utdaterte namnet etter ei ny tilkopling. Så snart den bundne eininga forsvinn, feilar peer-tilkoplingar, og klienten rapporterer heller tracker-feil enn ei rein melding om at grensesnittet er borte, noko som les som ein daud torrent. Les ifconfig på nytt, vel det nye namnet og start på nytt.

Den tredje er å anta at bindinga feilar lukka. Å velje eit grensesnitt ber systemet om å feste sokklar til eit einingnamn; kva som skjer når namnet manglar eller blir gjenbrukt, garanterer ikkje innstillingsskjermen. Fråkoplingstesten i neste avsnitt er det einaste provet som tel.

Prov med ei ekte overføring og ei fråkopling

Bruk ei overføring du har lov til å køyre, som eit Linux-distribusjonsbilete, og start ho med VPN-en tilkopla. Følg teljarane per grensesnitt før og etter, og samanlikn dei med eigen datateljar for VPN-klienten; begge bør stige saman medan peer-lista blir fylt.

netstat -ib | grep utun
pgrep -fl qbittorrent

Kople deretter frå VPN-en frå sitt eige grensesnitt og følg overføringa. Peers bør falle bort, og nye tilkoplingar bør feile kort tid etter at tunnelen går ned. Om gjennomstrøyminga held fram, er ikkje bindinga i kraft, og du er tilbake ved omstartstrinnet, ikkje ved brannmuren.

Kople til igjen og sjekk det valde namnet på nytt, for tunnelen kan kome tilbake under ein annan utun. Eit kort notat med tunneltypen, grensesnittnamnet og forventa åtferd når VPN-en fell, sparer neste økt: denne innstillinga er per maskin og per leverandør, og ho overlever verken ein klientoppgradering eller eit byte av VPN-app.