iMessage ไม่อัปเดตผ่าน VPN บน Mac: ลำดับการตรวจสอบ

หาก Messages หยุดซิงก์ในขณะที่ Safari ยังโหลดหน้าเว็บได้ VPN เป็นสาเหตุที่เป็นไปได้แต่ยังไม่พิสูจน์ iMessage ต้องพึ่ง Apple Push Notification service ร่วมกับบริการระบุตัวตนของ Apple และอุโมงค์สามารถเปลี่ยนเส้นทาง resolver หรือการตรวจสอบที่ใช้กับการเชื่อมต่อเหล่านั้นโดยไม่แตะทราฟฟิกเว็บ พอร์ตเดียวที่ถูกบล็อกไม่ค่อยเป็นเรื่องทั้งหมด ดังนั้นการตรวจสอบด้านล่างจะไล่จาก Mac ออกไปด้านนอก หยุดที่ขั้นตอนแรกที่ล้มเหลวและแก้ไขขั้นตอนนั้นก่อนเปลี่ยนอย่างอื่น

ระบุอาการให้ชัดก่อน การลงชื่อเข้าใช้ล้มเหลว ข้อความที่ไม่เคยส่งออก ข้อความที่ไม่เคยมาถึง และไฟล์แนบที่ดาวน์โหลดไม่ได้ เป็นปัญหาสี่อย่างที่ต่างกันแต่บังเอิญใช้แอปเดียวกัน จดบันทึกว่าคุณเป็นแบบไหน โปรไฟล์ VPN ใดทำงานอยู่ และเวอร์ชันไคลเอนต์ บันทึกนั้นยังเป็นสิ่งที่เจ้าของเครือข่ายต้องใช้ในภายหลัง

การตรวจสอบ 1: อุโมงค์กำหนดเส้นทางและขอบเขตอะไร

ดูโปรไฟล์ก่อนดูแอป อุโมงค์เต็มส่งทราฟฟิกทั้งหมดผ่าน VPN อุโมงค์แยกส่งเฉพาะซับเน็ตที่ระบุ และอุโมงค์รายแอปจะรวมเฉพาะแอปที่เลือก หาก Messages อยู่นอกชุดที่รวมอยู่ แสดงว่าใช้อินเทอร์เฟซกายภาพและ VPN ไม่ใช่สาเหตุ scutil --nc list แสดงบริการที่จัดการผ่านการกำหนดค่า netstat -rn -f inet แสดงว่าเส้นทางเริ่มต้นชี้ไปที่ใด และมุมมองโปรไฟล์ของไคลเอนต์แสดงว่าขอบเขตอิงแอปหรือไม่

เงื่อนไขผ่าน: เส้นทางเริ่มต้นหรือการรวมรายแอปครอบคลุม Messages จริง และโปรไฟล์ที่คุณทดสอบคือโปรไฟล์ที่ใช้อยู่ในขณะนี้ หากไม่ใช่ ให้หยุดและตรวจไคลเอนต์หรือระบบปฏิบัติการแทนเครือข่าย

การตรวจสอบ 2: นโยบาย resolver และการตรวจสอบ

บริการพุชและบัญชีแก้ชื่อที่มักต่างจากชื่อที่เบราว์เซอร์ของคุณใช้ และ DNS แบบแยกส่วนอาจส่งคำถามเหล่านั้นไปยังที่ที่ไม่คาดคิด scutil --dns แสดงรายการ resolver ตามโดเมน เปรียบเทียบ resolver ที่ใช้กับโดเมนของ Apple กับตัวที่คุณคาดหวัง resolver ที่ตอบด้วยที่อยู่ภายใน หรือปฏิเสธคำถามไปเลย จะทำให้บริการเสียก่อนที่แพ็กเก็ตแรกจะไปถึง Apple

จากนั้นตรวจสอบว่าอุโมงค์ตรวจสอบ TLS หรือไม่ ข้อกำหนดเครือข่ายของ Apple ระบุว่าบริการที่ระบุไว้ไม่ได้ออกแบบมาสำหรับการดักจับ HTTPS และอุปกรณ์ที่สิ้นสุดการเชื่อมต่อเหล่านั้นอาจทำให้การท่องเว็บยังใช้งานได้ในขณะที่การรับส่งข้อความล้มเหลวอย่างเงียบ ๆ หากการตรวจสอบครอบคลุมทุกอย่าง ให้ยกเว้นหมวดหมู่บริการ Apple ที่เกี่ยวข้องและทดสอบซ้ำ แทนที่จะปิดการตรวจสอบทั้งระบบ

