Podłączasz iPhone'a, żeby go naładować, a minutę później VPN na Macu przestaje przepuszczać ruch. Ustawienia systemowe pokazują nową usługę o nazwie iPhone USB, a oczywistym krokiem jest jej usunięcie. Ten krok jest często błędny. Usługa może być osobistym hotspotem telefonu albo połączeniem, którego Xcode i narzędzia urządzeń używają do rozmowy z telefonem, a oba zachowują się na tyle różnie, że identyfikacja musi poprzedzać usunięcie.

Krok 1: Przeczytaj usługę, którą telefon faktycznie utworzył

Otwórz Ustawienia systemowe, potem Sieć, i porównaj listę usług z telefonem odłączonym i podłączonym. W obecnym macOS usługa jest wymieniona jako iPhone USB. Zwróć uwagę, czy jest aktywna, gdzie stoi w kolejności usług i czy Mac używa jej do trasy domyślnej. Kolejność usług ma znaczenie, bo macOS wybiera najwyższą aktywną usługę, która może dotrzeć do celu, a nie tę, której nazwę rozpoznajesz.

Przewodnik Apple dotyczący osobistego hotspotu opisuje mechanizm: dopóki osobisty hotspot jest włączony w telefonie, podłączenie go przez USB może sprawić, że Mac użyje połączenia komórkowego telefonu, nawet gdy chciałeś tylko ładować. To nie błąd klienta VPN; tabela tras podąża za usługą, która podniosła się przed Wi-Fi.

Jeśli usługa istnieje, ale pozostaje nieaktywna przy podłączonym telefonie, najprawdopodobniej patrzysz na połączenie tylko do ładowania albo połączenie urządzenia, a nie na hotspot. Zachowaj to rozróżnienie, bo dwa następne kroki testują je, zamiast zgadywać z ikony.

Krok 2: Sprawdź, której trasy używa punkt końcowy VPN

Czytaj trasę do rozwiązanego adresu serwera VPN, a nie do strony internetowej. route -n get jest tylko do odczytu i wypisuje interfejs oraz bramę, których użyłby kernel, i oba wiersze się liczą.

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

Powyższy adres to placeholder dokumentacyjny. Zastąp go punktem końcowym, który pokazuje twój klient, i użyj route -n get -inet6 dla punktu końcowego IPv6. Porównaj wynik z telefonem odłączonym i podłączonym i nie dodawaj ani nie usuwaj tras między dwoma odczytami. Jeśli interfejs zmieni się z en0 na interfejs iPhone USB, trasa przez hotspot wygrała wyszukiwanie i zewnętrzne połączenie VPN idzie teraz przez sieć komórkową.

Zmiana trasy nie wyjaśnia każdej awarii. Klient nadal może dotrzeć do serwera i później zawieść na wewnętrznym ruchu tunelu, bo nowa ścieżka ma inny MTU albo operator blokuje protokół. Przeczytaj własny błąd klienta, zanim cokolwiek zmienisz: zewnętrzny limit czasu uścisku dłoni wskazuje na osiągalność, a ustanowiony tunel, który przestaje przepuszczać ruch, wskazuje na MTU, DNS albo politykę.

Krok 3: Oddziel hotspot od połączenia komunikacji z urządzeniem

Xcode 15 i nowsze rozmawiają z urządzeniem podłączonym przez USB kanałem sieciowym, który obejmuje lokalny dla łącza IPv6, więc Mac deweloperski może pokazać dodatkowy interfejs, który nie ma nic wspólnego z dostępem do internetu. Nota techniczna Apple TN3158 dokumentuje to zachowanie i ostrzega, że VPN albo filtrowanie bezpieczeństwa może mu przeszkadzać. To odwrotność problemu z hotspotem: VPN nie psuje się dlatego, że telefon oferuje internet; połączenie urządzenia psuje się dlatego, że VPN je przechwytuje.

Dwie obserwacje rozdzielają przypadki bez przechwytywania pakietów. Po pierwsze, sprawdź, czy interfejs ma adres routowalny i trasę domyślną, czy tylko adres fe80:: lokalny dla łącza; tylko lokalny dla łącza oznacza brak drogi do internetu. Po drugie, zamknij VPN i sprawdź, czy Xcode znów dociera do urządzenia. Jeśli tak, trasy albo filtr treści VPN przechwytują ruch lokalny dla łącza, a poprawka należy do konfiguracji tunelu dzielonego albo filtra, nie do panelu Sieć.

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

Nie oceniaj tylko po nazwie interfejsu. macOS tworzy i niszczy te interfejsy w miarę podłączania urządzeń, a numer en jest przydzielany w czasie działania, więc ten sam Mac może pokazać inny numer po restarcie albo wymianie kabla.

Krok 4: Odtwórz awarię z jedną zmienną naraz

Gdy wiesz, która usługa jest w grze, odtwórz problem w ustalonej kolejności. Zacznij z odłączonym telefonem i podłączonym VPN. Podłącz telefon przy wyłączonym osobistym hotspocie, poczekaj, aż lista Sieć się ustabilizuje, i uruchom ponownie zapytanie o trasę. Odłącz, włącz osobisty hotspot, podłącz ponownie i powtórz. Zapisz interfejs, bramę i błąd klienta dla każdego z trzech stanów, a będziesz mieć porównanie zamiast wspomnienia.

Jeśli VPN zawodzi tylko w stanie hotspotu, trzymaj telefon z dala od tej ścieżki: wyłącz osobisty hotspot podczas ładowania albo przenieś usługę iPhone USB poniżej Wi-Fi w kolejności usług. Jeśli zawodzi w każdym podłączonym stanie, także przy wyłączonym hotspocie, sprawdź, jak klient obsługuje przejście sieciowe. Niektórzy klienci zrywają tunel, gdy zmienia się usługa podstawowa, i wymagają ponownego połączenia; to zachowanie klienta, nie usterka telefonu.

Zmieniaj jedną rzecz na próbę. Usunięcie usługi, zresetowanie konfiguracji VPN i ponowna instalacja klienta w tej samej minucie zostawiają cię z działającym Makiem i bez pojęcia, która czynność to naprawiła.

Krok 5: Zdecyduj, co zachować, a co sprawdzić

Zostaw połączenie urządzenia w spokoju. Usunięcie interfejsu, którego używa Xcode, nie naprawia trasy VPN i psuje wdrażanie na urządzenia do następnego podłączenia. Jeśli usługa hotspotu naprawdę jest niechciana, najpierw wyłącz osobisty hotspot w telefonie; to udokumentowana kontrola i przetrwa restart.

Jeśli jednak usuniesz usługę, usuń tę, którą zidentyfikowałeś, a potem sprawdź dwie rzeczy: trasa do punktu końcowego VPN wróciła na oczekiwany interfejs, a tunel przepuszcza ruch do adresu wewnętrznego, nie tylko do internetu. Zapisz kolejność usług i wersję klienta, bo aktualizacja macOS może zmienić wygląd telefonu.

Potem sklasyfikuj awarię, którą naprawdę widziałeś. Limit czasu uścisku dłoni, zatrzymanie MTU po podniesieniu tunelu i odpowiedzi DNS przychodzące od operatora to trzy różne problemy z trzema różnymi poprawkami. Usługa USB jest wyzwalaczem we wszystkich trzech; przyczyną bywa rzadko.

Powiązane artykuły