Защо 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 устройство по мрежов канал, който включва локален за връзката IPv6, така че Mac за разработка може да покаже допълнителен интерфейс, който няма нищо общо с достъпа до интернет. Техническата бележка на Apple TN3158 документира това поведение и предупреждава, че VPN или филтрирането за сигурност може да му пречат. Това е обратното на проблема с хотспота: VPN не се чупи, защото телефонът предлага интернет; връзката с устройството се чупи, защото VPN я прихваща.

Две наблюдения разделят случаите без прихващане на пакети. Първо, проверете дали интерфейсът има маршрутизируем адрес и маршрут по подразбиране, или само локален за връзката адрес fe80::; само локален за връзката означава, че няма път към интернет. Второ, изключете VPN и вижте дали Xcode отново достига устройството. Ако може, маршрутите на VPN или филтърът за съдържание прихващат трафика по локалната връзка и поправката принадлежи на конфигурацията на разделения тунел или филтъра, а не на панела Мрежа.

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 услугата е спусъкът и в трите; причината е рядко.