Kako povezati qBittorrent s VPN sučeljem na macOS-u

Pokrenuo sam qBittorrent na Mac miniju, postavio Network Interface na utun4, ponovno ga pokrenuo i zatim proveo poslijepodne promatrajući kako torrent zastaje na dohvaćanju metapodataka dok je VPN i dalje pokazivao ispravnu vezu. Postavka načelno nije bila pogrešna; naziv je bio zastario. macOS dodjeljuje utun brojeve pri pokretanju servisa, pa je utun4 koji je prošlog tjedna bio točan pokazivao na tunel koji više ne postoji, a klijent je svoje sockete vezao uz uređaj bez rute. Redoslijed u nastavku je onaj koji sada koristim: pročitajte sučelje iz aktivnog tunela, odaberite ga u klijentu, ponovno pokrenite sesiju i zatim dokažite povezanost prijenosom i namjernim prekidom.

Otvorite Advanced i pronađite polje sučelja

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

Dvije pojedinosti 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 pridruživanje prije nego što odaberete nešto smisleno. I odabir se primjenjuje pri pokretanju BitTorrent sesije, a ne u trenutku kada pritisnete OK, pa promjena koja izgleda spremljena može još uvijek raditi na staroj povezanosti.

Zatvorite aplikaciju ispravno pomoću 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, port za slušanje i staro sučelje.

pgrep -fl qbittorrent

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

Najprije povežite VPN preko pružateljeva vlastitog klijenta, a zatim čitajte pogled sustava umjesto klijentova izbornika. 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-ovu skupu adresa. scutil --nwi pokazuje koja sučelja sustav smatra aktivnima i koje je primarno. netstat -rn pokazuje kamo pokazuje zadana ruta, a ako ta ruta još pokazuje na en0 dok utun ima adresu, tunel ne nosi sav promet, što mijenja ono što će povezanost kasnije raditi.

Kada dva tunela mogu postojati istodobno, primjerice radni i osobni profil, 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 pogledajte koji se pomaknuo.

netstat -ib | grep utun

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

Uskladite povezanost s opsegom tunela

Polje veže uređaj i to je sve što čini. Ako je VPN puni tunel koji usmjerava 0.0.0.0/0 u utun, vezanje uz taj uređaj šalje svaku peer vezu i svaki tracker zahtjev kroz VPN. Ako je VPN podijeljeni tunel koji usmjerava samo nekoliko podmreža, vezanje uz utun šalje peer promet na uređaj bez rute za te peere, i prijenosi se zaustavljaju umjesto da cure. Oba su ishoda sigurnija od Any Interface, ali samo jedan od njih održava klijent radnim. 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 išta odaberete:

Obitelj adresa 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, vezanje socketa ne učvršćuje razrješavanje naziva: nazivi tracker hostova razrješavaju se kroz macOS razrješivač, koji slijedi DNS konfiguraciju sustava, a ne odabrani uređaj.

Tri načina na koja ispravan izbor naizgled ne uspijeva

Prvi neuspjeh je ne ponovno pokretanje. Polje pokazuje utun4, postavke izgledaju konfigurirano, a probni prijenos i dalje izlazi preko Wi-Fi-ja jer je aktivna sesija zadržala staru povezanost. Zatvorite potpuno, potvrdite pomoću pgrep, otvorite ponovno i ponovno pokrenite prijenos.

Drugi je zastario naziv nakon ponovnog povezivanja. Čim vezani uređaj nestane, peer veze ne uspijevaju i klijent obično prijavljuje tracker pogreš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 povezanost ne uspijeva zatvoreno. Odabir sučelja traži od sustava da pričvrsti sockete na naziv uređaja; što se događa kada taj naziv nedostaje ili se reciklira, zaslon postavki ne jamči. Test prekida u sljedećem odjeljku jedini je dokaz koji se računa.

Provjerite stvarnim prijenosom i prekidom

Upotrijebite prijenos koji vam je dopušteno pokrenuti, poput slike Linux distribucije, i pokrenite ga s povezanim VPN-om. Promatrajte brojače po sučelju prije i poslije te ih usporedite 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 njegova vlastitog sučelja i promatrajte prijenos. Peerovi bi trebali nestati, a nove veze bi trebale ne uspjeti ubrzo nakon što tunel padne. Ako se propusnost nastavi, povezanost nije na snazi i vraćate se na korak ponovnog pokretanja, a ne na vatrozid.

Ponovno se povežite i provjerite odabrani naziv još jednom, jer se tunel može vratiti 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 je postavka po računalu i po pružatelju, i ne preživljava ni nadogradnju klijenta ni promjenu VPN aplikacije.