Kāpēc Mac VPN pārtrūkst, kad iPhone pievieno ar USB

Jūs pievienojat iPhone uzlādei, un pēc minūtes VPN Mac datorā pārstāj laist cauri datu plūsmu. Sistēmas iestatījumi rāda jaunu pakalpojumu ar nosaukumu iPhone USB, un acīmredzamais solis ir to dzēst. Šis solis bieži ir nepareizs. Pakalpojums var būt tālruņa Personīgais hotspot vai saite, ko Xcode un ierīču rīki izmanto saziņai ar tālruni, un abi uzvedas pietiekami atšķirīgi, lai identificēšana būtu pirms dzēšanas.

1. solis: Izlasiet pakalpojumu, ko tālrunis patiešām izveidoja

Atveriet Sistēmas iestatījumus, pēc tam Tīklu, un salīdziniet pakalpojumu sarakstu ar tālruni atvienotu un pievienotu. Pašreizējā macOS pakalpojums ir norādīts kā iPhone USB. Ievērojiet, vai tas ir aktīvs, kur tas atrodas pakalpojumu secībā un vai Mac to izmanto noklusējuma maršrutam. Pakalpojumu secība ir svarīga, jo macOS izvēlas augstāko aktīvo pakalpojumu, kas var sasniegt galamērķi, nevis to, kura nosaukumu atpazīstat.

Apple vadlīnijas par Personīgo hotspot apraksta mehānismu: kamēr tālrunī ir ieslēgts Personīgais hotspots, tā pievienošana ar USB var likt Mac izmantot tālruņa mobilo savienojumu, pat ja gribējāt tikai uzlādēt. Tā nav VPN klienta kļūda; maršrutu tabula seko pakalpojumam, kas pacēlās pirms Wi-Fi.

Ja pakalpojums pastāv, bet paliek neaktīvs ar pievienotu tālruni, jūs, visticamāk, redzat tikai uzlādes savienojumu vai ierīces saiti, nevis hotspot. Saglabājiet šo atšķirību, jo nākamie divi soļi to pārbauda, nevis min no ikonas.

2. solis: Pārbaudiet, kādu maršrutu izmanto VPN galapunkts

Lasiet maršrutu uz atrisināto VPN servera adresi, nevis uz vietni. route -n get ir tikai lasāma un izdrukā saskarni un vārteju, ko izmantotu kodols, un abas rindas ir svarīgas.

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

Iepriekš minētā adrese ir dokumentācijas vietturis. Aizstājiet to ar galapunktu, ko rāda jūsu klients, un IPv6 galapunktam izmantojiet route -n get -inet6. Salīdziniet izvadi ar tālruni atvienotu un pievienotu, un nepievienojiet un nenoņemiet maršrutus starp abiem nolasījumiem. Ja saskarne mainās no en0 uz iPhone USB saskarni, hotspot ceļš uzvarēja meklēšanā, un VPN ārējais savienojums tagad iet pa mobilo tīklu.

Maršruta maiņa neizskaidro visas neveiksmes. Klients joprojām var sasniegt serveri un vēlāk neizdoties tuneļa iekšējā plūsmā, jo jaunajam ceļam ir cits MTU vai operators bloķē protokolu. Izlasiet paša klienta kļūdu pirms kaut ko mainīt: ārējais rokasspiediena taimauts norāda uz sasniedzamību, bet izveidots tunelis, kas pārstāj laist plūsmu, norāda uz MTU, DNS vai politiku.

3. solis: Atdaliet hotspotu no ierīces saziņas saites

Xcode 15 un jaunākas versijas sazinās ar USB pievienotu ierīci pa tīkla kanālu, kas ietver saites lokālo IPv6, tāpēc izstrādes Mac var rādīt papildu saskarni, kam nav nekāda sakara ar piekļuvi internetam. Apple tehniskais pieraksts TN3158 dokumentē šo uzvedību un brīdina, ka VPN vai drošības filtrēšana var tam traucēt. Šī ir hotspot problēmas pretējā puse: VPN nesabrūk tāpēc, ka tālrunis piedāvā internetu; ierīces savienojums sabrūk tāpēc, ka VPN to pārtver.