การตรวจสอบ 3: การรับส่ง APNs รวมถึง 443

การเชื่อมต่อของอุปกรณ์ไปยัง APNs ใช้ TCP 5223 โดย TCP 443 ใช้สำหรับการเปิดใช้งานและเส้นทางสำรองในสถานการณ์ที่รองรับ ทั้งสองเป็นการเชื่อมต่อขาออกที่อุปกรณ์เริ่มเอง คุณไม่จำเป็นต้องมีพอร์ตขาเข้าบนเราเตอร์ และการเผยแพร่พอร์ตบน Mac จะเปิดเผยบริการโดยไม่ช่วยไคลเอนต์ที่ไปไม่ถึง Apple อยู่แล้ว

เงื่อนไขผ่าน: ข้อความใหม่จาก Mac ไปถึงผู้รับบนเครือข่ายอื่น และคำตอบของพวกเขามาถึง โดยโปรไฟล์เดิมยังทำงานอยู่ ส่งข้อความที่ไม่ละเอียดอ่อนหนึ่งข้อความและรอคำตอบหนึ่งครั้งแทนการส่งเป็นชุด เพื่อให้ความสำเร็จบางส่วนยังบอกได้ว่าทิศทางใดล้มเหลว หากการส่งทำงานแต่ไฟล์แนบค้าง การรับส่งน่าจะปกติดี และเส้นทางที่แคบกว่าคือสิ่งที่ต้องตรวจสอบ

การตรวจสอบ 4: สถานะบัญชีก่อนรีเซ็ต

ข้อผิดพลาดในการเปิดใช้งานหรือลงชื่อเข้าใช้เป็นของชั้นบัญชี ไม่ใช่อุโมงค์ ยืนยันว่าวันที่และเวลาของ Mac ถูกต้อง Apple ID ลงชื่อเข้าใช้อยู่ และมีพรอมต์ยืนยันรออยู่บนอุปกรณ์อื่นหรือไม่ การอนุมัติสองปัจจัยที่ค้างอยู่ดูเหมือนความล้มเหลวในการเชื่อมต่อทุกประการเมื่อมองจากในหน้าต่าง Messages

ต้านความอยากรีเซ็ต การลงชื่อออกแล้วลงชื่อเข้าใช้ใหม่ หรือการรีเซ็ตบัญชี จะทิ้งสถานะที่จะบอกคุณว่าความล้มเหลวอยู่ที่ใด และบน Mac ที่มีการจัดการอาจเริ่มขั้นตอนการลงทะเบียนที่คุณยกเลิกเองไม่ได้ ยืนยันตัวตนใหม่เพียงครั้งเดียว และเฉพาะหลังจากการตรวจสอบการรับส่งผ่านแล้วและบัญชีเป็นผู้ต้องสงสัยที่เหลืออยู่

สิ่งที่ต้องส่งให้เจ้าของเครือข่าย

หากการตรวจสอบชี้ไปที่อุโมงค์ รายงานที่มีประโยชน์นั้นสั้น: รุ่น Mac และเวอร์ชัน macOS ชื่อและเวอร์ชันไคลเอนต์ ชื่อโปรไฟล์ ช่วงเวลา ทิศทางที่ล้มเหลว และข้อสังเกตเรื่องเส้นทางหรือ resolver ที่แตกต่างออกไป อย่ารวมเนื้อหาข้อความและภาพหน้าจอของการสนทนา

ขอให้ใช้นโยบายที่ขอบเขตการกรองจริง ข้อกำหนดเครือข่ายองค์กรฉบับปัจจุบันของ Apple ระบุโฮสต์และเงื่อนไขการรับส่งต่อบริการ เพื่อให้เจ้าของจับคู่กับชุดกฎได้แทนที่จะเปิดพอร์ตแล้วหวัง ทดสอบซ้ำด้วยข้อความหนึ่งข้อความหลังการเปลี่ยนแปลงแต่ละครั้ง การเปลี่ยนสองตัวแปรพร้อมกันจะให้ผลลัพธ์ที่คุณอ่านไม่ออก