Waarom jou Mac se VPN onderbreek wanneer jy ’n iPhone per USB aansluit

Jy sluit ’n iPhone aan om dit te laai, en ’n minuut later hou die VPN op jou Mac op om verkeer deur te laat. Stelselinstellings wys ’n nuwe diens genaamd iPhone USB, en die ooglopende stap is om dit uit te vee. Dié stap is dikwels verkeerd. Die diens kan die foon se Persoonlike Hotspot wees, of dit kan ’n koppeling wees wat Xcode en toestelgereedskap gebruik om met die foon te praat, en die twee tree verskillend genoeg op dat identifisering voor uitvee moet kom.

Stap 1: Lees die diens wat die foon werklik geskep het

Maak Stelselinstellings oop, dan Netwerk, en vergelyk die dienslys met die foon afgekoppel en aangekoppel. Op die huidige macOS word die diens as iPhone USB gelys. Let op of dit aktief is, waar dit in die diensorde staan, en of die Mac dit vir die verstekroete gebruik. Die diensorde maak saak, want macOS kies die hoogste aktiewe diens wat ’n bestemming kan bereik, nie die een wie se naam jy herken nie.

Apple se Persoonlike Hotspot-riglyne beskryf die meganisme: terwyl Persoonlike Hotspot op die foon geaktiveer is, kan die koppeling per USB die Mac die foon se sellulêre verbinding laat gebruik, selfs wanneer jy net wou laai. Dit is nie ’n fout in die VPN-kliënt nie; die roetertabel volg ’n diens wat voor Wi-Fi opgekom het.

As die diens bestaan maar onaktief bly met die foon aangekoppel, kyk jy heel waarskynlik na ’n laai-alleen-verbinding of ’n toestelkoppeling eerder as ’n hotspot. Hou daardie onderskeid, want die volgende twee stappe toets dit in plaas daarvan om uit die ikoon te raai.

Stap 2: Kyk watter roete die VPN-eindpunt gebruik

Lees die roete na die VPN-bediener se opgeloste adres, nie na ’n webwerf nie. route -n get is net-lees en druk die koppelvlak en poort wat die kern sou gebruik, en albei reëls maak saak.

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

Die adres hierbo is ’n dokumentasie-plekhouer. Vervang dit met die eindpunt wat jou kliënt wys, en gebruik route -n get -inet6 vir ’n IPv6-eindpunt. Vergelyk die uitvoer met die foon afgekoppel en aangekoppel, en moenie roetes tussen die twee lesings byvoeg of verwyder nie. As die koppelvlak van en0 na die iPhone USB-koppelvlak verander, het die hotspot-pad die opsoek gewen en ry die VPN se buitenste verbinding nou op sellulêr.

’n Roeteverandering verduidelik nie elke mislukking nie. Die kliënt kan die bediener steeds bereik en later misluk op die tonnel se binneste verkeer, omdat die nuwe pad ’n ander MTU het of die operateur die protokol blokkeer. Lees die kliënt se eie fout voordat jy enigiets verander: ’n buitenste handdruk-tydsverloop dui op bereikbaarheid, terwyl ’n gevestigde tonnel wat ophou verkeer deurlaat op MTU, DNS of beleid dui.

Stap 3: Skei ’n hotspot van ’n toestel-kommunikasiekoppeling

Xcode 15 en later praat met ’n USB-aangekoppelde toestel oor ’n netwerkgebaseerde kanaal wat skakel-plaaslike IPv6 insluit, so ’n ontwikkel-Mac kan ’n ekstra koppelvlak wys wat niks met internettoegang te doen het nie. Apple se TN3158-tegniese nota dokumenteer daardie gedrag en waarsku dat VPN of sekuriteitsfiltrering daarmee kan inmeng. Dit is die omgekeerde van die hotspot-probleem: die VPN breek nie omdat die foon internet bied nie; die toestelverbinding breek omdat die VPN dit vasvang.

Twee waarnemings skei die gevalle sonder ’n pakkievaslegging. Eerstens, kyk of die koppelvlak ’n roeteerbare adres en ’n verstekroete het, of net ’n skakel-plaaslike fe80::-adres; net skakel-plaaslik beteken daar is geen internetpad nie. Tweedens, verlaat die VPN en kyk of Xcode die toestel weer kan bereik. As dit kan, vang die VPN se roetes of inhoudsfilter die skakel-plaaslike verkeer, en die regstelling hoort in die gesplete-tonnel- of filterkonfigurasie, nie in die Netwerk-paneel nie.

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

Moenie net op die koppelvlaknaam oordeel nie. macOS skep en vernietig hierdie koppelvlakke soos toestelle aankoppel, en die en-nommer word tydens looptyd toegeken, so dieselfde Mac kan ’n ander nommer wys ná ’n herbegin of ’n kabelruil.

Stap 4: Herhaal die mislukking met een veranderlike op ’n slag

Sodra jy weet watter diens betrokke is, herhaal die probleem in ’n vaste volgorde. Begin met die foon afgekoppel en die VPN gekoppel. Koppel die foon met Persoonlike Hotspot af, wag tot die Netwerk-lys stabiliseer, en voer die roetevraag weer uit. Koppel af, aktiveer Persoonlike Hotspot, koppel weer, en herhaal. Skryf die koppelvlak, poort en kliëntfout vir elk van die drie toestande neer, en jy het ’n vergelyking in plaas van ’n herinnering.

As die VPN net in die hotspot-toestand misluk, hou die foon van daardie pad af: skakel Persoonlike Hotspot af terwyl jy laai, of skuif die iPhone USB-diens onder Wi-Fi in die diensorde. As dit in elke aangekoppelde toestand misluk, ook met die hotspot af, kyk hoe die kliënt ’n netwerkoorgang hanteer. Sommige kliënte breek die tonnel af wanneer die primêre diens verander en benodig ’n herverbinding; dit is kliëntgedrag, nie ’n foonfout nie.

Verander een ding per poging. Om die diens te verwyder, die VPN-konfigurasie terug te stel en die kliënt in dieselfde minuut te herinstalleer, laat jou met ’n werkende Mac en geen idee watter aksie dit reggemaak het nie.

Stap 5: Besluit wat om te hou en wat om te verifieer

Los die toestelkoppeling alleen. Om ’n koppelvlak te verwyder wat Xcode gebruik, maak nie ’n VPN-roete reg nie, en dit breek toestelontplooiing tot die volgende aankoppeling. As die hotspot-diens werklik ongewens is, skakel Persoonlike Hotspot eers op die foon af; dit is die gedokumenteerde beheer en dit oorleef ’n herbegin.

As jy wel ’n diens verwyder, verwyder die een wat jy geïdentifiseer het en verifieer dan twee dinge: die roete na die VPN-eindpunt is terug op die verwagte koppelvlak, en die tonnel laat verkeer na ’n interne adres deur, nie net na die internet nie. Hou ’n nota van die diensorde en die kliëntweergawe, want ’n macOS-opdatering kan verander hoe die foon verskyn.

Klassifiseer dan die mislukking wat jy werklik gesien het. ’n Handdruk-tydsverloop, ’n MTU-stilstand nadat die tonnel op is, en DNS-antwoorde wat van die operateur kom, is drie verskillende probleme met drie verskillende regstellings. Die USB-diens is in al drie die sneller; dit is selde die oorsaak.