Чому VPN на Mac вимикається, коли ви підключаєте iPhone через USB

Ви підключаєте iPhone для заряджання, і за хвилину VPN на Mac перестає пропускати трафік. У Параметрах системи з'являється нова служба iPhone USB, і очевидний крок — видалити її. Цей крок часто помилковий. Служба може бути точкою доступу телефона або з'єднанням, яке Xcode та інструменти для пристроїв використовують для зв'язку з телефоном, і поводяться вони достатньо по-різному, щоб спершу визначити, що це.

Крок 1: Прочитайте службу, яку телефон справді створив

Відкрийте Параметри системи, потім Мережу та порівняйте список служб із телефоном від'єднаним і під'єднаним. У поточній macOS служба вказана як iPhone USB. Зверніть увагу, чи вона активна, де стоїть у порядку служб і чи використовує Mac її для маршруту за замовчуванням. Порядок служб важливий, бо macOS обирає найвищу активну службу, здатну досягти пункту призначення, а не ту, чию назву ви впізнаєте.

Посібник Apple щодо точки доступу описує механізм: доки на телефоні ввімкнено точку доступу, підключення через USB може змусити Mac використовувати стільникове з'єднання телефона, навіть якщо ви хотіли лише зарядити його. Це не помилка клієнта VPN; таблиця маршрутизації йде за службою, яка піднялася раніше за Wi-Fi.

Якщо служба існує, але залишається неактивною з під'єднаним телефоном, ви, найімовірніше, бачите з'єднання лише для заряджання або зв'язок із пристроєм, а не точку доступу. Збережіть цю відмінність, бо наступні два кроки перевіряють її, а не вгадують за значком.

Крок 2: Перевірте, який маршрут використовує кінцева точка VPN

Читайте маршрут до розв'язаної адреси сервера VPN, а не до вебсайту. route -n get лише читає та друкує інтерфейс і шлюз, які використовувало б ядро, і обидва рядки важливі.

scutil --dns | head -20
route -n get 203.0.113.10

Адреса вище — заповнювач для документації. Замініть її кінцевою точкою, яку показує ваш клієнт, і використайте route -n get -inet6 для кінцевої точки IPv6. Порівняйте вивід із телефоном від'єднаним і під'єднаним і не додавайте та не видаляйте маршрути між двома читаннями. Якщо інтерфейс змінюється з en0 на інтерфейс iPhone USB, маршрут через точку доступу виграв пошук, і зовнішнє з'єднання VPN тепер іде через стільникову мережу.

Зміна маршруту не пояснює кожну невдачу. Клієнт усе ще може досягти сервера й пізніше зазнати невдачі на внутрішньому трафіку тунелю, бо новий шлях має інший MTU або оператор блокує протокол. Прочитайте власну помилку клієнта, перш ніж щось змінювати: зовнішній тайм-аут рукостискання вказує на доступність, а встановлений тунель, що перестає пропускати трафік, — на MTU, DNS або політику.

Крок 3: Відокремте точку доступу від зв'язку з пристроєм

Xcode 15 і новіші версії спілкуються з під'єднаним через USB пристроєм мережевим каналом, що включає link-local IPv6, тому на Mac для розробки може з'явитися додатковий інтерфейс, який не має жодного відношення до доступу в інтернет. Технічна замітка Apple TN3158 документує цю поведінку й попереджає, що VPN або фільтрація безпеки може їй заважати. Це зворотний бік проблеми точки доступу: VPN ламається не тому, що телефон пропонує інтернет, а зв'язок із пристроєм ламається тому, що VPN його перехоплює.

Два спостереження розділяють випадки без перехоплення пакетів. По-перше, перевірте, чи має інтерфейс маршрутизовану адресу та маршрут за замовчуванням або лише link-local адресу fe80::; лише link-local означає, що шляху в інтернет немає. По-друге, закрийте VPN і подивіться, чи Xcode знову дістається до пристрою. Якщо так, маршрути або фільтр вмісту VPN перехоплюють link-local трафік, і виправлення належить до налаштування роздільного тунелю чи фільтра, а не до панелі «Мережа».

ifconfig | grep -A4 -E '^en[0-9]+:'
netstat -rn -f inet6 | head

Не судіть лише за назвою інтерфейсу. macOS створює й знищує ці інтерфейси в міру підключення пристроїв, а номер en призначається під час роботи, тож той самий Mac може показати інший номер після перезавантаження або заміни кабелю.

Крок 4: Відтворіть збій з однією змінною за раз

Коли ви знаєте, яка служба задіяна, відтворіть проблему у фіксованому порядку. Почніть із від'єднаного телефона й підключеного VPN. Підключіть телефон із вимкненою точкою доступу, дочекайтеся стабілізації списку «Мережа» й знову виконайте запит маршруту. Від'єднайте, увімкніть точку доступу, підключіть знову й повторіть. Запишіть інтерфейс, шлюз і помилку клієнта для кожного з трьох станів, і у вас буде порівняння замість спогаду.

Якщо VPN падає лише в стані точки доступу, тримайте телефон подалі від цього шляху: вимикайте точку доступу під час заряджання або перемістіть службу iPhone USB нижче Wi-Fi у порядку служб. Якщо він падає в будь-якому під'єднаному стані, зокрема з вимкненою точкою доступу, подивіться, як клієнт обробляє перехід мережі. Деякі клієнти зносять тунель, коли змінюється основна служба, і потребують повторного підключення; це поведінка клієнта, а не дефект телефона.

Змінюйте по одній речі за спробу. Видалення служби, скидання конфігурації VPN і переінсталяція клієнта в ту саму хвилину залишать вас із робочим Mac і без розуміння, яка дія це виправила.

Крок 5: Вирішіть, що залишити, а що перевірити

Не чіпайте зв'язок із пристроєм. Видалення інтерфейсу, який використовує Xcode, не виправляє маршрут VPN і ламає розгортання на пристрої до наступного підключення. Якщо служба точки доступу справді не потрібна, спершу вимкніть точку доступу на телефоні; це задокументоване керування, і воно переживає перезавантаження.

Якщо ви все ж видаляєте службу, видаліть ту, яку визначили, і потім перевірте дві речі: маршрут до кінцевої точки VPN повернувся на очікуваний інтерфейс, а тунель пропускає трафік до внутрішньої адреси, а не лише в інтернет. Запишіть порядок служб і версію клієнта, бо оновлення macOS може змінити те, як виглядає телефон.

Потім класифікуйте збій, який ви насправді бачили. Тайм-аут рукостискання, зупинка MTU після підняття тунелю й відповіді DNS, що надходять від оператора, — три різні проблеми з трьома різними виправленнями. Служба USB — спусковий гачок у всіх трьох; причиною вона буває рідко.