Kial la VPN sur via Mac falas, kiam vi konektas iPhone per USB

Vi konektas iPhone por ŝargi ĝin, kaj post unu minuto la VPN sur via Mac ĉesas pasigi trafikon. Sistemaj Agordoj montras novan servon nomatan iPhone USB, kaj la evidenta movo estas forigi ĝin. Tiu movo ofte malĝustas. La servo povas esti la Persona Poŝa Retpunkto de la telefono, aŭ povas esti ligilo, kiun Xcode kaj aparataj iloj uzas por paroli kun la telefono, kaj la du kondutas sufiĉe malsame por ke identigo venu antaŭ forigo.

Paŝo 1: Legu la servon, kiun la telefono efektive kreis

Malfermu Sistemajn Agordojn, poste Reton, kaj komparu la servoliston kun la telefono malkonektita kaj konektita. En la nuna macOS la servo aperas kiel iPhone USB. Rimarku, ĉu ĝi estas aktiva, kie ĝi staras en la serva ordo, kaj ĉu la Mac uzas ĝin por la implicita itinero. La serva ordo gravas, ĉar macOS elektas la plej altan aktivan servon, kiu povas atingi celon, ne tiun, kies nomon vi rekonas.

La gvidilo de Apple pri la Persona Poŝa Retpunkto priskribas la mekanismon: dum la Persona Poŝa Retpunkto estas ŝaltita en la telefono, konektado per USB povas igi la Mac uzi la poŝtelefonan ligon de la telefono, eĉ kiam vi volis nur ŝargi. Tio ne estas cimo de la VPN-kliento; la itinera tabelo sekvas servon, kiu leviĝis antaŭ Wi-Fi.

Se la servo ekzistas sed restas neaktiva kun la telefono konektita, vi plej verŝajne vidas nur-ŝargan ligon aŭ aparatan ligilon, ne hotspotan. Konservu tiun distingon, ĉar la sekvaj du paŝoj testas ĝin anstataŭ diveni el la piktogramo.

Paŝo 2: Kontrolu, kiun itineron uzas la VPN-finpunkto

Legu la itineron al la solvita adreso de la VPN-servilo, ne al retejo. route -n get estas nurlegebla kaj presas la interfacon kaj enirejon, kiujn la kerno uzus, kaj ambaŭ linioj gravas.

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

La adreso supre estas anstataŭilo por dokumentado. Anstataŭigu ĝin per la finpunkto, kiun montras via kliento, kaj uzu route -n get -inet6 por IPv6-finpunkto. Komparu la eligon kun la telefono malkonektita kaj konektita, kaj ne aldonu nek forigu itinerojn inter la du legadoj. Se la interfaco ŝanĝiĝas de en0 al la iPhone USB-interfaco, la hotspot-itinero gajnis la serĉon kaj la ekstera ligo de la VPN nun iras sur la poŝtelefona reto.

Itinera ŝanĝo ne klarigas ĉiun malsukceson. La kliento ankoraŭ povas atingi la servilon kaj malsukcesi poste sur la interna trafiko de la tunelo, ĉar la nova vojo havas alian MTU aŭ la operatoro blokas la protokolon. Legu la propran eraron de la kliento antaŭ ol ŝanĝi ion: ekstera manprema tempolimo indikas atingeblon, dum establita tunelo, kiu ĉesas pasigi trafikon, indikas MTU, DNS aŭ politikon.

Paŝo 3: Apartigu hotspotan de aparata komunikiga ligilo

Xcode 15 kaj pli novaj parolas kun per USB konektita aparato per retbaza kanalo, kiu inkluzivas ligo-lokan IPv6, do evoluiga Mac povas montri plian interfacon, kiu rilatas al nenio pri interreta aliro. La teknika noto TN3158 de Apple dokumentas tiun konduton kaj avertas, ke VPN aŭ sekureca filtrado povas malhelpi ĝin. Tio estas la malo de la hotspot-problemo: la VPN ne rompiĝas ĉar la telefono proponas interreton; la aparata ligo rompiĝas ĉar la VPN kaptas ĝin.

