Jak svázat qBittorrent s rozhraním VPN na macOS

Otevřel jsem qBittorrent na Mac mini, nastavil Network Interface na utun4, restartoval a pak strávil odpoledne sledováním, jak torrent stojí na získávání metadat, zatímco VPN stále ukazovalo zdravé připojení. Nastavení nebylo v zásadě špatné; název byl zastaralý. macOS přiděluje čísla utun při spouštění služeb, takže utun4, který byl předchozí týden správný, ukazoval na tunel, který už neexistoval, a klient svazoval své sockety se zařízením bez trasy. Postup níže je to, co používám nyní: přečíst rozhraní z běžícího tunelu, vybrat ho v klientovi, restartovat relaci a potom svázání prokázat přenosem a záměrným odpojením.

Otevřete Rozšířené a najděte pole rozhraní

V okně qBittorrentu otevřete Předvolby pomocí Cmd+, a přejděte na stránku Rozšířené. Network Interface je pole, na kterém záleží: vypisuje názvy rozhraní systému a ve výchozím stavu je na Any Interface, což znamená, že operační systém vybírá trasu pro každý socket, který klient otevře. přehled voleb projektu toto pole a tento výchozí stav dokumentuje a je to stejné nastavení na každé platformě, i když názvy v něm stejné nejsou.

Dva detaily tady lidi pletou. Seznam ukazuje názvy zařízení jako en0, en1 a utun0 až utun9, nikdy název produktu poskytovatele VPN, takže před rozumnou volbou potřebujete přiřazení. A volba se uplatní při startu relace BitTorrent, ne v okamžiku stisku OK, takže změna, která vypadá uložená, může stále běžet na starém svázání.

Ukončete aplikaci řádně pomocí Cmd+Q a před opětovným otevřením ověřte, že proces zmizel. Zavření okna ho jen skryje a skrytý klient si drží relaci, port pro naslouchání i staré rozhraní.

pgrep -fl qbittorrent

Najděte rozhraní, které vaše VPN skutečně vlastní

Nejprve připojte VPN přes vlastního klienta poskytovatele a potom čtěte pohled systému, ne nabídku klienta. Níže uvedené příkazy vypisují každé rozhraní s adresami, ukazují, která systém považuje za aktivní, a tisknou směrovací tabulku; hledáte zařízení utun, které nese privátní rozsah, jenž vám poskytovatel přiděluje.

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

Tři čtení vám řeknou, které zařízení je tunel. Záznam utun potřebuje adresu inet, která patří do poolu VPN. scutil --nwi ukazuje, která rozhraní systém považuje za aktivní a které je primární. netstat -rn ukazuje, kam směřuje výchozí trasa, a pokud tato trasa stále směřuje na en0, zatímco utun má adresu, tunel nenese veškerý provoz, což mění, co svázání později udělá.

Když mohou existovat dva tunely najednou, například pracovní a osobní profil, jsou přítomna obě zařízení utun a užitečné je jen jedno. Rozhodnou bajtové čítače: poznamenejte si čítače, načtěte stránku nebo spusťte malý přenos a podívejte se, který se pohnul.

netstat -ib | grep utun

Nepovažujte číslo za stabilní. Opětovné připojení může stejnému tunelu dát jiný název utun a služba iCloud nebo Continuity může držet utun0 dávno předtím, než se vaše VPN připojí.

Přizpůsobte svázání rozsahu tunelu

Pole svazuje zařízení a nic víc nedělá. Pokud je VPN plný tunel, který směruje 0.0.0.0/0 do utun, svázání s tímto zařízením posílá každé připojení k peerům a každý požadavek trackeru přes VPN. Pokud je VPN rozdělený tunel, který směruje jen několik podsítí, svázání s utun posílá provoz peerů na zařízení bez trasy pro tyto peery a přenosy se zastaví místo toho, aby unikaly. Oba výsledky jsou bezpečnější než Any Interface, ale jen jeden z nich udrží klienta funkční. Mimo klienta se nic nemění: prohlížeče a další aplikace si drží vlastní trasy, takže požadavek pokrývající všechny aplikace musí být prosazen ze strany VPN.

Přečtěte si situaci, než něco vyberete:

Na rodině adres také záleží. Poskytovatel, který přiděluje jen IPv4, nechává svázané rozhraní bez adresy IPv6, takže peery IPv6 selhávají, místo aby vyklouzly přes Wi-Fi. Odděleně: svázání socketů nefixuje překlad názvů: názvy hostitelů trackerů se překládají přes resolver macOS, který se řídí konfigurací DNS systému, ne vybraným zařízením.

Tři způsoby, jak správně vypadající volba selže

První selhání je nerestartovat. Pole ukazuje utun4, předvolby vypadají nastavené a testovací přenos přesto vychází přes Wi-Fi, protože běžící relace si ponechala staré svázání. Ukončete úplně, ověřte pomocí pgrep, otevřete znovu a přenos spusťte znovu.

Druhé je zastaralý název po opětovném připojení. Jakmile svázané zařízení zmizí, připojení k peerům selhávají a klient obvykle hlásí chyby trackeru místo čisté zprávy, že rozhraní zmizelo, což vypadá jako mrtvý torrent. Přečtěte ifconfig znovu, vyberte nový název a restartujte.

Třetí je předpoklad, že svázání selže zavřeně. Volba rozhraní žádá systém, aby připojil sockety k názvu zařízení; co se stane, když tento název chybí nebo se recykluje, obrazovka nastavení nezaručuje. Test odpojení v další části je jediný důkaz, který platí.

Ověřte skutečným přenosem a odpojením

Použijte přenos, který smíte spustit, například obraz distribuce Linuxu, a spusťte ho s připojenou VPN. Sledujte čítače po rozhraních před a po a porovnejte je s vlastním datovým čítačem klienta VPN; oba by měly růst společně, zatímco se plní seznam peerů.

netstat -ib | grep utun
pgrep -fl qbittorrent

Potom odpojte VPN z jejího vlastního rozhraní a sledujte přenos. Peery by měly zmizet a nová připojení by měla krátce po pádu tunelu selhat. Pokud propustnost pokračuje, svázání neplatí a jste zpět u kroku restartu, ne u firewallu.

Připojte se znovu a znovu zkontrolujte vybraný název, protože tunel se může vrátit pod jiným utun. Krátká poznámka s typem tunelu, názvem rozhraní a očekávaným chováním při pádu VPN ušetří příští relaci: toto nastavení je pro každý stroj a každého poskytovatele a nepřežije ani upgrade klienta, ani změnu aplikace VPN.