Paano i-bind ang qBittorrent sa isang VPN interface sa macOS

Binuksan ko ang qBittorrent sa isang Mac mini, itinakda ang Network Interface sa utun4, nag-restart, at pagkatapos ay nagpalipas ng isang hapon na pinapanood ang isang torrent na natigil sa pagkuha ng metadata habang ang VPN ay nagpapakita pa rin ng malusog na koneksyon. Hindi mali ang setting sa prinsipyo; ang pangalan ay luma na. Nagbibigay ang macOS ng mga numero ng utun kapag nagsisimula ang mga serbisyo, kaya ang utun4 na tama noong nakaraang linggo ay tumuturo sa isang tunnel na wala na, at ang client ay nagbibid ng mga socket nito sa isang device na walang ruta. Ang pagkakasunod-sunod sa ibaba ang ginagamit ko ngayon: basahin ang interface mula sa tumatakbong tunnel, piliin ito sa client, i-restart ang session, at pagkatapos ay patunayan ang bind gamit ang isang transfer at isang sadyang disconnect.

Buksan ang Advanced at hanapin ang field ng interface

Sa window ng qBittorrent, buksan ang Preferences gamit ang Cmd+, at pumunta sa pahinang Advanced. Ang Network Interface ang field na mahalaga: inililista nito ang mga pangalan ng interface ng system at default ay nasa Any Interface, ibig sabihin pinipili ng operating system ang ruta para sa bawat socket na binubuksan ng client. Ang reference ng mga opsyon ng proyekto ay nagdodokumento ng field na iyon at ng default na iyon, at ito ang parehong setting sa bawat platform kahit na ang mga pangalan sa loob nito ay hindi pareho.

Dalawang detalye ang nagpapadapa sa mga tao dito. Ipinapakita ng listahan ang mga pangalan ng device tulad ng en0, en1 at utun0 hanggang utun9, hindi kailanman ang pangalan ng produkto ng provider ng VPN, kaya kailangan mo ang pagtutugma bago makapili ng anumang makatuwiran. At ang pagpili ay inilalapat kapag nagsimula ang session ng BitTorrent, hindi sa sandaling pinindot mo ang OK, kaya ang pagbabagong mukhang nai-save ay maaaring tumatakbo pa rin sa lumang bind.

Isara ang application nang maayos gamit ang Cmd+Q at tiyakin na wala na ang proseso bago ito buksan muli. Ang pagsasara ng window ay nagtatago lang nito, at ang nakatagong client ay nagpapanatili ng session, port ng pakikinig at lumang interface.

pgrep -fl qbittorrent

Hanapin ang interface na talagang pagmamay-ari ng iyong VPN

Ikonekta muna ang VPN sa pamamagitan ng sariling client ng provider, pagkatapos ay basahin ang pananaw ng system sa halip na ang menu ng client. Inililista ng mga command sa ibaba ang bawat interface kasama ang mga address nito, ipinapakita kung alin ang itinuturing na aktibo ng system at ipinapasa ang routing table; hinahanap mo ang device na utun na nagdadala ng pribadong saklaw na ibinibigay ng iyong provider.

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

Tatlong pagbasa ang magsasabi sa iyo kung aling device ang tunnel. Ang entry na utun ay nangangailangan ng address na inet na kabilang sa pool ng VPN. Ipinapakita ng scutil --nwi kung aling mga interface ang itinuturing na aktibo ng system at alin ang pangunahin. Ipinapakita ng netstat -rn kung saan tumuturo ang default na ruta, at kung ang rutang iyon ay tumuturo pa rin sa en0 habang may address ang isang utun, hindi dinadala ng tunnel ang lahat ng trapiko, na nagbabago sa gagawin ng bind mamaya.

Kapag may dalawang tunnel nang sabay, halimbawa isang work profile at isang personal, naroroon ang dalawang device na utun at isa lang ang kapaki-pakinabang. Ang mga byte counter ang magpapasya sa tanong: itala ang mga counter, mag-load ng pahina o magsimula ng maliit na transfer at tingnan kung alin ang gumalaw.

netstat -ib | grep utun

Huwag ituring na matatag ang numero. Ang muling pagkonekta ay maaaring magbigay ng ibang pangalang utun sa parehong tunnel, at ang serbisyo ng iCloud o Continuity ay maaaring humawak ng utun0 nang matagal bago kumonekta ang iyong VPN.

