Miks Maci VPN katkeb, kui ühendad iPhone'i USB-ga

Ühendad iPhone'i laadimiseks ja minut hiljem lõpetab Maci VPN liikluse läbilaskmise. Süsteemiseaded näitavad uut teenust nimega iPhone USB ja ilmne samm on see kustutada. See samm on sageli vale. Teenus võib olla telefoni isiklik kuumkoht või link, mida Xcode ja seadme tööriistad kasutavad telefoniga suhtlemiseks, ning need kaks käituvad piisavalt erinevalt, et tuvastamine peab tulema enne kustutamist.

Samm 1: Loe teenust, mille telefon tegelikult lõi

Ava Süsteemiseaded, seejärel Võrk, ja võrdle teenuste loendit telefoniga lahti ühendatud ja ühendatud olekus. Praeguses macOS-is on teenus kirjas kui iPhone USB. Pane tähele, kas see on aktiivne, kus see teenuste järjekorras asub ja kas Mac kasutab seda vaikemarsruudi jaoks. Teenuste järjekord on oluline, sest macOS valib kõrgeima aktiivse teenuse, mis suudab sihtkohta jõuda, mitte selle, mille nime sa tunned.

Apple'i isikliku kuumkoha juhend kirjeldab mehhanismi: kui telefoni isiklik kuumkoht on lubatud, võib USB-ga ühendamine panna Maci kasutama telefoni mobiilset ühendust, isegi kui tahtsid ainult laadida. See ei ole VPN-kliendi viga; marsruutimistabel järgib teenust, mis tõusis enne Wi-Fi-t.

Kui teenus on olemas, aga jääb telefoniga ühendatud olekus mitteaktiivseks, vaatad tõenäoliselt ainult laadimise ühendust või seadmelüli, mitte kuumkohta. Hoia see erinevus alles, sest järgmised kaks sammu testivad seda, selle asemel et ikooni järgi oletada.

Samm 2: Kontrolli, millist marsruuti VPN-i lõpp-punkt kasutab

Loe marsruuti VPN-serveri lahendatud aadressini, mitte veebisaidini. route -n get on ainult lugemiseks ja trükib liidese ja lüüsi, mida kernel kasutaks, ning mõlemad read on olulised.

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

Ülaltoodud aadress on dokumentatsiooni kohatäide. Asenda see lõpp-punktiga, mida sinu klient näitab, ja kasuta route -n get -inet6 IPv6 lõpp-punkti jaoks. Võrdle väljundit telefoniga lahti ühendatud ja ühendatud olekus ning ära lisa ega eemalda marsruute kahe lugemise vahel. Kui liides muutub en0-lt iPhone USB liideseks, võitis hotspot-tee otsingu ja VPN-i välimine ühendus sõidab nüüd mobiilse võrgu peal.

Marsruudi muutus ei selgita iga tõrget. Klient võib endiselt serverini jõuda ja hiljem tunnelisisese liikluse juures ebaõnnestuda, sest uuel teel on teistsugune MTU või operaator blokeerib protokolli. Loe kliendi enda viga enne millegi muutmist: välimine kätlus-timeout viitab kättesaadavusele, samas kui püstitatud tunnel, mis lõpetab liikluse läbilaskmise, viitab MTU-le, DNS-ile või poliitikale.

Samm 3: Eralda kuumkoht seadme sidekanalist

Xcode 15 ja uuemad räägivad USB-ga ühendatud seadmega võrgupõhise kanali kaudu, mis hõlmab lokaalse lingi IPv6-t, nii et arendus-Mac võib näidata täiendavat liidest, millel pole internetiühendusega mingit pistmist. Apple'i tehniline märkus TN3158 dokumenteerib selle käitumise ja hoiatab, et VPN või turvafiltreerimine võib seda segada. See on hotspot-probleemi vastand: VPN ei lähe katki sellepärast, et telefon pakub internetti; seadmeühendus läheb katki sellepärast, et VPN püüab selle kinni.

Kaks tähelepanekut eraldavad juhtumid ilma paketipüügi. Esiteks kontrolli, kas liidesel on marsruuditav aadress ja vaikemarsruut, või ainult lokaalse lingi fe80:: aadress; ainult lokaalne link tähendab, et internetiteed pole. Teiseks sulge VPN ja vaata, kas Xcode pääseb seadmele uuesti ligi. Kui pääseb, püüavad VPN-i marsruudid või sisufilter lokaalse lingi liikluse kinni ja parandus kuulub jagatud tunneli või filtri konfiguratsiooni, mitte Võrgu paneeli.

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

Ära otsusta ainult liidese nime järgi. macOS loob ja hävitab neid liideseid seadmete ühendamisel ning en-number määratakse käitusajal, nii et sama Mac võib pärast taaskäivitust või kaabli vahetust näidata teist numbrit.

Samm 4: Korda tõrget ühe muutujaga korraga

Kui tead, milline teenus on mängus, korda probleemi kindlas järjekorras. Alusta telefoniga lahti ühendatud ja VPN-iga ühendatud olekus. Ühenda telefon isikliku kuumkohaga väljas, oota, kuni Võrgu loend rahuneb, ja käivita marsruudipäring uuesti. Ühenda lahti, luba isiklik kuumkoht, ühenda uuesti ja korda. Kirjuta üles liides, lüüs ja kliendi viga kõigi kolme oleku jaoks ning sul on võrdlus, mitte mälestus.

Kui VPN ebaõnnestub ainult kuumkoha olekus, hoia telefon sellest teest eemal: lülita laadimise ajal isiklik kuumkoht välja või vii iPhone USB teenus teenuste järjekorras Wi-Fi alla. Kui see ebaõnnestub igas ühendatud olekus, ka kuumkoha väljalülitamisega, vaata, kuidas klient võrguüleminekut käsitleb. Mõned kliendid lammutavad tunneli, kui esmane teenus muutub, ja vajavad taasühendust; see on kliendi käitumine, mitte telefoni viga.

Muuda iga katse kohta ühte asja. Teenuse kustutamine, VPN-i konfiguratsiooni lähtestamine ja kliendi uuesti paigaldamine samal minutil jätavad sulle töötava Maci ja ei mingit aimu, milline tegevus selle korda tegi.

Samm 5: Otsusta, mida hoida ja mida kontrollida

Jäta seadmelüli rahule. Liidese eemaldamine, mida Xcode kasutab, ei paranda VPN-i marsruuti ja rikub seadmetesse juurutamise kuni järgmise ühendamiseni. Kui kuumkoha teenus on tõesti soovimatu, lülita esmalt telefonis isiklik kuumkoht välja; see on dokumenteeritud juhtelement ja see jääb taaskäivituse järel püsima.

Kui teenuse siiski eemaldad, eemalda see, mille tuvastasid, ja kontrolli seejärel kahte asja: marsruut VPN-i lõpp-punktini on tagasi oodatud liidesel ja tunnel laseb liiklust läbi sisemisele aadressile, mitte ainult internetti. Märgi üles teenuste järjekord ja kliendi versioon, sest macOS-i värskendus võib muuta seda, kuidas telefon paistab.

Seejärel liigita tõrge, mida sa tegelikult nägid. Kätlus-timeout, MTU seiskumine pärast tunneli püstitamist ja operaatorilt tulevad DNS-vastused on kolm erinevat probleemi kolme erineva parandusega. USB-teenus on kõigis kolmes päästik; põhjus on see harva.