iMessage לא מתעדכן דרך VPN ב-Mac: בדיקות לפי הסדר

אם Messages מפסיק להסתנכרן בעוד Safari עדיין טוען דפים, ה-VPN הוא סיבה סבירה אך לא מוכחת. iMessage תלוי בשירות ההתראות push של Apple (APNs) ובשירותי הזהות של Apple, ומנהרה יכולה לשנות את המסלול, את הפותר או את הבדיקה המופעלת על החיבורים האלה בלי לגעת בתעבורת האינטרנט. פורט חסום אחד הוא לעתים רחוקות כל הסיפור, ולכן הבדיקות שלהלן מתקדמות מה-Mac החוצה. עצרו בשלב הראשון שנכשל ותקנו אותו לפני שתשנו משהו אחר.

קודם לכן חדדו את הסימפטום. כשל התחברות, הודעה שלעולם לא יוצאת, הודעה שלעולם לא מגיעה וקובץ מצורף שלא יורד הם ארבע בעיות שונות שבמקרה חולקות אפליקציה אחת. רשמו איזו מהן יש לכם, איזו פרופיל VPN היה פעיל וגרסת הלקוח; בהערה הזו יצטרך גם אחראי הרשת בהמשך.

בדיקה 1: מה המנהרה מנתבת ומכסה

הסתכלו בפרופיל לפני האפליקציה. מנהרה מלאה שולחת את כל התעבורה דרך ה-VPN, מנהרה מפוצלת רק את תת-הרשתות המפורטות, ומנהרה לפי אפליקציה כוללת רק את האפליקציות הנבחרות. אם Messages מחוץ לקבוצה הנכללת, הוא משתמש בממשק הפיזי וה-VPN לא יכול להיות הסיבה. scutil --nc list מציג שירותים המנוהלים על ידי תצורה, netstat -rn -f inet מראה לאן מכוון המסלול המוגדר כברירת מחדל, ותצוגת הפרופיל בלקוח מראה אם ההיקף מבוסס על האפליקציה.

תנאי מעבר: המסלול המוגדר כברירת מחדל או ההכללה לפי אפליקציה אכן מכסים את Messages, והפרופיל שאתם בודקים הוא זה שמופעל כרגע. אם לא, עצרו ובדקו את הלקוח או את מערכת ההפעלה ולא את הרשת.

בדיקה 2: מדיניות הפותר ובדיקה

שירותי push וחשבון מפענחים שמות שלעתים קרובות שונים מאלה שהדפדפן שלכם משתמש בהם, ו-DNS מפוצל יכול לשלוח את השאילתות האלה למקום לא צפוי. scutil --dns מציג פותרים לפי דומיין; השוו את הפותר המשמש לדומיינים של Apple לזה שאתם מצפים לו. פותר שעונה בכתובת פנימית, או דוחה את השאילתה לחלוטין, שובר את השירות לפני שאפילו חבילה אחת מגיעה ל-Apple.

לאחר מכן בדקו אם המנהרה בודקת TLS. דרישות הרשת של Apple קובעות שהשירותים המפורטים שלה אינם מיועדים ליירוט HTTPS, והתקן שמסיים את החיבורים האלה יכול להשאיר את גלישת האינטרנט שלמה בעוד שההתכתבות נכשלת בשקט. אם הבדיקה מכסה הכול, החריגו את קטגוריות השירות הרלוונטיות של Apple ובדקו שוב במקום לכבות את הבדיקה באופן גורף.

בדיקה 3: תעבורת APNs, כולל 443

חיבורי מכשירים ל-APNs משתמשים ב-TCP 5223, כאשר TCP 443 משמש להפעלה ולנסיגה במצבים נתמכים. שניהם חיבורים יוצאים שמכשיר יוזם. אינכם זקוקים לפורט נכנס בנתב, ופרסום אחד ב-Mac חושף שירות בלי לעזור ללקוח שלא יכול להגיע ל-Apple מלכתחילה.

תנאי מעבר: הודעה חדשה מה-Mac מגיעה לנמען ברשת אחרת והתשובה שלו מגיעה, כשאותו פרופיל עדיין פעיל. שלחו הודעה אחת לא רגישה והמתינו לתשובה אחת ולא לקבוצה, כדי שגם הצלחה חלקית תראה איזה כיוון נכשל. אם השליחה עובדת והקבצים המצורפים נתקעים, התעבורה כנראה תקינה והמסלול הצר יותר הוא מה שצריך לבדוק.

בדיקה 4: מצב החשבון לפני איפוס

שגיאת הפעלה או התחברות שייכת לשכבת החשבון, לא למנהרה. ודאו שתאריך ושעה של ה-Mac נכונים, שה-Apple ID מחובר, והאם בקשת אימות ממתינה במכשיר אחר. אישור דו-שלבי שממתין נראה בדיוק כמו כשל קישוריות מחלון Messages.

התנגדו לדחף לאפס. התנתקות והתחברות מחדש, או איפוס החשבון, משליכים את המצב שהיה מראה לכם היכן הכשל, וב-Mac מנוהל זה יכול להתחיל שלבי הרשמה שאינכם יכולים לבטל לבד. אמתו מחדש פעם אחת, ורק אחרי שבדיקות התעבורה עברו והחשבון הוא החשוד היחיד שנותר.

מה למסור לאחראי הרשת

אם הבדיקות מצביעות על המנהרה, הדוח השימושי קצר: דגם Mac וגרסת macOS, שם וגרסת הלקוח, שם הפרופיל, חלון הזמן, איזה כיוון נכשל, ותצפית המסלול או הפותר שהייתה שונה. השאירו בחוץ תוכן הודעות וצילומי מסך של שיחות.

בקשו שהמדיניות תיושם בגבול הסינון האמיתי. דרישות הרשת הארגוניות הנוכחיות של Apple מפרטות מארחים ותנאי תעבורה לכל שירות, כך שהאחראי יכול להשוות אותן למערך הכללים במקום לפתוח פורט ולקוות. בדקו שוב עם הודעה אחת אחרי כל שינוי; שני משתנים בבת אחת נותנים תוצאה שאי אפשר לקרוא.