Как привязать qBittorrent к интерфейсу VPN на macOS

Задайте Network Interface в расширенных настройках qBittorrent на macOS, сопоставьте имена utun с активным туннелем, перезапустите клиент и докажите привязку передачей.

Я открыл qBittorrent на Mac mini, поставил Network Interface на utun4, перезапустил и потом провёл полдня, наблюдая, как торрент висит на получении метаданных, хотя VPN всё ещё показывал здоровое соединение. Настройка в принципе не была ошибочной; имя устарело. macOS выдаёт номера utun при запуске служб, поэтому тот utun4, который был верным неделю назад, указывал на туннель, которого больше нет, а клиент привязывал свои сокеты к устройству без маршрута. Последовательность ниже — то, что я использую сейчас: прочитать интерфейс из работающего туннеля, выбрать его в клиенте, перезапустить сеанс и затем доказать привязку передачей и намеренным отключением.

Откройте Advanced и найдите поле интерфейса

В окне qBittorrent откройте Preferences сочетанием Cmd+, и перейдите на страницу Advanced. Network Interface — то поле, которое важно: оно перечисляет имена интерфейсов системы и по умолчанию стоит на Any Interface, то есть операционная система выбирает маршрут для каждого сокета, который открывает клиент. справочник по параметрам проекта описывает это поле и это значение по умолчанию, и это одна и та же настройка на всех платформах, хотя имена внутри неё не одинаковы.

Здесь людей сбивают с толку две вещи. Список показывает имена устройств, такие как en0, en1 и utun0 до utun9, никогда не название продукта провайдера VPN, поэтому вам нужно сопоставление, прежде чем выбирать что-то разумное. И выбор применяется при старте сеанса BitTorrent, а не в момент нажатия OK, поэтому изменение, которое выглядит сохранённым, может всё ещё работать на старой привязке.

Закройте приложение правильно, сочетанием Cmd+Q, и убедитесь, что процесс исчез, прежде чем открывать его снова. Закрытие окна лишь скрывает его, а скрытый клиент сохраняет сеанс, порт прослушивания и старый интерфейс.

pgrep -fl qbittorrent

Найдите интерфейс, которым ваш VPN действительно владеет

Сначала подключите VPN через собственный клиент провайдера, а затем читайте представление системы, а не меню клиента. Команды ниже перечисляют каждый интерфейс с его адресами, показывают, какие система считает активными, и печатают таблицу маршрутизации; вы ищете устройство utun, которое несёт приватный диапазон, выдаваемый вашим провайдером.

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

Три прочтения скажут, какое устройство является туннелем. Записи utun нужен адрес inet, принадлежащий пулу VPN. scutil --nwi показывает, какие интерфейсы система считает активными и какой из них основной. netstat -rn показывает, куда указывает маршрут по умолчанию, и если этот маршрут всё ещё указывает на en0, пока у utun есть адрес, туннель не несёт весь трафик, что меняет то, что привязка сделает позже.

Когда одновременно могут существовать два туннеля, например рабочий профиль и личный, оба устройства utun присутствуют, и полезно только одно из них. Счётчики байт решают вопрос: запишите счётчики, загрузите страницу или начните небольшую передачу и посмотрите, какой из них сдвинулся.

netstat -ib | grep utun

Не считайте номер стабильным. Повторное подключение может дать тому же туннелю другое имя utun, а служба iCloud или Continuity может занимать utun0 задолго до подключения вашего VPN.

Согласуйте привязку с областью действия туннеля

Поле привязывает устройство, и это всё, что оно делает. Если VPN — полный туннель, который направляет 0.0.0.0/0 в utun, привязка к этому устройству отправляет каждое соединение с пирами и каждый запрос к трекеру через VPN. Если VPN — разделённый туннель, который направляет только несколько подсетей, привязка к utun отправляет трафик пиров на устройство без маршрута для этих пиров, и передачи останавливаются, а не утекают. Оба результата безопаснее, чем Any Interface, но только один из них сохраняет работоспособность клиента. Вне клиента ничего не меняется: браузеры и другие приложения сохраняют свои маршруты, поэтому требование, охватывающее все приложения, должно применяться со стороны VPN.

Прочитайте ситуацию, прежде чем что-то выбирать:

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

Семейство адресов тоже важно. Провайдер, который выдаёт только IPv4, оставляет привязанный интерфейс без адреса IPv6, поэтому пиры IPv6 терпят неудачу вместо того, чтобы утечь через Wi-Fi. Отдельно: привязка сокетов не фиксирует разрешение имён: имена хостов трекеров разрешаются через резолвер macOS, который следует конфигурации DNS системы, а не выбранному устройству.

Три способа, которыми правильный на вид выбор терпит неудачу

Первая неудача — не перезапустить. Поле показывает utun4, настройки выглядят сконфигурированными, а тестовая передача всё равно выходит через Wi-Fi, потому что работающий сеанс сохранил старую привязку. Закройте полностью, подтвердите через pgrep, откройте снова и начните передачу заново.

Вторая — устаревшее имя после повторного подключения. Как только привязанное устройство исчезает, соединения с пирами терпят неудачу, и клиент обычно сообщает об ошибках трекера, а не о понятном сообщении, что интерфейс пропал, что читается как мёртвый торрент. Перечитайте ifconfig, выберите новое имя и перезапустите.

Третья — предположение, что привязка терпит неудачу закрыто. Выбор интерфейса просит систему прикрепить сокеты к имени устройства; что происходит, когда этого имени нет или его переиспользуют, экран настроек не гарантирует. Тест отключения в следующем разделе — единственное доказательство, которое считается.

Проверьте настоящей передачей и отключением

Используйте передачу, которую вам разрешено запускать, например образ дистрибутива Linux, и запустите её с подключённым VPN. Следите за счётчиками по интерфейсам до и после и сравнивайте их с собственным счётчиком данных клиента VPN; оба должны расти вместе, пока список пиров заполняется.

netstat -ib | grep utun
pgrep -fl qbittorrent

Затем отключите VPN с его собственного интерфейса и наблюдайте за передачей. Пиры должны исчезнуть, а новые соединения должны терпеть неудачу вскоре после падения туннеля. Если пропускная способность продолжается, привязка не действует, и вы вернулись к шагу перезапуска, а не к брандмауэру.

Подключитесь снова и проверьте выбранное имя ещё раз, потому что туннель может вернуться под другим utun. Короткая заметка с типом туннеля, именем интерфейса и ожидаемым поведением при падении VPN экономит следующий сеанс: эта настройка для каждой машины и каждого провайдера, и она не переживает ни обновления клиента, ни смены приложения VPN.

Похожие статьи