Itugma ang bind sa saklaw ng tunnel

Ang field ay nagbibid ng isang device, at iyon lang ang ginagawa nito. Kung ang VPN ay isang buong tunnel na nagruruta ng 0.0.0.0/0 papasok sa utun, ang pag-bind sa device na iyon ay nagpapadala ng bawat koneksyon ng peer at bawat kahilingan ng tracker sa pamamagitan ng VPN. Kung ang VPN ay isang split tunnel na nagruruta lamang ng ilang subnet, ang pag-bind sa utun ay nagpapadala ng trapiko ng peer sa isang device na walang ruta para sa mga peer na iyon, at humihinto ang mga transfer sa halip na tumagas. Parehong mas ligtas ang dalawang resulta kaysa sa Any Interface, ngunit isa lang ang nagpapanatili sa client na gumagana. Walang nagbabago sa labas ng client: pinapanatili ng mga browser at iba pang app ang kanilang sariling ruta, kaya ang isang pangangailangan na sumasaklaw sa lahat ng application ay dapat ipatupad mula sa panig ng VPN.

Basahin ang sitwasyon bago pumili ng anuman:

Mahalaga rin ang pamilya ng address. Ang provider na nagbibigay lamang ng IPv4 ay nag-iiwan sa naka-bind na interface na walang address na IPv6, kaya nabibigo ang mga peer na IPv6 sa halip na dumulas palabas sa Wi-Fi. Hiwalay, ang pag-bind ng socket ay hindi nagpapako sa paglutas ng pangalan: ang mga hostname ng tracker ay nilulutas sa pamamagitan ng resolver ng macOS, na sumusunod sa configuration ng DNS ng system at hindi sa piniling device.

Tatlong paraan kung paano nabibigo ang isang pagpipiliang mukhang tama

Ang unang kabiguan ay ang hindi pag-restart. Ipinapakita ng field ang utun4, mukhang naka-configure ang mga preference, at ang test transfer ay lumalabas pa rin sa Wi-Fi dahil pinanatili ng tumatakbong session ang lumang bind. Isara nang lubusan, kumpirmahin gamit ang pgrep, buksan muli at simulan muli ang transfer.

Ang pangalawa ay ang lumang pangalan pagkatapos ng muling pagkonekta. Sa sandaling mawala ang naka-bind na device, nabibigo ang mga koneksyon ng peer at ang client ay may tendensiyang mag-ulat ng mga error ng tracker sa halip na isang malinaw na mensahe na wala na ang interface, na parang patay na torrent. Basahin muli ang ifconfig, piliin ang bagong pangalan at i-restart.

Ang pangatlo ay ang pag-aakala na nabibigo ang bind nang sarado. Ang pagpili ng interface ay humihiling sa system na ilakip ang mga socket sa isang pangalan ng device; kung ano ang mangyayari kapag wala ang pangalang iyon o ginagamit muli ay hindi ginagarantiyahan ng screen ng mga setting. Ang test ng pagdiskonekta sa susunod na seksyon ang tanging ebidensiyang binibilang.

I-verify gamit ang tunay na transfer at isang disconnect

Gumamit ng transfer na pinapayagan kang patakbuhin, tulad ng image ng distribusyon ng Linux, at simulan ito habang nakakonekta ang VPN. Panoorin ang mga counter kada interface bago at pagkatapos at ihambing sa counter ng data ng client ng VPN mismo; dapat tumaas ang dalawa nang magkasabay habang napupuno ang listahan ng peer.

netstat -ib | grep utun
pgrep -fl qbittorrent

Pagkatapos ay idiskonekta ang VPN mula sa sarili nitong interface at panoorin ang transfer. Dapat mawala ang mga peer, at dapat mabigo ang mga bagong koneksyon sa ilang sandali pagkatapos bumagsak ang tunnel. Kung nagpatuloy ang throughput, hindi umiiral ang bind at bumalik ka sa hakbang ng pag-restart, hindi sa firewall.

Kumonekta muli at suriin muli ang piniling pangalan, dahil maaaring bumalik ang tunnel sa ilalim ng ibang utun. Ang maikling tala na nagtatala ng uri ng tunnel, pangalan ng interface at inaasahang pag-uugali kapag bumagsak ang VPN ay nakakatipid sa susunod na session: ang setting na ito ay kada makina at kada provider, at hindi ito nakakaligtas sa pag-upgrade ng client o pagpalit ng app ng VPN.