Waarom de VPN op je Mac wegvalt als je een iPhone via USB aansluit

Je sluit een iPhone aan om hem op te laten laden, en een minuut later houdt de VPN op je Mac op verkeer door te laten. Systeeminstellingen tonen een nieuwe dienst met de naam iPhone USB, en de voor de hand liggende stap is die verwijderen. Die stap is vaak verkeerd. De dienst kan de Persoonlijke hotspot van de telefoon zijn, of een koppeling die Xcode en apparaatgereedschap gebruiken om met de telefoon te praten, en die twee gedragen zich dusdanig anders dat identificatie vóór verwijdering moet komen.

Stap 1: Lees de dienst die de telefoon werkelijk heeft aangemaakt

Open Systeeminstellingen en dan Netwerk, en vergelijk de lijst met diensten met de telefoon losgekoppeld en aangesloten. Op het huidige macOS staat de dienst als iPhone USB. Let op of hij actief is, waar hij in de dienstvolgorde staat en of de Mac hem voor de standaardroute gebruikt. De dienstvolgorde is belangrijk omdat macOS de hoogste actieve dienst kiest die een bestemming kan bereiken, niet die waarvan je de naam herkent.

Apple's handleiding voor de Persoonlijke hotspot beschrijft het mechanisme: zolang de Persoonlijke hotspot op de telefoon is ingeschakeld, kan aansluiten via USB de Mac de mobiele verbinding van de telefoon laten gebruiken, ook als je alleen wilde opladen. Dat is geen fout in de VPN-client; de routetabel volgt een dienst die vóór de Wi-Fi omhoogkwam.

Als de dienst bestaat maar inactief blijft terwijl de telefoon is aangesloten, kijk je hoogstwaarschijnlijk naar een alleen-opladen-verbinding of een apparaatkoppeling, niet naar een hotspot. Houd dat onderscheid vast, want de volgende twee stappen testen het in plaats van het uit het pictogram te raden.

Stap 2: Controleer welke route het VPN-eindpunt gebruikt

Lees de route naar het opgeloste adres van de VPN-server, niet naar een website. route -n get is alleen-lezen en drukt de interface en gateway af die de kernel zou gebruiken, en beide regels tellen.

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

Het adres hierboven is een plaatsvervanger voor documentatie. Vervang het door het eindpunt dat je client toont, en gebruik route -n get -inet6 voor een IPv6-eindpunt. Vergelijk de uitvoer met de telefoon losgekoppeld en aangesloten, en voeg geen routes toe en verwijder ze niet tussen de twee metingen. Als de interface verandert van en0 naar de iPhone USB-interface, heeft de hotspot-route de opzoeking gewonnen en loopt de buitenste verbinding van de VPN nu over mobiel.

Een routewijziging verklaart niet elke storing. De client kan de server nog bereiken en later falen op het binnenste verkeer van de tunnel, omdat het nieuwe pad een andere MTU heeft of de provider het protocol blokkeert. Lees de eigen fout van de client voordat je iets verandert: een uitwendige handshake-timeout wijst op bereikbaarheid, terwijl een opgezette tunnel die geen verkeer meer doorlaat op MTU, DNS of beleid wijst.

Stap 3: Scheid een hotspot van een apparaatcommunicatiekoppeling

Xcode 15 en nieuwer praten met een via USB aangesloten apparaat over een netwerkgebaseerd kanaal dat link-local IPv6 omvat, dus een ontwikkel-Mac kan een extra interface tonen die niets met internettoegang te maken heeft. Apple's technische notitie TN3158 documenteert dat gedrag en waarschuwt dat VPN of beveiligingsfiltering erin kan grijpen. Dit is het omgekeerde van het hotspot-probleem: de VPN breekt niet omdat de telefoon internet biedt; de apparaatverbinding breekt omdat de VPN hem onderschept.

Twee waarnemingen scheiden de gevallen zonder packet capture. Ten eerste: controleer of de interface een routeerbaar adres en een standaardroute heeft, of alleen een link-local fe80::-adres; alleen link-local betekent dat er geen internetpad is. Ten tweede: sluit de VPN af en kijk of Xcode het apparaat weer bereikt. Als dat lukt, onderscheppen de routes of het inhoudsfilter van de VPN het link-local verkeer, en de oplossing hoort in de configuratie van de split-tunnel of het filter, niet in het paneel Netwerk.

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

Oordeel niet alleen op de interfacenaam. macOS maakt en vernietigt deze interfaces terwijl apparaten worden aangesloten, en het en-nummer wordt tijdens het draaien toegewezen, dus dezelfde Mac kan na een herstart of kabelwissel een ander nummer tonen.

Stap 4: Reproduceer de storing met één variabele tegelijk

Als je weet welke dienst erbij betrokken is, reproduceer het probleem in een vaste volgorde. Begin met de telefoon losgekoppeld en de VPN verbonden. Sluit de telefoon aan met de Persoonlijke hotspot uit, wacht tot de lijst Netwerk tot rust is gekomen en voer de routeopvraag opnieuw uit. Koppel los, zet de Persoonlijke hotspot aan, sluit weer aan en herhaal. Schrijf de interface, de gateway en de clientfout op voor elk van de drie toestanden, en je hebt een vergelijking in plaats van een herinnering.

Als de VPN alleen in de hotspot-toestand faalt, houd de telefoon dan van dat pad af: zet de Persoonlijke hotspot uit tijdens het opladen, of verplaats de dienst iPhone USB in de dienstvolgorde onder de Wi-Fi. Als hij in elke aangesloten toestand faalt, ook met de hotspot uit, kijk dan hoe de client een netwerkovergang afhandelt. Sommige clients breken de tunnel af wanneer de primaire dienst verandert en vragen om opnieuw verbinden; dat is clientgedrag, geen telefoonfout.

Verander één ding per poging. De dienst verwijderen, de VPN-configuratie resetten en de client in dezelfde minuut opnieuw installeren laten je achter met een werkende Mac en geen idee welke actie het heeft opgelost.

Stap 5: Bepaal wat je houdt en wat je verifieert

Laat de apparaatkoppeling met rust. Een interface verwijderen die Xcode gebruikt lost geen VPN-route op, en het breekt de uitrol naar apparaten tot de volgende aansluiting. Als de hotspot-dienst echt ongewenst is, zet dan eerst de Persoonlijke hotspot op de telefoon uit; dat is de gedocumenteerde regeling en die overleeft een herstart.

Als je toch een dienst verwijdert, verwijder dan degene die je hebt geïdentificeerd en verifieer daarna twee dingen: de route naar het VPN-eindpunt staat weer op de verwachte interface, en de tunnel laat verkeer door naar een intern adres, niet alleen naar het internet. Noteer de dienstvolgorde en de clientversie, want een macOS-update kan veranderen hoe de telefoon verschijnt.

Classificeer daarna de storing die je werkelijk zag. Een handshake-timeout, een MTU-stilstand nadat de tunnel omhoog is en DNS-antwoorden die van de provider komen zijn drie verschillende problemen met drie verschillende oplossingen. De USB-dienst is in alle drie de trigger; de oorzaak is hij zelden.