Я відкрив 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.

Схожі статті