Du observoj apartigas la kazojn sen paketkaptado. Unue, kontrolu, ĉu la interfaco havas itinereblan adreson kaj implicitan itineron, aŭ nur ligo-lokan adreson fe80::; nur ligo-loka signifas, ke ne estas interreta vojo. Due, malŝaltu la VPN kaj vidu, ĉu Xcode povas denove atingi la aparaton. Se jes, la itineroj aŭ la enhavofiltro de la VPN kaptas la ligo-lokan trafikon, kaj la korekto apartenas al la agordo de dividita tunelo aŭ filtro, ne al la Reta panelo.

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

Ne juĝu nur laŭ la interfaca nomo. macOS kreas kaj detruas ĉi tiujn interfacojn laŭ la konektado de aparatoj, kaj la en-numero estas atribuata dum plenumo, do la sama Mac povas montri alian numeron post restartiĝo aŭ kabla ŝanĝo.

Paŝo 4: Reproduktu la malsukceson per unu variablo samtempe

Kiam vi scias, kiu servo estas implikita, reproduktu la problemon en fiksa ordo. Komencu kun la telefono malkonektita kaj la VPN konektita. Konektu la telefonon kun la Persona Poŝa Retpunkto malŝaltita, atendu, ke la Reta listo stabiliĝos, kaj rulu la itinera demando denove. Malkonektu, ŝaltu la Personan Poŝan Retpunkton, konektu denove, kaj ripetu. Notu la interfacon, la enirejon kaj la klientan eraron por ĉiu el la tri statoj, kaj vi havas komparon anstataŭ memoron.

Se la VPN malsukcesas nur en la hotspot-stato, tenu la telefonon for de tiu vojo: malŝaltu la Personan Poŝan Retpunkton dum ŝargado, aŭ movu la servon iPhone USB sub Wi-Fi en la serva ordo. Se ĝi malsukcesas en ĉiu konektita stato, ankaŭ kun la hotspot malŝaltita, rigardu, kiel la kliento traktas retan transiron. Iuj klientoj malkonstruas la tunelon, kiam la ĉefa servo ŝanĝiĝas, kaj bezonas rekonon; tio estas klienta konduto, ne telefono-difekto.

Ŝanĝu unu aferon por provo. Forigi la servon, restarigi la VPN-agordon kaj reinstali la klienton en la sama minuto lasas vin kun funkcianta Mac kaj neniu ideo, kiu ago ĝin riparis.

Paŝo 5: Decidu, kion konservi kaj kion kontroli

Lasu la aparatan ligilon trankvila. Forigi interfacon, kiun Xcode uzas, ne riparas VPN-itinerojn, kaj ĝi rompas aparatan disponigon ĝis la sekva konekto. Se la hotspot-servo vere maldeziratas, unue malŝaltu la Personan Poŝan Retpunkton en la telefono; tio estas la dokumentita regilo kaj ĝi postvivas restartigon.

Se vi tamen forigos servon, forigu tiun, kiun vi identigis, kaj poste kontrolu du aferojn: la itinero al la VPN-finpunkto estas denove sur la atendata interfaco, kaj la tunelo pasigas trafikon al interna adreso, ne nur al la interreto. Notu la servan ordon kaj la klientan version, ĉar ĝisdatigo de macOS povas ŝanĝi, kiel la telefono aperas.

Poste klasifiku la malsukceson, kiun vi efektive vidis. Manprema tempolimo, MTU-halto post kiam la tunelo leviĝis, kaj DNS-respondoj venantaj de la operatoro estas tri malsamaj problemoj kun tri malsamaj korektoj. La USB-servo estas la ellasaĵo en ĉiuj tri; ĝi malofte estas la kaŭzo.