Divi novērojumi atdala gadījumus bez pakešu uztveršanas. Pirmkārt, pārbaudiet, vai saskarnei ir maršrutējama adrese un noklusējuma maršruts, vai tikai saites lokālā fe80:: adrese; tikai saites lokālā nozīmē, ka interneta ceļa nav. Otrkārt, aizveriet VPN un paskatieties, vai Xcode atkal sasniedz ierīci. Ja sasniedz, VPN maršruti vai satura filtrs pārtver saites lokālo plūsmu, un labojums pieder sadalītā tuneļa vai filtra konfigurācijai, nevis Tīkla panelim.

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

Nespriediet tikai pēc saskarnes nosaukuma. macOS veido un iznīcina šīs saskarnes, ierīcēm pievienojoties, un en numurs tiek piešķirts izpildes laikā, tāpēc tas pats Mac pēc restartēšanas vai kabeļa maiņas var rādīt citu numuru.

4. solis: Atkārtojiet neveiksmi ar vienu mainīgo vienlaikus

Kad zināt, kurš pakalpojums ir iesaistīts, atkārtojiet problēmu noteiktā secībā. Sāciet ar atvienotu tālruni un pievienotu VPN. Pievienojiet tālruni ar izslēgtu Personīgo hotspotu, nogaidiet, līdz Tīkla saraksts nostabilizējas, un atkal palaidiet maršruta vaicājumu. Atvienojiet, ieslēdziet Personīgo hotspotu, pievienojiet vēlreiz un atkārtojiet. Pierakstiet saskarni, vārteju un klienta kļūdu katram no trim stāvokļiem, un jums būs salīdzinājums, nevis atmiņa.

Ja VPN neizdodas tikai hotspot stāvoklī, turiet tālruni prom no šī ceļa: izslēdziet Personīgo hotspotu uzlādes laikā vai pārvietojiet pakalpojumu iPhone USB zem Wi-Fi pakalpojumu secībā. Ja tas neizdodas katrā pievienotā stāvoklī, arī ar izslēgtu hotspotu, apskatiet, kā klients apstrādā tīkla pāreju. Daži klienti izjauc tuneli, kad mainās primārais pakalpojums, un prasa atkārtotu savienojumu; tā ir klienta uzvedība, nevis tālruņa defekts.

Mainiet vienu lietu katrā mēģinājumā. Pakalpojuma dzēšana, VPN konfigurācijas atiestatīšana un klienta pārinstalēšana tajā pašā minūtē atstāj jūs ar strādājošu Mac un bez priekšstata, kura darbība to salaboja.

5. solis: Izlemiet, ko paturēt un ko pārbaudīt

Atstājiet ierīces saiti mierā. Tādas saskarnes noņemšana, ko izmanto Xcode, nesalabo VPN maršrutu un sabojā izvietošanu ierīcēs līdz nākamajai pievienošanai. Ja hotspot pakalpojums tiešām nav vēlams, vispirms izslēdziet Personīgo hotspotu tālrunī; tas ir dokumentētā vadība, un tā pārdzīvo restartēšanu.

Ja tomēr noņemat pakalpojumu, noņemiet to, ko identificējāt, un pēc tam pārbaudiet divas lietas: maršruts uz VPN galapunktu atkal ir gaidītajā saskarnē, un tunelis laiž plūsmu uz iekšēju adresi, ne tikai uz internetu. Pierakstiet pakalpojumu secību un klienta versiju, jo macOS atjauninājums var mainīt to, kā tālrunis parādās.

Pēc tam klasificējiet neveiksmi, ko patiešām redzējāt. Rokasspiediena taimauts, MTU apstāšanās pēc tuneļa pacelšanas un DNS atbildes no operatora ir trīs dažādas problēmas ar trim dažādiem labojumiem. USB pakalpojums ir ierosinātājs visos trijos; cēlonis tas ir reti.