Kiel ligi qBittorrent al VPN-interfaco sur macOS

Mi malfermis qBittorrent sur Mac mini, agordis Network Interface al utun4, restartigis, kaj poste pasigis posttagmezon rigardante torrenteon halti ĉe akiro de metadatenoj dum la VPN ankoraŭ montris sanan konekton. La agordo ne estis malĝusta principe; la nomo estis kaduka. macOS donas utun-numerojn kiam servoj ekfunkcias, do la utun4, kiu estis ĝusta la antaŭan semajnon, montris al tunelo, kiu ne plu ekzistis, kaj la kliento ligis siajn poŝojn al aparato sen itinero. La sekva sinsekvo estas tio, kion mi uzas nun: legi la interfacon el la kuranta tunelo, elekti ĝin en la kliento, restartigi la seancon kaj poste pruvi la ligon per transfero kaj intenca malkonekto.

Malfermu Advanced kaj trovu la interfacan kampon

En la fenestro de qBittorrent, malfermu Preferences per Cmd+, kaj iru al la paĝo Advanced. Network Interface estas la kampo, kiu gravas: ĝi listigas la interfacajn nomojn de la sistemo kaj defaŭlte staras ĉe Any Interface, kio signifas, ke la operaciumo elektas itinero por ĉiu poŝo, kiun la kliento malfermas. La referenco pri opcioj de la projekto dokumentas la kampon kaj tiun defaŭlton, kaj ĝi estas la sama agordo sur ĉiu platformo, kvankam la nomoj ene de ĝi ne samas.

Du detaloj faligas homojn ĉi tie. La listo montras aparatajn nomojn kiel en0, en1 kaj utun0 ĝis utun9, neniam la produktonomon de la VPN-provizanto, do vi bezonas la mapadon antaŭ ol vi povas elekti ion prudentan. Kaj la elekto aplikiĝas kiam la BitTorrent-seanco komenciĝas, ne en la momento, kiam vi premas OK, do ŝanĝo, kiu ŝajnas konservita, eble ankoraŭ funkcias sur la malnova ligo.

Fermu la programon ĝuste per Cmd+Q kaj konfirmu, ke la procezo malaperis antaŭ ol remalfermi ĝin. Fermi la fenestron nur kaŝas ĝin, kaj kaŝita kliento konservas sian seancon, sian aŭskultan pordon kaj sian malnovan interfacon.

pgrep -fl qbittorrent

Trovu la interfacon, kiun via VPN vere posedas

Unue konektu la VPN per la propra kliento de la provizanto, kaj poste legu la vidpunkton de la sistemo anstataŭ la menuon de la kliento. La subaj komandoj listigas ĉiun interfacon kun ĝiaj adresoj, montras, kiujn la sistemo konsideras aktivaj, kaj presas la itineran tabelon; vi serĉas la utun-aparaton, kiu portas la privatan gamon, kiun via provizanto donas.

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

Tri legadoj diras al vi, kiu aparato estas la tunelo. La utun-enskribo bezonas inet-adreson, kiu apartenas al la naĝejo de la VPN. scutil --nwi montras, kiujn interfacojn la sistemo konsideras aktivaj kaj kiu estas ĉefa. netstat -rn montras, kien direktiĝas la defaŭlta itinero, kaj se tiu itinero ankoraŭ direktiĝas al en0 dum utun havas adreson, la tunelo ne portas la tutan trafikon, kio ŝanĝas, kion la ligo faros poste.

Kiam du tuneloj povas ekzisti samtempe, ekzemple labora profilo kaj persona, ambaŭ utun-aparatoj ĉeestas kaj nur unu el ili utilas. Bajtaj nombriloj solvas la demandon: notu la nombrilojn, ŝarĝu paĝon aŭ komencu malgrandan transferon kaj vidu, kiu moviĝis.

netstat -ib | grep utun

