Як прив'язати 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 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 |
Сімейство адрес також важливе. Постачальник, який видає лише 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.