De ce VPN-ul de pe Mac cade când conectezi un iPhone prin USB

Conectezi un iPhone ca să se încarce, iar un minut mai târziu VPN-ul de pe Mac nu mai lasă traficul să treacă. Setările sistemului arată un serviciu nou numit iPhone USB, iar mișcarea evidentă este să-l ștergi. Acea mișcare este adesea greșită. Serviciul poate fi Hotspotul personal al telefonului sau poate fi o legătură pe care Xcode și instrumentele pentru dispozitive o folosesc pentru a vorbi cu telefonul, iar cele două se comportă destul de diferit încât identificarea trebuie să vină înainte de ștergere.

Pasul 1: Citește serviciul pe care telefonul l-a creat de fapt

Deschide Setările sistemului, apoi Rețea, și compară lista de servicii cu telefonul deconectat și conectat. În macOS-ul actual serviciul apare ca iPhone USB. Observă dacă este activ, unde se află în ordinea serviciilor și dacă Mac-ul îl folosește pentru ruta implicită. Ordinea serviciilor contează pentru că macOS alege cel mai înalt serviciu activ care poate ajunge la o destinație, nu pe cel al cărui nume îl recunoști.

Ghidul Apple despre Hotspotul personal descrie mecanismul: cât timp Hotspotul personal este activat pe telefon, conectarea lui prin USB poate face Mac-ul să folosească conexiunea celulară a telefonului, chiar când voiai doar să îl încarci. Nu este o eroare a clientului VPN; tabela de rutare urmează un serviciu care a urcat înaintea Wi-Fi-ului.

Dacă serviciul există dar rămâne inactiv cu telefonul conectat, cel mai probabil vezi o conexiune doar pentru încărcare sau o legătură de dispozitiv, nu un hotspot. Păstrează această distincție, pentru că următorii doi pași o testează în loc să o ghicească după pictogramă.

Pasul 2: Verifică ce rută folosește punctul final al VPN-ului

Citește ruta către adresa rezolvată a serverului VPN, nu către un site web. route -n get este doar pentru citire și tipărește interfața și gateway-ul pe care le-ar folosi nucleul, iar ambele linii contează.

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

Adresa de mai sus este un substituent pentru documentație. Înlocuiește-o cu punctul final pe care îl arată clientul tău și folosește route -n get -inet6 pentru un punct final IPv6. Compară ieșirea cu telefonul deconectat și conectat și nu adăuga sau elimina rute între cele două citiri. Dacă interfața se schimbă din en0 în interfața iPhone USB, ruta prin hotspot a câștigat căutarea, iar conexiunea exterioară a VPN-ului merge acum prin rețeaua celulară.

O schimbare de rută nu explică orice eșec. Clientul poate ajunge în continuare la server și poate eșua mai târziu pe traficul interior al tunelului, pentru că noua cale are alt MTU sau operatorul blochează protocolul. Citește eroarea proprie a clientului înainte de a schimba ceva: un timp limită al strângerii de mână exterioare indică accesibilitatea, iar un tunel stabilit care nu mai lasă traficul să treacă indică MTU, DNS sau politică.

Pasul 3: Separă un hotspot de o legătură de comunicare cu dispozitivul

Xcode 15 și versiunile mai noi vorbesc cu un dispozitiv conectat prin USB pe un canal bazat pe rețea care include IPv6 local de legătură, așa că un Mac de dezvoltare poate arăta o interfață suplimentară fără nicio legătură cu accesul la internet. Nota tehnică TN3158 a Apple documentează acest comportament și avertizează că VPN-ul sau filtrarea de securitate poate interfera. Este inversul problemei hotspotului: VPN-ul nu se strică pentru că telefonul oferă internet; conexiunea dispozitivului se strică pentru că VPN-ul o captează.

Două observații separă cazurile fără captură de pachete. Întâi, verifică dacă interfața are adresă rutabilă și rută implicită, sau doar o adresă fe80:: locală de legătură; doar locală de legătură înseamnă că nu există cale spre internet. Apoi, închide VPN-ul și vezi dacă Xcode ajunge din nou la dispozitiv. Dacă ajunge, rutele sau filtrul de conținut al VPN-ului captează traficul local de legătură, iar corecția aparține configurației tunelului divizat sau filtrului, nu panoului Rețea.

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

Nu judeca doar după numele interfeței. macOS creează și distruge aceste interfețe pe măsură ce dispozitivele se conectează, iar numărul en este alocat la execuție, așa că același Mac poate arăta alt număr după o repornire sau o schimbare de cablu.

Pasul 4: Reprodu eșecul cu o singură variabilă deodată

După ce știi ce serviciu este implicat, reproduc problema într-o ordine fixă. Începe cu telefonul deconectat și VPN-ul conectat. Conectează telefonul cu Hotspotul personal oprit, așteaptă ca lista Rețea să se stabilizeze și rulează din nou interogarea de rută. Deconectează, activează Hotspotul personal, conectează din nou și repetă. Notează interfața, gateway-ul și eroarea clientului pentru fiecare dintre cele trei stări, și ai o comparație în loc de o amintire.

Dacă VPN-ul eșuează doar în starea de hotspot, ține telefonul departe de acea cale: oprește Hotspotul personal în timpul încărcării sau mută serviciul iPhone USB sub Wi-Fi în ordinea serviciilor. Dacă eșuează în fiecare stare conectată, inclusiv cu hotspotul oprit, uită-te la modul în care clientul tratează o tranziție de rețea. Unii clienți desființează tunelul când se schimbă serviciul principal și au nevoie de reconectare; acesta este comportamentul clientului, nu un defect al telefonului.

Schimbă un singur lucru pe încercare. Ștergerea serviciului, resetarea configurației VPN și reinstalarea clientului în același minut te lasă cu un Mac funcțional și fără nicio idee care acțiune l-a reparat.

Pasul 5: Decide ce păstrezi și ce verifici

Lasă legătura dispozitivului în pace. Eliminarea unei interfețe pe care Xcode o folosește nu repară o rută VPN și strică implementarea pe dispozitive până la următoarea conectare. Dacă serviciul de hotspot chiar nu este dorit, oprește mai întâi Hotspotul personal pe telefon; acesta este controlul documentat și supraviețuiește unei reporniri.

Dacă totuși elimini un serviciu, elimină-l pe cel identificat și apoi verifică două lucruri: ruta către punctul final al VPN-ului a revenit pe interfața așteptată, iar tunelul lasă traficul să treacă spre o adresă internă, nu doar spre internet. Notează ordinea serviciilor și versiunea clientului, pentru că o actualizare de macOS poate schimba felul în care apare telefonul.

Apoi clasifică eșecul pe care l-ai văzut de fapt. Un timp limită al strângerii de mână, o oprire a MTU după ce tunelul urcă și răspunsuri DNS care vin de la operator sunt trei probleme diferite cu trei corecții diferite. Serviciul USB este declanșatorul în toate trei; cauza este rar.