Varför VPN:en på Macen tappar kopplingen när du ansluter en iPhone via USB

Du ansluter en iPhone för att ladda den, och en minut senare slutar VPN:en på din Mac att föra vidare trafik. Systeminställningar visar en ny tjänst som heter iPhone USB, och det uppenbara greppet är att radera den. Det greppet är ofta fel. Tjänsten kan vara telefonens Personliga hotspot, eller en länk som Xcode och enhetsverktyg använder för att prata med telefonen, och de två beter sig tillräckligt olika för att identifiering måste komma före raderingen.

Steg 1: Läs tjänsten som telefonen faktiskt skapade

Öppna Systeminställningar, sedan Nätverk, och jämför tjänstelistan med telefonen frånkopplad och ansluten. I nuvarande macOS listas tjänsten som iPhone USB. Notera om den är aktiv, var den står i tjänsteordningen och om Macen använder den för standardrutten. Tjänsteordningen spelar roll eftersom macOS väljer den högsta aktiva tjänsten som kan nå en destination, inte den vars namn du känner igen.

Apples vägledning för Personlig hotspot beskriver mekanismen: så länge Personlig hotspot är påslagen på telefonen kan en USB-anslutning få Macen att använda telefonens mobilanslutning, även när du bara ville ladda. Det är inte ett fel i VPN-klienten; rutttabellen följer en tjänst som kom upp före Wi-Fi.

Om tjänsten finns men förblir inaktiv med telefonen ansluten ser du sannolikt en ren laddningsanslutning eller en enhetslänk, inte en hotspot. Behåll den skillnaden, eftersom de två nästa stegen testar den i stället för att gissa från ikonen.

Steg 2: Kontrollera vilken rutt VPN-slutpunkten använder

Läs rutten till VPN-serverns uppslagna adress, inte till en webbplats. route -n get är skrivskyddat och skriver ut gränssnittet och gatewayen som kärnan skulle använda, och båda raderna spelar roll.

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

Adressen ovan är en platshållare för dokumentation. Byt ut den mot slutpunkten som din klient visar och använd route -n get -inet6 för en IPv6-slutpunkt. Jämför utdata med telefonen frånkopplad och ansluten, och lägg inte till eller ta bort rutter mellan de två avläsningarna. Om gränssnittet byts från en0 till iPhone USB-gränssnittet vann hotspot-rutten uppslaget och VPN:ens yttre anslutning går nu över mobilnätet.

En ruttändring förklarar inte varje fel. Klienten kan fortfarande nå servern och misslyckas senare med tunnelns inre trafik, eftersom den nya vägen har en annan MTU eller operatören blockerar protokollet. Läs klientens eget fel innan du ändrar något: en yttre handskakningstimeout pekar på nåbarhet, medan en etablerad tunnel som slutar föra trafik pekar på MTU, DNS eller policy.

Steg 3: Skilj en hotspot från en enhetskommunikationslänk

Xcode 15 och senare pratar med en USB-ansluten enhet över en nätverksbaserad kanal som inkluderar link-local IPv6, så en utvecklar-Mac kan visa ett extra gränssnitt som inte har något med internetåtkomst att göra. Apples tekniska anteckning TN3158 dokumenterar det beteendet och varnar för att VPN eller säkerhetsfiltrering kan störa det. Det är motsatsen till hotspot-problemet: VPN:en går inte sönder för att telefonen erbjuder internet; enhetsanslutningen går sönder för att VPN:en fångar den.

Två observationer skiljer fallen utan paketfångst. Först, kontrollera om gränssnittet har en rutbar adress och en standardrutt, eller bara en link-local fe80::-adress; bara link-local betyder att det inte finns någon internetväg. Sedan, stäng VPN:en och se om Xcode når enheten igen. Om den gör det fångar VPN:ens rutter eller innehållsfilter den link-lokala trafiken, och rättelsen hör i konfigurationen för delad tunnel eller filter, inte i Nätverk-panelen.

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

Döm inte bara efter gränssnittets namn. macOS skapar och förstör dessa gränssnitt när enheter ansluts, och en-numret tilldelas vid körning, så samma Mac kan visa ett annat nummer efter en omstart eller ett kabelbyte.

Steg 4: Reproducera felet med en variabel i taget

När du vet vilken tjänst som är inblandad, återskapa problemet i fast ordning. Börja med telefonen frånkopplad och VPN:en ansluten. Anslut telefonen med Personlig hotspot avstängd, vänta tills Nätverk-listan har stabiliserats och kör ruttfrågan igen. Koppla från, slå på Personlig hotspot, anslut igen och upprepa. Skriv ner gränssnitt, gateway och klientfel för var och en av de tre tillstånden, och du har en jämförelse i stället för ett minne.

Om VPN:en bara fallerar i hotspot-läget, håll telefonen borta från den vägen: stäng av Personlig hotspot under laddning, eller flytta tjänsten iPhone USB nedanför Wi-Fi i tjänsteordningen. Om den fallerar i varje anslutet tillstånd, även med hotspoten avstängd, titta på hur klienten hanterar en nätverksväxling. Vissa klienter river tunneln när den primära tjänsten ändras och behöver återansluta; det är klientbeteende, inte ett telefonfel.

Ändra en sak per försök. Att radera tjänsten, återställa VPN-konfigurationen och installera om klienten i samma minut lämnar dig med en Mac som fungerar och ingen aning om vilken åtgärd som lagade det.

Steg 5: Bestäm vad du behåller och vad du verifierar

Låt enhetslänken vara i fred. Att ta bort ett gränssnitt som Xcode använder lagar inte en VPN-rutt, och det bryter enhetsdistributionen till nästa anslutning. Om hotspot-tjänsten verkligen är oönskad, stäng först av Personlig hotspot på telefonen; det är den dokumenterade kontrollen och den överlever en omstart.

Om du ändå tar bort en tjänst, ta bort den du identifierade och verifiera sedan två saker: rutten till VPN-slutpunkten är tillbaka på det förväntade gränssnittet, och tunneln för vidare trafik till en intern adress, inte bara till internet. Notera tjänsteordningen och klientversionen, eftersom en macOS-uppdatering kan ändra hur telefonen visas.

Klassificera sedan felet du faktiskt såg. En handskakningstimeout, ett MTU-stopp efter att tunneln kommit upp och DNS-svar som kommer från operatören är tre olika problem med tre olika rättelser. USB-tjänsten är utlösaren i alla tre; orsaken är den sällan.