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 qbittorrent

Keresse 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 5

Há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 utun

A 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 seeWhat it means for the bind
A utun with a provider address and the default route pointing at itFull tunnel; the bind covers peer and tracker traffic
A utun with a provider address but the default route still on en0Split tunnel; the bind will stall transfers unless the provider routes 0.0.0.0/0
No utun carrying a provider addressThe VPN is down or connects on demand; bring it up before selecting
A utun number that changed since the last sessionThe 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 qbittorrent

Ezutá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.

Kapcsolódó cikkek