Kako vezati qBittorrent za VPN sučelje na macOS-u

Otvorio sam qBittorrent na Mac miniju, postavio Network Interface na utun4, ponovno pokrenuo i zatim proveo poslijepodne gledajući kako torrent stoji na dohvaćanju metapodataka dok je VPN i dalje pokazivao zdravu vezu. Postavka u načelu nije bila pogrešna; naziv je bio zastario. macOS dodjeljuje utun brojeve kada se servisi pokreću, pa je utun4 koji je bio ispravan tjedan prije pokazivao na tunel koji više nije postojao, a klijent je vezao svoje sockete za uređaj bez rute. Slijed u nastavku je ono što sada koristim: pročitajte sučelje s aktivnog tunela, odaberite ga u klijentu, ponovno pokrenite sesiju i zatim dokažite vezu prijenosom i namjernim prekidom.

Otvorite Advanced i pronađite polje sučelja

U prozoru qBittorrenta otvorite Preferences s Cmd+, i prijeđite na stranicu Advanced. Network Interface je polje koje je važno: navodi nazive sučelja u sustavu i prema zadanim postavkama stoji na Any Interface, što znači da operacijski sustav bira rutu za svaki socket koji klijent otvori. pregled opcija projekta dokumentira to polje i taj zadani izbor, i to je ista postavka na svakoj platformi iako nazivi unutar nje nisu isti.

Dva detalja ovdje zbunjuju ljude. Popis prikazuje nazive uređaja poput en0, en1 i utun0 do utun9, nikada naziv proizvoda VPN pružatelja, pa vam je potrebno mapiranje prije nego što odaberete nešto razumno. I odabir se primjenjuje kada BitTorrent sesija započne, a ne u trenutku kada pritisnete OK, pa promjena koja izgleda spremljena može i dalje raditi na staroj vezi.

Zatvorite aplikaciju ispravno s Cmd+Q i potvrdite da je proces nestao prije nego što je ponovno otvorite. Zatvaranje prozora samo ga skriva, a skriveni klijent zadržava svoju sesiju, svoj port za slušanje i svoje staro sučelje.

pgrep -fl qbittorrent

Pronađite sučelje koje vaš VPN doista posjeduje

Prvo povežite VPN preko pružateljevog vlastitog klijenta, a zatim čitajte pogled sustava umjesto izbornika klijenta. Naredbe u nastavku navode svako sučelje s njegovim adresama, pokazuju koja sustav smatra aktivnima i ispisuju tablicu ruta; tražite utun uređaj koji nosi privatni raspon koji vam pružatelj dodjeljuje.

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

Tri čitanja govore vam koji je uređaj tunel. utun zapis treba inet adresu koja pripada VPN-ovom poolu. scutil --nwi pokazuje koja sučelja sustav smatra aktivnima i koje je primarno. netstat -rn pokazuje kamo pokazuje zadana ruta, a ako ta ruta i dalje pokazuje na en0 dok utun ima adresu, tunel ne nosi sav promet, što mijenja ono što će veza kasnije raditi.

Kada dva tunela mogu postojati istovremeno, na primjer radni profil i osobni, oba utun uređaja su prisutna i samo je jedan od njih koristan. Brojači bajtova rješavaju pitanje: zabilježite brojače, učitajte stranicu ili pokrenite mali prijenos i vidite koji se pomaknuo.

netstat -ib | grep utun

Ne smatrajte broj stabilnim. Ponovno povezivanje može istom tunelu dati drugačiji utun naziv, a iCloud ili Continuity servis može držati utun0 mnogo prije nego što se vaš VPN poveže.

Uskladite vezu s opsegom tunela

Polje veže uređaj i to je sve što radi. Ako je VPN puni tunel koji rutira 0.0.0.0/0 u utun, vezivanje za taj uređaj šalje svaku peer vezu i svaki tracker zahtjev kroz VPN. Ako je VPN podijeljeni tunel koji rutira samo nekoliko podmreža, vezivanje za utun šalje peer promet na uređaj bez rute za te peere, i prijenosi se zaustavljaju umjesto da cure. Oba ishoda sigurnija su od Any Interface, ali samo jedan od njih održava klijent funkcionalnim. Ništa izvan klijenta se ne mijenja: preglednici i druge aplikacije zadržavaju svoje rute, pa zahtjev koji pokriva svaku aplikaciju mora biti nametnut s VPN strane.

Pročitajte situaciju prije nego što bilo što odaberete:

Adresna obitelj je također važna. Pružatelj koji dodjeljuje samo IPv4 ostavlja vezano sučelje bez IPv6 adrese, pa IPv6 peerovi ne uspijevaju umjesto da se izvuku preko Wi-Fi-ja. Odvojeno, vezivanje socketa ne fiksira razrješavanje naziva: nazivi tracker hostova razrješavaju se kroz macOS resolver, koji slijedi DNS konfiguraciju sustava, a ne odabrani uređaj.

Tri načina na koja ispravan izbor naizgled ne uspijeva

Prvi neuspjeh je neponovno pokretanje. Polje pokazuje utun4, postavke izgledaju konfigurirano, a testni prijenos i dalje izlazi preko Wi-Fi-ja jer je aktivna sesija zadržala staru vezu. Zatvorite potpuno, potvrdite s pgrep, otvorite ponovno i ponovno pokrenite prijenos.

Drugi je zastario naziv nakon ponovnog povezivanja. Kada vezani uređaj nestane, peer veze ne uspijevaju i klijent obično prijavljuje tracker greške umjesto čiste poruke da je sučelje otišlo, što izgleda kao mrtav torrent. Ponovno pročitajte ifconfig, odaberite novi naziv i ponovno pokrenite.

Treći je pretpostavka da veza ne uspijeva zatvoreno. Odabir sučelja traži od sustava da prikači sockete na naziv uređaja; što se događa kada taj naziv nedostaje ili se reciklira, ekran postavki ne garantira. Test prekida u sljedećem odjeljku jedini je dokaz koji se računa.

Provjerite stvarnim prijenosom i prekidom

Koristite prijenos koji vam je dopušteno pokrenuti, poput slike Linux distribucije, i pokrenite ga s povezanim VPN-om. Gledajte brojače po sučelju prije i poslije i usporedite ih s vlastitim brojačem podataka VPN klijenta; oba bi trebala rasti zajedno dok se popis peerova puni.

netstat -ib | grep utun
pgrep -fl qbittorrent

Zatim isključite VPN s njegovog vlastitog sučelja i gledajte prijenos. Peerovi bi trebali nestati, a nove veze bi trebale ne uspjeti ubrzo nakon što tunel padne. Ako propusnost traje, veza nije na snazi i vraćate se na korak ponovnog pokretanja, a ne na vatrozid.

Ponovno se povežite i provjerite odabrani naziv, jer tunel može doći pod drugim utun-om. Kratka bilješka s tipom tunela, nazivom sučelja i očekivanim ponašanjem kada VPN padne štedi sljedeću sesiju: ova postavka je po računalu i po pružatelju, i ne preživljava ni nadogradnju klijenta ni promjenu VPN aplikacije.