Hvorfor VPN-en på Macen faller ut når du kobler til en iPhone via USB

Du kobler til en iPhone for å lade den, og et minutt senere slutter VPN-en på Macen å føre trafikk. Systeminnstillinger viser en ny tjeneste som heter iPhone USB, og det åpenbare trekket er å slette den. Det trekket er ofte feil. Tjenesten kan være telefonens Personlig hotspot, eller den kan være en kobling som Xcode og enhetsverktøy bruker for å snakke med telefonen, og de to oppfører seg forskjellig nok til at identifikasjon må komme før sletting.

Trinn 1: Les tjenesten telefonen faktisk opprettet

Åpne Systeminnstillinger, deretter Nettverk, og sammenlign tjenestelisten med telefonen frakoblet og tilkoblet. På gjeldende macOS vises tjenesten som iPhone USB. Legg merke til om den er aktiv, hvor den står i tjenesterekkefølgen, og om Macen bruker den til standardruten. Tjenesterekkefølgen betyr noe fordi macOS velger den høyeste aktive tjenesten som kan nå en destinasjon, ikke den du kjenner navnet på.

Apples veiledning for Personlig hotspot beskriver mekanismen: så lenge Personlig hotspot er slått på på telefonen, kan en USB-tilkobling få Macen til å bruke telefonens mobilforbindelse, selv når du bare ville lade. Det er ikke en feil i VPN-klienten; rutetabellen følger en tjeneste som kom opp før Wi-Fi.

Hvis tjenesten finnes, men forblir inaktiv med telefonen tilkoblet, ser du sannsynligvis en ren ladekobling eller en enhetskobling, ikke en hotspot. Behold den forskjellen, fordi de neste to trinnene tester den i stedet for å gjette ut fra ikonet.

Trinn 2: Sjekk hvilken rute VPN-endepunktet bruker

Les ruten til VPN-serverens oppslåtte adresse, ikke til et nettsted. route -n get er skrivebeskyttet og skriver ut grensesnittet og gatewayen kjernen ville brukt, og begge linjene betyr noe.

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

Adressen ovenfor er en plassholder for dokumentasjon. Erstatt den med endepunktet klienten din viser, og bruk route -n get -inet6 for et IPv6-endepunkt. Sammenlign utdataene med telefonen frakoblet og tilkoblet, og ikke legg til eller fjern ruter mellom de to lesningene. Hvis grensesnittet endres fra en0 til iPhone USB-grensesnittet, vant hotspot-ruten oppslaget og VPN-ens ytre forbindelse går nå over mobilnettet.

En ruteendring forklarer ikke alle feil. Klienten kan fortsatt nå serveren og feile senere på tunnelens indre trafikk, fordi den nye veien har en annen MTU eller operatøren blokkerer protokollen. Les klientens egen feil før du endrer noe: en ytre handshake-timeout peker på tilgjengelighet, mens en etablert tunnel som slutter å føre trafikk peker på MTU, DNS eller policy.

Trinn 3: Skill en hotspot fra en enhetskommunikasjonskobling

Xcode 15 og nyere snakker med en USB-tilkoblet enhet over en nettverksbasert kanal som inkluderer link-lokal IPv6, så en utvikler-Mac kan vise et ekstra grensesnitt som ikke har noe med internettilgang å gjøre. Apples tekniske notat TN3158 dokumenterer denne oppførselen og advarer om at VPN eller sikkerhetsfiltrering kan forstyrre den. Dette er det motsatte av hotspot-problemet: VPN-en bryter ikke fordi telefonen tilbyr internett; enhetskoblingen bryter fordi VPN-en fanger den.

To observasjoner skiller tilfellene uten pakkefangst. Først, sjekk om grensesnittet har en rutbar adresse og en standardrute, eller bare en link-lokal fe80:: adresse; bare link-lokal betyr at det ikke finnes noen internettvei. For det andre, avslutt VPN-en og se om Xcode når enheten igjen. Hvis den gjør det, fanger VPN-ens ruter eller innholdsfilter den link-lokale trafikken, og rettelsen hører i konfigurasjonen for delt tunnel eller filter, ikke i Nettverk-panelet.

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

Ikke døm etter grensesnittnavnet alene. macOS oppretter og ødelegger disse grensesnittene etter hvert som enheter kobles til, og en-nummeret tildeles ved kjøring, så samme Mac kan vise et annet nummer etter en omstart eller et kabelbytte.

Trinn 4: Gjenskap feilen med én variabel om gangen

Når du vet hvilken tjeneste som er involvert, gjenskap problemet i fast rekkefølge. Start med telefonen frakoblet og VPN-en tilkoblet. Koble til telefonen med Personlig hotspot slått av, vent til Nettverk-listen har stabilisert seg, og kjør rutespørringen igjen. Koble fra, slå på Personlig hotspot, koble til igjen, og gjenta. Skriv ned grensesnitt, gateway og klientfeil for hver av de tre tilstandene, og du har en sammenligning i stedet for en erindring.

Hvis VPN-en bare feiler i hotspot-tilstanden, hold telefonen unna den veien: slå av Personlig hotspot under lading, eller flytt iPhone USB-tjenesten ned under Wi-Fi i tjenesterekkefølgen. Hvis den feiler i alle tilkoblede tilstander, også med hotspoten slått av, se på hvordan klienten håndterer en nettverksovergang. Noen klienter river ned tunnelen når den primære tjenesten endres og trenger en ny tilkobling; det er klientatferd, ikke en telefonfeil.

Endre én ting per forsøk. Sletting av tjenesten, tilbakestilling av VPN-konfigurasjonen og reinstallasjon av klienten i samme minutt etterlater deg med en Mac som virker og ingen anelse om hvilken handling som fikset det.

Trinn 5: Bestem hva du vil beholde og hva du vil verifisere

La enhetskoblingen være i fred. Å fjerne et grensesnitt som Xcode bruker retter ikke en VPN-rute, og det bryter enhetsdistribusjon til neste tilkobling. Hvis hotspot-tjenesten virkelig er uønsket, slå først av Personlig hotspot på telefonen; det er den dokumenterte kontrollen, og den overlever en omstart.

Hvis du likevel fjerner en tjeneste, fjern den du identifiserte, og verifiser deretter to ting: ruten til VPN-endepunktet er tilbake på det forventede grensesnittet, og tunnelen fører trafikk til en intern adresse, ikke bare til internett. Noter tjenesterekkefølgen og klientversjonen, fordi en macOS-oppdatering kan endre hvordan telefonen vises.

Klassifiser så feilen du faktisk så. En handshake-timeout, et MTU-stopp etter at tunnelen er oppe, og DNS-svar som kommer fra operatøren er tre forskjellige problemer med tre forskjellige rettelser. USB-tjenesten er utløseren i alle tre; den er sjelden årsaken.