iMessage nem frissül Mac VPN-en át: ellenőrzések sorrendben

Ha a Messages leáll a szinkronizálással, miközben a Safari még tölti az oldalakat, a VPN valószínű ok, de nem bizonyított. Az iMessage az Apple push-értesítési szolgáltatásától (APNs) és az Apple identitásszolgáltatásaitól függ, és az alagút megváltoztathatja az útvonalat, a feloldót vagy az ezekre a kapcsolatokra alkalmazott vizsgálatot anélkül, hogy érintené a webtrafikot. Egyetlen blokkolt port ritkán a teljes történet, ezért az alábbi ellenőrzések a Mac-től kifelé haladnak. Álljon meg az első sikertelen lépésnél, és javítsa ki, mielőtt bármi mást változtat.

Először pontosítsa a tünetet. Bejelentkezési hiba, soha el nem induló üzenet, soha meg nem érkező üzenet és le nem tölthető melléklet négy különböző probléma, amelyek véletlenül ugyanazt az alkalmazást használják. Jegyezze fel, melyik áll fenn, melyik VPN-profil volt aktív és a kliens verzióját; erre a feljegyzésre később a hálózati felelősnek is szüksége lesz.

1. ellenőrzés: mit irányít és fog át az alagút

Nézze meg a profilt az alkalmazás előtt. A teljes alagút minden forgalmat a VPN-en keresztül küld, a megosztott alagút csak a felsorolt alhálózatokat, az alkalmazásonkénti alagút pedig csak a kiválasztott alkalmazásokat tartalmazza. Ha a Messages az érintett halmazon kívül esik, a fizikai interfészt használja, és a VPN nem lehet az ok. scutil --nc list a konfiguráció által kezelt szolgáltatásokat mutatja, netstat -rn -f inet megmutatja, hova mutat az alapértelmezett útvonal, a kliens profilnézete pedig azt, hogy a hatókör alkalmazásalapú-e.

Teljesülési feltétel: az alapértelmezett útvonal vagy az alkalmazásonkénti bevonás ténylegesen lefedi a Messages-t, és a tesztelt profil a jelenleg alkalmazott. Ha nem, álljon meg, és a hálózat helyett a klienst vagy az operációs rendszert vizsgálja.

2. ellenőrzés: feloldószabályzat és vizsgálat

A push- és fiókszolgáltatások gyakran a böngészőjétől eltérő neveket oldanak fel, és a megosztott DNS ezeket a lekérdezéseket váratlan helyre küldheti. scutil --dns tartományonként listázza a feloldókat; hasonlítsa össze az Apple-tartományokhoz használt feloldót azzal, amelyet elvár. Az a feloldó, amely belső címmel válaszol, vagy egyenesen elutasítja a lekérdezést, még egyetlen csomag Apple-hez érkezése előtt megtöri a szolgáltatást.

Ezután ellenőrizze, hogy az alagút vizsgálja-e a TLS-t. Az Apple hálózati követelményei szerint a felsorolt szolgáltatásai nem HTTPS-elfogásra készültek, és az a berendezés, amely ezeket a kapcsolatokat lezárja, érintetlenül hagyhatja a webböngészést, miközben az üzenetküldés csendben meghibásodik. Ha a vizsgálat mindent lefed, zárja ki a vonatkozó Apple szolgáltatáskategóriákat, és teszteljen újra, ahelyett hogy globálisan kikapcsolná a vizsgálatot.

3. ellenőrzés: APNs-szállítás, beleértve a 443-at

Az eszközök APNs-kapcsolatai TCP 5223-at használnak, a TCP 443 pedig aktiválásra és tartalék útvonalra szolgál támogatott helyzetekben. Mindkettő kimenő, az eszköz által kezdeményezett kapcsolat. Nincs szüksége bejövő portra a routeren, és ha egyet megnyit a Mac-en, feltár egy szolgáltatást anélkül, hogy segítene egy kliensen, amely amúgy sem éri el az Apple-t.

Teljesülési feltétel: egy új üzenet a Mac-ről eljut egy másik hálózaton lévő címzetthez, és a válasza megérkezik, miközben ugyanaz a profil még aktív. Küldjön egy nem érzékeny üzenetet, és várjon egy válaszra egy köteg helyett, hogy a részleges siker is megmutassa, melyik irány hibázott. Ha a küldés működik, de a mellékletek elakadnak, a szállítás valószínűleg rendben van, és a szűkebb útvonalat kell vizsgálni.

4. ellenőrzés: a fiók állapota az alaphelyzetbe állítás előtt

Az aktiválási vagy bejelentkezési hiba a fiókréteghez tartozik, nem az alagúthoz. Erősítse meg, hogy a Mac dátuma és időpontja helyes, hogy az Apple ID be van jelentkezve, és hogy vár-e ellenőrzési kérés egy másik eszközön. A függőben lévő kétfaktoros jóváhagyás a Messages ablakából pontosan úgy néz ki, mint egy kapcsolódási hiba.

Ellenálljon az alaphelyzetbe állítás ösztönének. A kijelentkezés és új bejelentkezés, vagy a fiók visszaállítása eldobja azt az állapotot, amely megmutatta volna, hol volt a hiba, és egy felügyelt Mac-en olyan regisztrációs lépéseket indíthat, amelyeket egyedül nem tud visszavonni. Hitelesítse újra egyszer, és csak miután a szállítási ellenőrzések átmentek, és a fiók maradt az egyetlen gyanúsított.

Mit adjon át a hálózati felelősnek

Ha az ellenőrzések az alagútra mutatnak, a hasznos jelentés rövid: Mac-modell és macOS-verzió, kliensnév és -verzió, profilnév, az időablak, melyik irány hibázott, és az eltérő útvonal- vagy feloldómegfigyelés. Hagyja ki az üzenetek tartalmát és a beszélgetések képernyőképeit.

Kérje, hogy a szabályzatot a tényleges szűrési határon alkalmazzák. Az Apple jelenlegi vállalati hálózati követelményei szolgáltatásonként sorolják fel a gazdagépeket és szállítási feltételeket, így a felelős összevetheti őket a szabálykészlettel, ahelyett hogy portot nyitna és reménykedne. Minden változtatás után teszteljen újra egy üzenettel; két változó egyszerre olyan eredményt ad, amelyet nem tud elolvasni.