Jak powiązać qBittorrent z interfejsem VPN na macOS
Ustaw Network Interface w zaawansowanych opcjach qBittorrent na macOS, przypisz nazwy utun do aktywnego tunelu, uruchom ponownie klienta i udowodnij powiązanie transferem.
Otworzyłem qBittorrent na Mac mini, ustawiłem Network Interface na utun4, uruchomiłem ponownie, a potem spędziłem popołudnie, patrząc, jak torrent stoi na pobieraniu metadanych, podczas gdy VPN wciąż pokazywał zdrowe połączenie. Ustawienie nie było błędne co do zasady; nazwa była nieaktualna. macOS przydziela numery utun przy starcie usług, więc utun4, który był poprawny tydzień wcześniej, wskazywał na tunel, którego już nie było, a klient wiązał swoje gniazda z urządzeniem bez trasy. Poniższa kolejność to ta, której używam teraz: odczytaj interfejs z działającego tunelu, wybierz go w kliencie, uruchom sesję ponownie, a następnie udowodnij powiązanie transferem i świadomym rozłączeniem.
Otwórz Zaawansowane i znajdź pole interfejsu
W oknie qBittorrent otwórz Preferencje skrótem Cmd+, i przejdź do strony Zaawansowane. Network Interface to pole, które ma znaczenie: wymienia nazwy interfejsów systemu i domyślnie stoi na Any Interface, co oznacza, że system operacyjny wybiera trasę dla każdego gniazda otwieranego przez klienta. opis opcji projektu dokumentuje to pole i tę wartość domyślną, i jest to to samo ustawienie na każdej platformie, choć nazwy w nim nie są takie same.
Dwa szczegóły sprawiają tu kłopoty. Lista pokazuje nazwy urządzeń, takie jak en0, en1 i utun0 do utun9, nigdy nazwy produktu dostawcy VPN, więc potrzebujesz przyporządkowania, zanim wybierzesz coś sensownego. A wybór jest stosowany przy starcie sesji BitTorrent, a nie w chwili naciśnięcia OK, więc zmiana, która wygląda na zapisaną, może nadal działać na starym powiązaniu.
Zamknij aplikację prawidłowo skrótem Cmd+Q i potwierdź, że proces zniknął, zanim otworzysz ją ponownie. Zamknięcie okna tylko ją ukrywa, a ukryty klient zachowuje sesję, port nasłuchu i stary interfejs.
pgrep -fl qbittorrentZnajdź interfejs, który naprawdę należy do twojego VPN
Najpierw połącz VPN przez własnego klienta dostawcy, a potem czytaj widok systemu, a nie menu klienta. Poniższe polecenia wymieniają każdy interfejs z jego adresami, pokazują, które system uznaje za aktywne, i drukują tablicę tras; szukasz urządzenia utun, które niesie prywatny zakres przydzielany przez twojego dostawcę.
ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5Trzy odczyty mówią, które urządzenie jest tunelem. Wpis utun potrzebuje adresu inet należącego do puli VPN. scutil --nwi pokazuje, które interfejsy system uznaje za aktywne i który jest główny. netstat -rn pokazuje, dokąd prowadzi trasa domyślna, a jeśli ta trasa nadal wskazuje na en0, podczas gdy utun ma adres, tunel nie niesie całego ruchu, co zmienia to, co powiązanie zrobi później.
Gdy jednocześnie mogą istnieć dwa tunele, na przykład profil służbowy i prywatny, oba urządzenia utun są obecne i tylko jedno z nich jest użyteczne. Liczniki bajtów rozstrzygają sprawę: zapisz liczniki, wczytaj stronę albo rozpocznij mały transfer i zobacz, który się poruszył.
netstat -ib | grep utunNie traktuj numeru jako stałego. Ponowne połączenie może nadać temu samemu tunelowi inną nazwę utun, a usługa iCloud lub Continuity może trzymać utun0 długo przed połączeniem twojego VPN.
Dopasuj powiązanie do zasięgu tunelu
Pole wiąże urządzenie i to wszystko, co robi. Jeśli VPN jest pełnym tunelem, który kieruje 0.0.0.0/0 do utun, powiązanie z tym urządzeniem wysyła każde połączenie z peerem i każde żądanie trackera przez VPN. Jeśli VPN jest tunelem dzielonym, który kieruje tylko kilka podsieci, powiązanie z utun wysyła ruch peerów do urządzenia bez trasy dla tych peerów, a transfery zatrzymują się zamiast wyciekać. Oba wyniki są bezpieczniejsze niż Any Interface, ale tylko jeden z nich utrzymuje klienta w działaniu. Poza klientem nic się nie zmienia: przeglądarki i inne aplikacje zachowują własne trasy, więc wymóg obejmujący wszystkie aplikacje musi być egzekwowany od strony VPN.
Przeczytaj sytuację, zanim cokolwiek wybierzesz:
| 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 |
Rodzina adresów też ma znaczenie. Dostawca, który przydziela tylko IPv4, zostawia powiązany interfejs bez adresu IPv6, więc peery IPv6 ponoszą porażkę zamiast wymykać się przez Wi-Fi. Osobno: powiązanie gniazd nie ustala rozwiązywania nazw: nazwy hostów trackerów są rozwiązywane przez resolver macOS, który stosuje konfigurację DNS systemu, a nie wybrane urządzenie.
Trzy sposoby, w jakie poprawnie wyglądający wybór zawodzi
Pierwsza porażka to brak ponownego uruchomienia. Pole pokazuje utun4, preferencje wyglądają na skonfigurowane, a testowy transfer i tak wychodzi przez Wi-Fi, bo działająca sesja zachowała stare powiązanie. Zamknij całkowicie, potwierdź przez pgrep, otwórz ponownie i zacznij transfer od nowa.
Druga to nieaktualna nazwa po ponownym połączeniu. Gdy powiązane urządzenie znika, połączenia z peerami zawodzą, a klient zwykle zgłasza błędy trackera zamiast jasnego komunikatu, że interfejs zniknął, co wygląda jak martwy torrent. Przeczytaj ifconfig ponownie, wybierz nową nazwę i uruchom ponownie.
Trzecia to założenie, że powiązanie zawodzi zamknięcie. Wybór interfejsu prosi system o przypięcie gniazd do nazwy urządzenia; co się dzieje, gdy tej nazwy brakuje lub jest odzyskiwana, nie gwarantuje ekran ustawień. Test rozłączenia w następnej sekcji jest jedynym dowodem, który się liczy.
Sprawdź prawdziwym transferem i rozłączeniem
Użyj transferu, na który masz zgodę, na przykład obrazu dystrybucji Linux, i uruchom go z podłączonym VPN. Obserwuj liczniki na interfejs pokazane przed i po i porównaj je z własnym licznikiem danych klienta VPN; oba powinny rosnąć razem, gdy lista peerów się zapełnia.
netstat -ib | grep utun
pgrep -fl qbittorrentPotem rozłącz VPN z jego własnego interfejsu i obserwuj transfer. Peery powinny zniknąć, a nowe połączenia powinny zawieść wkrótce po upadku tunelu. Jeśli przepustowość trwa, powiązanie nie działa i wracasz do kroku ponownego uruchomienia, a nie do zapory.
Połącz ponownie i sprawdź wybraną nazwę jeszcze raz, bo tunel może wrócić pod innym utun. Krótka notatka z typem tunelu, nazwą interfejsu i oczekiwanym zachowaniem przy upadku VPN oszczędza następną sesję: to ustawienie jest na maszynę i na dostawcę, i nie przeżywa ani aktualizacji klienta, ani zmiany aplikacji VPN.