Ne traktu la numeron kiel stabilan. Rekonekto povas doni al la sama tunelo alian utun-nomon, kaj iCloud aŭ Continuity-servo povas okupi utun0 longe antaŭ ol via VPN konektiĝas.

Adaptu la ligon al la amplekso de la tunelo

La kampo ligas aparaton, kaj tion ĝi nur faras. Se la VPN estas plena tunelo, kiu itineras 0.0.0.0/0 en la utun, ligo al tiu aparato sendas ĉiun peer-konekton kaj ĉiun tracker-peton tra la VPN. Se la VPN estas dividita tunelo, kiu itineras nur kelkajn subretojn, ligo al la utun sendas peer-trafikon al aparato sen itinero por tiuj peer, kaj transferoj haltas anstataŭ liki. Ambaŭ rezultoj pli sekuras ol Any Interface, sed nur unu el ili tenas la klienton funkcianta. Nenio ekster la kliento ŝanĝiĝas: retumiloj kaj aliaj programoj konservas siajn proprajn itinerojn, do postulo kovranta ĉiun programon bezonas plenumadon de la VPN-flanko.

Legu la situacion antaŭ ol elekti ion:

Ankaŭ la adresa familio gravas. Provizanto, kiu donas nur IPv4, lasas la ligitan interfacon sen IPv6-adreso, do IPv6-peer malsukcesas anstataŭ gliti eksteren tra Wi-Fi. Aparte, ligi poŝojn ne fiksas nomrezolucion: tracker-gastigantaj nomoj rezolviĝas per la macOS-rezolvilo, kiu sekvas la DNS-agordon de la sistemo, ne la elektitan aparaton.

Tri manieroj, kiel ŝajne ĝusta elekto malsukcesas

La unua malsukceso estas ne restartigi. La kampo montras utun4, la preferoj aspektas agorditaj, kaj testa transfero ankoraŭ eliras tra Wi-Fi ĉar la kuranta seanco tenis la malnovan ligon. Fermu plene, konfirmu per pgrep, remalfermu kaj komencu la transferon denove.

La dua estas la kaduka nomo post rekonekto. Kiam la ligita aparato malaperas, peer-konektoj malsukcesas kaj la kliento emas raporti tracker-erarojn anstataŭ puran mesaĝon, ke la interfaco foriris, kio aspektas kiel morta torrenteo. Rellegu ifconfig, elektu la novan nomon kaj restartigu.

La tria estas supozi, ke la ligo malsukcesas fermite. Elekti interfacon petas al la sistemo alkroĉi poŝojn al aparata nomo; kio okazas, kiam tiu nomo mankas aŭ estas recikligita, la agorda ekrano ne garantias. La malkonekta testo en la sekva sekcio estas la sola pruvo, kiu valoras.

Kontrolu per reala transfero kaj malkonekto

Uzu transferon, kiun vi rajtas lanĉi, ekzemple Linux-distribuan bildon, kaj lanĉu ĝin kun la VPN konektita. Rigardu la nombrilojn po interfaco antaŭe kaj poste kaj komparu ilin kun la propra datuma nombrilo de la VPN-kliento; ambaŭ devus altiĝi kune dum la peer-listo pleniĝas.

netstat -ib | grep utun
pgrep -fl qbittorrent

Poste malkonektu la VPN de sia propra interfaco kaj rigardu la transferon. Peer devus foriri, kaj novaj konektoj devus malsukcesi baldaŭ post kiam la tunelo falas. Se la trafluo daŭras, la ligo ne validas kaj vi estas denove ĉe la restartiga paŝo, ne ĉe la fajroŝirmilo.

Rekonektu kaj kontrolu la elektitan nomon denove, ĉar la tunelo povas reveni sub alia utun. Mallonga noto kun la tunela tipo, la interfaca nomo kaj la atendata konduto kiam la VPN falas ŝparas la sekvan seancon: ĉi tiu agordo estas po maŝino kaj po provizanto, kaj ĝi postvivas nek klientan ĝisdatigon nek ŝanĝon de VPN-programo.