Hoe om qBittorrent aan 'n VPN-koppelvlak op macOS te bind

Ek het qBittorrent op 'n Mac mini oopgemaak, Network Interface op utun4 gestel, herbegin en toe 'n middag daaraan spandeer om te kyk hoe 'n torrent by die haal van metadata vassteek terwyl die VPN steeds 'n gesonde verbinding gewys het. Die instelling was nie in beginsel verkeerd nie; die naam was verouderd. macOS ken utun-nommers toe wanneer dienste begin, so die utun4 wat die week tevore korrek was, het na 'n tonnel gewys wat nie meer bestaan het nie, en die kliënt het sy sockets aan 'n toestel sonder roete gebind. Die volgorde hieronder is wat ek nou gebruik: lees die koppelvlak van die lopende tonnel, kies dit in die kliënt, herbegin die sessie en bewys die binding dan met 'n oordrag en 'n doelbewuste ontkoppeling.

Maak Gevorderd oop en vind die koppelvlakveld

Maak die voorkeure in die qBittorrent-venster met Cmd+, oop en gaan na die Gevorderd-bladsy. Network Interface is die veld wat saak maak: dit lys die stelsel se koppelvlakname en staan by verstek op Any Interface, wat beteken die bedryfstelsel kies 'n roete vir elke socket wat die kliënt oopmaak. Die opsieverwysing van die projek dokumenteer die veld en daardie verstek, en dit is dieselfde instelling op elke platform, al is die name daarin nie dieselfde nie.

Twee besonderhede laat mense hier struikel. Die lys wys toestelname soos en0, en1 en utun0 tot utun9, nooit die produknaam van die VPN-verskaffer nie, so jy het die kartering nodig voordat jy iets sinvols kan kies. En die keuse word toegepas wanneer die BitTorrent-sessie begin, nie op die oomblik dat jy OK druk nie, so 'n verandering wat gestoor lyk, kan steeds op die ou binding loop.

Sluit die program behoorlik met Cmd+Q en bevestig dat die proses weg is voordat jy dit weer oopmaak. Om die venster te sluit versteek dit net, en 'n versteekte kliënt hou sy sessie, sy luisterpoort en sy ou koppelvlak.

pgrep -fl qbittorrent

Vind die koppelvlak wat jou VPN werklik besit

Verbind eers die VPN, deur die verskaffer se eie kliënt, en lees dan die stelsel se siening eerder as die kliënt se kieslys. Die opdragte hieronder lys elke koppelvlak met sy adresse, wys watter die stelsel as aktief beskou en druk die roetetabel; jy soek die utun-toestel wat die privaat reeks dra wat jou verskaffer uitdeel.

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

Drie lesings sê vir jou watter toestel die tonnel is. Die utun-inskrywing het 'n inet-adres nodig wat aan die VPN se poel behoort. scutil --nwi wys watter koppelvlakke die stelsel as aktief beskou en watter een primêr is. netstat -rn wys waar die verstekroete wys, en as daardie roete steeds op en0 wys terwyl 'n utun 'n adres het, dra die tonnel nie alle verkeer nie, wat verander wat die binding later sal doen.

Wanneer twee tonnels gelyktydig kan bestaan, byvoorbeeld 'n werkprofiel en 'n persoonlike een, is albei utun-toestelle teenwoordig en is net een van hulle nuttig. Greptellers beslis die vraag: noteer die tellers, laai 'n bladsy of begin 'n klein oordrag en kyk watter een het beweeg.

netstat -ib | grep utun

Moenie die nommer as stabiel beskou nie. 'n Herverbinding kan dieselfde tonnel 'n ander utun-naam gee, en 'n iCloud- of Continuity-diens kan utun0 lank voor jou VPN verbind, beset.

Pas die binding by die tonnel se omvang aan

Die veld bind 'n toestel, en dit is al wat dit doen. As die VPN 'n vol tonnel is wat 0.0.0.0/0 in die utun inroeteer, stuur binding aan daardie toestel elke peer-verbinding en tracker-versoek deur die VPN. As die VPN 'n gesplete tonnel is wat net 'n paar subnetwerke roeteer, stuur binding aan die utun peer-verkeer na 'n toestel sonder 'n roete vir daardie peers, en oordragte stop in plaas daarvan om te lek. Albei uitkomste is veiliger as Any Interface, maar net een van hulle hou die kliënt aan die werk. Niks buite die kliënt verander nie: blaaiers en ander programme hou hul eie roetes, so 'n vereiste vir elke toepassing moet van die VPN-kant af afgedwing word.

Lees die situasie voordat jy enigiets kies:

Adresfamilie maak ook saak. 'n Verskaffer wat net IPv4 toeken, laat die gebinde koppelvlak sonder 'n IPv6-adres, so IPv6-peers misluk eerder as om oor Wi-Fi uit te glip. Afsonderlik daarvan pen die bind van sockets nie naamresolusie vas nie: tracker-gasheername word deur die macOS-oplosser opgelos, wat die stelsel se DNS-opstelling volg eerder as die gekose toestel.

Drie maniere waarop 'n korrek-lykende keuse misluk

Die eerste fout is om nie te herbegin nie. Die veld wys utun4, die voorkeure lyk opgestel, en 'n toets-oordrag verlaat steeds oor Wi-Fi omdat die lopende sessie die ou binding behou het. Sluit heeltemal, bevestig met pgrep, maak weer oop en begin die oordrag weer.

Die tweede is die verouderde naam ná 'n herverbinding. Sodra die gebinde toestel verdwyn, misluk peer-verbindings en die kliënt rapporteer eerder tracker-foute as 'n skoon boodskap dat die koppelvlak weg is, wat soos 'n dooie torrent lees. Lees ifconfig weer, kies die nuwe naam en herbegin.

Die derde is om aan te neem die binding misluk geslote. Om 'n koppelvlak te kies vra die stelsel om sockets aan 'n toestelnaam te heg; wat gebeur wanneer daardie naam ontbreek of herwin word, waarborg die instellingsskerm nie. Die ontkoppelingstoets in die volgende afdeling is die enigste bewys wat tel.

Verifieer met 'n werklike oordrag en 'n ontkoppeling

Gebruik 'n oordrag wat jy mag uitvoer, soos 'n Linux-verspreidingsbeeld, en begin dit met die VPN verbind. Kyk na die tellers per koppelvlak voor en ná, en vergelyk hulle met die VPN-kliënt se eie datateller; albei behoort saam te styg terwyl die peer-lys vul.

netstat -ib | grep utun
pgrep -fl qbittorrent

Ontkoppel dan die VPN van sy eie koppelvlak en kyk na die oordrag. Peers behoort weg te val, en nuwe verbindings behoort kort ná die tonnel se afval te misluk. As die deurset aanhou, is die binding nie in werking nie en is jy terug by die herbegin-stap, nie by die firewall nie.

Verbind weer en kyk weer na die gekose naam, want die tonnel kan onder 'n ander utun terugkom. 'n Kort nota met die tonneltipe, die koppelvlaknaam en die verwagte gedrag wanneer die VPN val, spaar die volgende sessie: hierdie instelling is per masjien en per verskaffer, en dit oorleef nóg 'n kliënt-opgradering nóg 'n verandering van VPN-program.