Hogyan köthetjük a qBittorrentet VPN-interfészhez macOS-en
Állítsa be a Network Interface-t a qBittorrent speciális beállításaiban macOS-en, rendelje az utun-neveket az aktív alagúthoz, indítsa újra a klienst, majd bizonyítsa a kötést egy átvitellel.
Megnyitottam a qBittorrentet egy Mac minin, a Network Interface-t utun4-re állítottam, újraindítottam, majd egy egész délutánt azzal töltöttem, hogy néztem, ahogy egy torrent megakad a metaadatok lekérésénél, miközben a VPN továbbra is egészséges kapcsolatot mutatott. A beállítás elvileg nem volt rossz; a név volt elavult. A macOS az utun-számokat a szolgáltatások indulásakor osztja ki, ezért az az utun4, amely egy héttel korábban helyes volt, már nem létező alagútra mutatott, és a kliens a socketjeit egy útvonal nélküli eszközhöz kötötte. Az alábbi sorrend az, amit most használok: olvassa ki az interfészt a futó alagútból, válassza ki a kliensben, indítsa újra a munkamenetet, majd bizonyítsa a kötést egy átvitellel és egy szándékos bontással.
Nyissa meg a Speciális beállításokat, és keresse meg az interfész mezőt
A qBittorrent ablakában nyissa meg a Beállításokat a Cmd+, kombinációval, és lépjen a Speciális oldalra. A Network Interface az a mező, amely számít: felsorolja a rendszer interfészneveit, és alapértelmezésben az Any Interface-en áll, ami azt jelenti, hogy az operációs rendszer minden sockethez útvonalat választ, amelyet a kliens megnyit. A projekt beállítási referenciája dokumentálja ezt a mezőt és ezt az alapértelmezést, és ez ugyanaz a beállítás minden platformon, bár a benne szereplő nevek nem azonosak.
Két részlet zavarja meg itt az embereket. A lista olyan eszközneveket mutat, mint az en0, en1 és utun0 az utun9-ig, soha nem a VPN-szolgáltató terméknevét, ezért szüksége van a leképezésre, mielőtt bármi értelmeset választhatna. És a kiválasztás a BitTorrent-munkamenet indulásakor lép életbe, nem az OK megnyomásának pillanatában, ezért egy mentettnek látszó változás még mindig a régi kötésen futhat.
Lépjen ki az alkalmazásból megfelelően a Cmd+Q-val, és ellenőrizze, hogy a folyamat eltűnt, mielőtt újra megnyitja. Az ablak bezárása csak elrejti, és egy rejtett kliens megtartja a munkamenetét, a figyelő portját és a régi interfészét.
pgrep -fl qbittorrentKeresse meg az interfészt, amely valóban a VPN-jéhez tartozik
Először a szolgáltató saját kliensén keresztül csatlakoztassa a VPN-t, majd a kliens menüje helyett a rendszer nézetét olvassa. Az alábbi parancsok felsorolják az összes interfészt a címeivel, megmutatják, melyeket tekint a rendszer aktívnak, és kiírják az útvonaltáblát; azt az utun-eszközt keresi, amely a szolgáltatója által adott privát tartományt hordozza.
ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5Három olvasat mondja meg, melyik eszköz az alagút. Az utun bejegyzésnek a VPN pooljához tartozó inet-címre van szüksége. A scutil --nwi megmutatja, mely interfészeket tekint a rendszer aktívnak, és melyik az elsődleges. A netstat -rn megmutatja, hová mutat az alapértelmezett útvonal, és ha az az útvonal továbbra is az en0-ra mutat, miközben egy utun rendelkezik címmel, akkor az alagút nem viszi az összes forgalmat, ami megváltoztatja, hogy a kötés később mit tesz.
Amikor két alagút létezhet egyszerre, például egy munka- és egy személyes profil, mindkét utun-eszköz jelen van, és csak az egyikük hasznos. A bájtszámlálók eldöntik a kérdést: jegyezze fel a számlálókat, töltsön be egy oldalt vagy indítson egy kis átvitelt, és nézze meg, melyik mozdult el.
netstat -ib | grep utunA számot se tekintse stabilnak. Az újracsatlakozás más utun-nevet adhat ugyanannak az alagútnak, és egy iCloud- vagy Continuity-szolgáltatás jóval a VPN csatlakozása előtt lefoglalhatja az utun0-t.
Igazítsa a kötést az alagút hatóköréhez
A mező egy eszközt köt, és ennyi az egész. Ha a VPN teljes alagút, amely a 0.0.0.0/0-t az utunba irányítja, akkor az eszközhöz kötés minden peer-kapcsolatot és minden tracker-kérést a VPN-en keresztül küld. Ha a VPN osztott alagút, amely csak néhány alhálózatot irányít, akkor az utunhoz kötés a peer-forgalmat egy olyan eszközre küldi, amelynek nincs útvonala ezekhez a peer-ekhez, és az átvitelek megállnak ahelyett, hogy szivárognának. Mindkét eredmény biztonságosabb az Any Interface-nél, de csak az egyik tartja működőképesen a klienst. A klienesen kívül semmi sem változik: a böngészők és más alkalmazások megtartják a saját útvonalaikat, ezért a minden alkalmazást lefedő követelményt a VPN oldaláról kell érvényesíteni.
Olvassa el a helyzetet, mielőtt bármit kiválaszt:
| What you see | What it means for the bind |
|---|---|
| A utun with a provider address and the default route pointing at it | Full tunnel; the bind covers peer and tracker traffic |
| A utun with a provider address but the default route still on en0 | Split tunnel; the bind will stall transfers unless the provider routes 0.0.0.0/0 |
| No utun carrying a provider address | The VPN is down or connects on demand; bring it up before selecting |
| A utun number that changed since the last session | The saved name is stale; reselect and restart |
A címcsalád is számít. Az a szolgáltató, amely csak IPv4-et ad, IPv6-cím nélkül hagyja a kötött interfészt, ezért az IPv6-os peer-ek meghiúsulnak ahelyett, hogy kicsúsznának a Wi-Fi-n. Ettől függetlenül a socketek kötése nem rögzíti a névfeloldást: a tracker-gépnevek a macOS feloldóján keresztül oldódnak fel, amely a rendszer DNS-konfigurációját követi, nem a kiválasztott eszközt.
Három módja annak, ahogy egy helyesnek látszó kiválasztás meghiúsul
Az első hiba az, hogy nem indítja újra. A mező az utun4-et mutatja, a beállítások konfiguráltnak látszanak, és egy tesztátvitel mégis a Wi-Fi-n keresztül megy ki, mert a futó munkamenet megtartotta a régi kötést. Lépjen ki teljesen, ellenőrizze a pgrep-pel, nyissa meg újra, és indítsa újra az átvitelt.
A második az elavult név újracsatlakozás után. Amint a kötött eszköz eltűnik, a peer-kapcsolatok meghiúsulnak, és a kliens inkább tracker-hibákat jelent, mint egy tiszta üzenetet arról, hogy az interfész eltűnt, ami halott torrentnek tűnik. Olvassa újra az ifconfig-ot, válassza ki az új nevet, és indítsa újra.
A harmadik annak feltételezése, hogy a kötés zártan hibázik. Az interfész kiválasztása azt kéri a rendszertől, hogy socketeket kapcsoljon egy eszköznévhez; hogy mi történik, ha ez a név hiányzik vagy újrahasznosítják, azt a beállítások képernyője nem garantálja. A következő szakasz bontási tesztje az egyetlen bizonyíték, amely számít.
Ellenőrizze valódi átvitellel és bontással
Használjon olyan átvitelt, amelyet engedélyezett futtatni, például egy Linux-disztribúció lemezképét, és indítsa el a VPN csatlakoztatva. Figyelje az interfészenkénti számlálókat előtte és utána, és hasonlítsa össze őket a VPN-kliens saját adatszámlálójával; mindkettőnek együtt kell emelkednie, miközben a peer-lista megtelik.
netstat -ib | grep utun
pgrep -fl qbittorrentEzután bontsa a VPN-t a saját felületéről, és figyelje az átvitelt. A peer-eknek el kell tűnniük, és az új kapcsolatoknak röviddel az alagút leomlása után meg kell hiúsulniuk. Ha az átviteli sebesség folytatódik, a kötés nem érvényes, és visszatért az újraindítási lépéshez, nem a tűzfalhoz.
Csatlakozzon újra, és ellenőrizze még egyszer a kiválasztott nevet, mert az alagút más utun alatt térhet vissza. Egy rövid feljegyzés az alagút típusáról, az interfész nevéről és a VPN leomlásakor várható viselkedésről megkíméli a következő munkamenetet: ez a beállítás gépenként és szolgáltatónként érvényes, és sem egy kliensfrissítést, sem a VPN-alkalmazás cseréjét nem éli túl.