iMessage nie aktualizuje się przez VPN na Macu: kontrole po kolei
Awarie push rzadko wynikają z jednego zablokowanego portu. Wykonaj kontrole po kolei: routing i zakres aplikacji, resolver, osiągalność APNs, a potem stan konta.
Jeśli Messages przestaje synchronizować, podczas gdy Safari nadal wczytuje strony, VPN jest prawdopodobną przyczyną, ale nie udowodnioną. iMessage zależy od Apple Push Notification service oraz usług tożsamości Apple, a tunel może zmienić trasę, resolver lub inspekcję stosowaną do tych połączeń, nie dotykając ruchu webowego. Jeden zablokowany port rzadko jest całą historią, dlatego poniższe kontrole idą od Maca na zewnątrz. Zatrzymaj się na pierwszym kroku, który zawiedzie, i napraw go, zanim zmienisz cokolwiek innego.
Najpierw ustal objaw. Błąd logowania, wiadomość, która nigdy nie wychodzi, wiadomość, która nigdy nie dociera, i załącznik, który się nie pobiera, to cztery różne problemy, które przypadkiem dzielą jedną aplikację. Zapisz, który masz, który profil VPN był aktywny i wersję klienta; ta notatka przyda się później także właścicielowi sieci.
Kontrola 1: co tunel kieruje i jaki ma zakres
Spójrz na profil, zanim spojrzysz na aplikację. Pełny tunel wysyła cały ruch przez VPN, tunel dzielony wysyła tylko wymienione podsieci, a tunel dla aplikacji obejmuje tylko wybrane aplikacje. Jeśli Messages znajduje się poza uwzględnionym zbiorem, korzysta z interfejsu fizycznego i VPN nie może być przyczyną. scutil --nc list pokazuje usługi zarządzane konfiguracją, netstat -rn -f inet pokazuje, dokąd prowadzi trasa domyślna, a widok profilu klienta pokazuje, czy zakres jest oparty na aplikacjach.
Warunek zaliczenia: trasa domyślna lub uwzględnienie dla aplikacji faktycznie obejmuje Messages, a testowany profil to ten stosowany teraz. Jeśli nie, zatrzymaj się i sprawdź klienta lub system, a nie sieć.
Kontrola 2: polityka resolvera i inspekcja
Usługi push i konta rozwiązują nazwy, które często różnią się od tych używanych przez przeglądarkę, a dzielony DNS może wysłać te zapytania w nieoczekiwane miejsce. scutil --dns wymienia resolvery według domeny; porównaj resolver używany dla domen Apple z tym, którego oczekujesz. Resolver, który odpowiada adresem wewnętrznym lub całkowicie odrzuca zapytanie, psuje usługę, zanim choćby jeden pakiet dotrze do Apple.
Następnie sprawdź, czy tunel inspekcjonuje TLS. Wymagania sieciowe Apple mówią, że wymienione usługi nie są projektowane do przechwytywania HTTPS, a urządzenie, które kończy te połączenia, może pozostawić przeglądanie stron nietknięte, podczas gdy wiadomości po cichu zawodzą. Jeśli inspekcja obejmuje wszystko, wyklucz odpowiednie kategorie usług Apple i przetestuj ponownie, zamiast wyłączać inspekcję globalnie.
Kontrola 3: transport APNs, w tym 443
Połączenia urządzeń z APNs używają TCP 5223, a TCP 443 służy do aktywacji i trasy zapasowej w obsługiwanych sytuacjach. Oba są połączeniami wychodzącymi inicjowanymi przez urządzenie. Nie potrzebujesz portu przychodzącego na routerze, a opublikowanie go na Macu wystawia usługę, nie pomagając klientowi, który i tak nie dociera do Apple.
Warunek zaliczenia: nowa wiadomość z Maca dociera do odbiorcy w innej sieci, a jego odpowiedź przychodzi, przy nadal aktywnym tym samym profilu. Wyślij jedną niepoufną wiadomość i poczekaj na jedną odpowiedź, a nie na partię, aby częściowy sukces nadal pokazał, który kierunek zawiódł. Jeśli wysyłanie działa, a załączniki się zatrzymują, transport jest prawdopodobnie w porządku i węższa ścieżka jest tym, co trzeba sprawdzić.
Kontrola 4: stan konta, zanim je zresetujesz
Błąd aktywacji lub logowania należy do warstwy konta, a nie do tunelu. Potwierdź, że data i godzina na Macu są poprawne, że Apple ID jest zalogowane i czy na innym urządzeniu czeka monit weryfikacyjny. Oczekujące zatwierdzenie dwuskładnikowe wygląda z wnętrza okna Messages dokładnie jak awaria łączności.
Oprzyj się odruchowi resetowania. Wylogowanie i ponowne zalogowanie albo zresetowanie konta wyrzuca stan, który pokazałby, gdzie leży awaria, a na zarządzanym Macu może uruchomić kroki rejestracji, których nie cofniesz sam. Uwierzytelnij się ponownie raz, i to dopiero po przejściu kontroli transportu i gdy konto pozostanie jedynym podejrzanym.
Co przekazać właścicielowi sieci
Jeśli kontrole wskazują tunel, przydatny raport jest krótki: model Maca i wersja macOS, nazwa i wersja klienta, nazwa profilu, okno czasowe, który kierunek zawiódł oraz zaobserwowana różnica trasy lub resolvera. Pomiń treść wiadomości i zrzuty ekranu rozmów.
Poproś o stosowanie polityki na rzeczywistej granicy filtrowania. Aktualne wymagania sieciowe Apple dla firm wymieniają hosty i warunki transportu dla każdej usługi, więc właściciel może dopasować je do zestawu reguł, zamiast otwierać port i mieć nadzieję. Po każdej zmianie przetestuj ponownie jedną wiadomością; dwie zmienne naraz dają wynik, którego nie odczytasz.