Зошто 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 е предизвикувачот во сите три; причина е ретко.