Hindi nag-a-update ang iMessage sa VPN ng Mac: mga pagsusuri sa pagkakasunod-sunod

Kung huminto ang Messages sa pag-sync habang naglo-load pa rin ang Safari ng mga pahina, ang VPN ay isang malamang na dahilan ngunit hindi pa napatunayan. Ang iMessage ay umaasa sa Apple Push Notification service kasama ng mga serbisyo ng pagkakakilanlan ng Apple, at ang isang tunnel ay maaaring magbago ng ruta, resolver, o inspeksyong inilalapat sa mga koneksyong iyon nang hindi hinahawakan ang trapikong web. Ang isang naharang na port ay bihirang ang buong kuwento, kaya ang mga pagsusuri sa ibaba ay gumagalaw mula sa Mac pakanluran. Huminto sa unang hakbang na nabigo at ayusin iyon bago baguhin ang anupaman.

Unahin ang pagtukoy ng sintomas. Pagkabigo sa pag-sign in, isang mensaheng hindi kailanman lumalabas, isang mensaheng hindi kailanman dumarating, at isang attachment na hindi nagda-download ay apat na magkakaibang problema na nagkataong nagbabahagi ng isang app. Isulat kung alin ang mayroon ka, aling profile ng VPN ang aktibo, at ang bersyon ng client; kakailanganin din ng may-ari ng network ang talaang iyon mamaya.

Pagsusuri 1: ano ang ruta at saklaw ng tunnel

Tingnan ang profile bago ang app. Ang buong tunnel ay nagpapadala ng lahat ng trapiko sa VPN, ang split tunnel ay nagpapadala lamang ng mga nakalistang subnet, at ang tunnel kada app ay kinabibilangan lamang ng mga napiling application. Kung ang Messages ay nasa labas ng kasamang set, gumagamit ito ng pisikal na interface at ang VPN ay hindi maaaring maging sanhi. scutil --nc list ay nagpapakita ng mga serbisyong pinamamahalaan ng configuration, netstat -rn -f inet ay nagpapakita kung saan tumuturo ang default na ruta, at ang profile view ng client ay nagpapakita kung ang saklaw ay nakabatay sa app.

Kondisyon ng pagpasa: ang default na ruta o ang pagsasama kada app ay talagang sumasaklaw sa Messages, at ang profile na sinusubukan mo ay ang inilalapat ngayon. Kung hindi, huminto at siyasatin ang client o ang OS sa halip na ang network.

Pagsusuri 2: patakaran ng resolver at inspeksyon

Ang mga serbisyong push at account ay nireresolba ang mga pangalang madalas na naiiba sa ginagamit ng iyong browser, at ang split DNS ay maaaring magpadala ng mga query na iyon sa hindi inaasahang lugar. scutil --dns ay naglilista ng mga resolver kada domain; ihambing ang resolver na ginagamit para sa mga domain ng Apple sa inaasahan mo. Ang resolver na sumasagot ng panloob na address, o tahasang tinatanggihan ang query, ay sumisira sa serbisyo bago pa man makarating ang isang packet sa Apple.

Pagkatapos tingnan kung iniinspeksyon ng tunnel ang TLS. Sinasabi ng mga kinakailangan sa network ng Apple na ang mga nakalistang serbisyo ay hindi dinisenyo para sa HTTPS interception, at ang appliance na nagtatapos sa mga koneksyong iyon ay maaaring iwanang buo ang pag-browse sa web habang tahimik na nabibigo ang pagmemensahe. Kung ang inspeksyon ay sumasaklaw sa lahat, ibukod ang mga kaugnay na kategorya ng serbisyo ng Apple at muling subukan sa halip na patayin ang inspeksyon sa buong network.

Pagsusuri 3: transport ng APNs, kasama ang 443

Ang mga koneksyon ng device sa APNs ay gumagamit ng TCP 5223, habang ang TCP 443 ay ginagamit para sa activation at fallback sa mga sinusuportahang sitwasyon. Pareho silang palabas na koneksyong sinisimulan ng device. Hindi mo kailangan ng papasok na port sa router, at ang pag-publish ng isa sa Mac ay naglalantad ng serbisyo nang hindi tumutulong sa client na hindi talaga nakakarating sa Apple.

Kondisyon ng pagpasa: ang bagong mensahe mula sa Mac ay nakakarating sa isang tatanggap sa ibang network, at dumarating ang kanilang sagot, habang aktibo pa rin ang parehong profile. Magpadala ng isang hindi sensitibong mensahe at maghintay ng isang sagot sa halip na isang batch, upang ang bahagyang tagumpay ay magpakita pa rin kung aling direksyon ang nabigo. Kung gumagana ang pagpapadala at natigil ang mga attachment, malamang ay maayos ang transport at ang mas makitid na landas ang dapat siyasatin.

Pagsusuri 4: kalagayan ng account bago ito i-reset

Ang error sa activation o pag-sign in ay kabilang sa layer ng account, hindi sa tunnel. Kumpirmahin na tama ang petsa at oras ng Mac, na naka-sign in ang Apple ID, at kung may nakabinbing verification prompt sa ibang device. Ang nakabinbing two-factor approval ay mukhang eksaktong pagkabigo sa koneksyon mula sa loob ng window ng Messages.

Labanan ang instinct na mag-reset. Ang pag-sign out at pag-sign in muli, o pag-reset ng account, ay itinatapon ang estado na magpapakita sana kung saan naroon ang pagkabigo, at sa isang managed Mac maaari itong magsimula ng mga hakbang sa enrollment na hindi mo kayang bawiin nang mag-isa. Magsagawa ng reauthentication nang isang beses, at pagkatapos lamang na pumasa ang mga pagsusuri sa transport at ang account ang natitirang suspetsa.

Ano ang ibibigay sa may-ari ng network

Kung itinuturo ng mga pagsusuri ang tunnel, ang kapaki-pakinabang na ulat ay maikli: modelo ng Mac at bersyon ng macOS, pangalan at bersyon ng client, pangalan ng profile, ang time window, aling direksyon ang nabigo, at ang obserbasyon sa ruta o resolver na naiiba. Iwanan ang nilalaman ng mensahe at mga screenshot ng usapan.

Hilingin na ilapat ang patakaran sa tunay na hangganan ng pag-filter. Kasalukuyang mga kinakailangan sa network ng enterprise ng Apple ay naglilista ng mga host at kundisyon ng transport kada serbisyo, kaya maaaring itugma ng may-ari ang mga ito sa set ng patakaran sa halip na magbukas ng port at umasa. Muling subukan gamit ang isang mensahe pagkatapos ng bawat pagbabago; ang dalawang variable nang sabay ay nagbibigay ng resulta na hindi mo mababasa.