Kvifor VPN-en på Macen fell ut når du koplar til ein iPhone via USB

Du koplar til ein iPhone for å lade han, og eit minutt seinare sluttar VPN-en på Macen å føre trafikk. Systeminnstillingar viser ei ny teneste som heiter iPhone USB, og det openberre trekket er å slette henne. Det trekket er ofte feil. Tenesta kan vere Personleg hotspot på telefonen, eller ho kan vere ei kopling som Xcode og einingverkty brukar for å snakke med telefonen, og dei to oppfører seg ulikt nok til at identifisering må kome før sletting.

Steg 1: Les tenesta telefonen faktisk oppretta

Opne Systeminnstillingar, deretter Nettverk, og samanlikn tenestelista med telefonen fråkopla og tilkopla. På gjeldande macOS er tenesta lista som iPhone USB. Legg merke til om ho er aktiv, kvar ho står i tenesterekkjefølgja, og om Macen brukar henne til standardruta. Tenesterekkjefølgja har noko å seie fordi macOS vel den høgaste aktive tenesta som kan nå ein destinasjon, ikkje den du kjenner namnet på.

Apple si rettleiing for Personleg hotspot skildrar mekanismen: så lenge Personleg hotspot er slått på på telefonen, kan ei USB-tilkopling få Macen til å bruke mobilkoplinga til telefonen, sjølv når du berre ville lade. Det er ikkje ein feil i VPN-klienten; rutetabellen følgjer ei teneste som kom opp før Wi-Fi.

Viss tenesta finst, men blir verande inaktiv med telefonen tilkopla, ser du truleg ei rein ladekopling eller ei einingkopling, ikkje ein hotspot. Hald på den skilnaden, fordi dei neste to stega testar han i staden for å gjette ut frå ikonet.

Steg 2: Sjekk kva rute VPN-endepunktet brukar

Les ruta til den oppslåtte adressa til VPN-tenaren, ikkje til eit nettstad. route -n get er skriveverna og skriv ut grensesnittet og gatewayen kjernen ville bruke, og begge linjene har noko å seie.

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

Adressa ovanfor er ein plasshaldar for dokumentasjon. Byt henne ut med endepunktet klienten din viser, og bruk route -n get -inet6 for eit IPv6-endepunkt. Samanlikn utdataa med telefonen fråkopla og tilkopla, og ikkje legg til eller fjern ruter mellom dei to lesingane. Viss grensesnittet endrar seg frå en0 til iPhone USB-grensesnittet, vann hotspot-ruta oppslaget og den ytre sambindinga til VPN-en går no over mobilnettet.

Ei ruteendring forklarar ikkje alle feil. Klienten kan framleis nå tenaren og feile seinare på den indre trafikken i tunnelen, fordi den nye vegen har ein annan MTU eller operatøren blokkerer protokollen. Les klienten sin eigen feil før du endrar noko: ein ytre handshake-timeout peikar på tilgjenge, medan ein etablert tunnel som sluttar å føre trafikk peikar på MTU, DNS eller policy.

Steg 3: Skil ein hotspot frå ei einingkommunikasjonskopling

Xcode 15 og nyare snakkar med ei USB-tilkopla eining over ein nettverksbasert kanal som omfattar link-lokal IPv6, så ein utviklar-Mac kan vise eit ekstra grensesnitt som ikkje har noko med internettilgang å gjere. Det tekniske notatet TN3158 frå Apple dokumenterer denne åtferda og åtvarar om at VPN eller tryggingsfiltrering kan forstyrre han. Dette er det motsette av hotspot-problemet: VPN-en bryt ikkje fordi telefonen tilbyr internett; einingkoplinga bryt fordi VPN-en fangar henne.

To observasjonar skil tilfella utan pakkefangst. Fyrst, sjekk om grensesnittet har ei rutbar adresse og ei standardrute, eller berre ei link-lokal fe80:: adresse; berre link-lokal tyder at det ikkje finst nokon internettveg. For det andre, avslutt VPN-en og sjå om Xcode når eininga igjen. Viss han gjer det, fangar rutene eller innhaldsfilteret til VPN-en den link-lokale trafikken, og rettinga høyrer i konfigurasjonen for delt tunnel eller filter, ikkje i Nettverk-panelet.

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

Ikkje døm etter grensesnittnamnet åleine. macOS opprettar og øydelegg desse grensesnitta etter kvart som einingar blir kopla til, og en-nummeret blir tildelt ved køyring, så same Mac kan vise eit anna nummer etter ein omstart eller eit kabelbyte.

Steg 4: Gjenskap feilen med éin variabel om gongen

Når du veit kva teneste som er involvert, gjenskap problemet i fast rekkjefølgje. Start med telefonen fråkopla og VPN-en tilkopla. Kopla til telefonen med Personleg hotspot slått av, vent til Nettverk-lista har stabilisert seg, og køyr rutespørjinga igjen. Kopla frå, slå på Personleg hotspot, kopla til igjen, og gjenta. Skriv ned grensesnitt, gateway og klientfeil for kvar av dei tre tilstandane, og du har ei samanlikning i staden for ei minning.

Viss VPN-en berre feilar i hotspot-tilstanden, hald telefonen unna den vegen: slå av Personleg hotspot under lading, eller flytt iPhone USB-tenesta ned under Wi-Fi i tenesterekkjefølgja. Viss han feilar i alle tilkopla tilstandar, også med hotspoten slått av, sjå på korleis klienten handterer ein nettverksovergang. Nokre klientar riv ned tunnelen når den primære tenesta endrar seg og treng ein ny tilkopling; det er klientåtferd, ikkje ein telefonfeil.

Endre éin ting per forsøk. Sletting av tenesta, tilbakestilling av VPN-konfigurasjonen og reinstallering av klienten i same minutt lèt deg sitje att med ein Mac som verkar og inga aning om kva handling som fiksa det.

Steg 5: Bestem kva du vil halde på og kva du vil stadfeste

Lat einingkoplinga vere i fred. Å fjerne eit grensesnitt som Xcode brukar rettar ikkje ei VPN-rute, og det bryt einingsdistribusjon til neste tilkopling. Viss hotspot-tenesta verkeleg er uønskt, slå først av Personleg hotspot på telefonen; det er den dokumenterte kontrollen, og han overlever ein omstart.

Viss du likevel fjernar ei teneste, fjern den du identifiserte, og stadfest deretter to ting: ruta til VPN-endepunktet er tilbake på det venta grensesnittet, og tunnelen fører trafikk til ei intern adresse, ikkje berre til internett. Noter tenesterekkjefølgja og klientversjonen, fordi ei macOS-oppdatering kan endre korleis telefonen blir vist.

Klassifiser så feilen du faktisk såg. Ein handshake-timeout, eit MTU-stopp etter at tunnelen er oppe, og DNS-svar som kjem frå operatøren er tre ulike problem med tre ulike rettingar. USB-tenesta er utløysaren i alle tre; ho er sjeldan årsaka.