ההתראות מפסיקות להגיע בטלפון שאחרת גולש היטב דרך ה-VPN הארגוני. דפי אינטרנט נטענים, האפליקציה נפתחת, וההודעות מופיעות רק בבית או לאחר כיבוי המנהרה. באפליקציה שנבנתה על Firebase Cloud Messaging, ערוץ ה-push הוא חיבור יוצא נפרד וארוך-טווח, לא נתיב ה-HTTPS שהדפדפן הרגע הוכיח. עברו על הבדיקות האלה לפי הסדר ועצרו בראשונה שנכשלת.

ודאו שהאפליקציה באמת משתמשת ב-FCM

לא כל התראה היא push. חלקן מתוזמנות מקומית על ידי האפליקציה, חלקן נשאלות דרך HTTPS, וחלקן מגיעות בערוץ של ספק שאין לו שום קשר ל-Firebase. אם המניפסט והתלויות של האפליקציה כוללים Firebase Messaging, ההתראות שלה עוברות בדרך כלל דרך חיבור FCM, וספריית הלקוח רושמת את הרישום תחת תג צפוי.

adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase

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

בדקו את הפורטים היוצאים, לא את האתר

חיבורי המכשיר ל-FCM הם TCP שמקורו במכשיר אל פורט 5228, עם 5229 ו-5230 כגיבוי ו-443 כמוצא אחרון. חומת אש שמתירה 443 לגלישה עדיין יכולה לשבור את ה-push, וכלל שמתיר את דומיין ה-API של אפליקציה אינו מכסה את נקודות הקצה של ההודעות, שהן שירותים נפרדים.

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

PortRoleWhat to verify
5228Primary FCM connectionOutbound allowed and session state kept
5229, 5230Fallback portsOften missing from hand-written allowlists
443Last-resort fallbackWorks only if the client actually falls back
HTTP proxyNot a supported FCM transportProxy exclusion or bypass, not a port rule

הנחיות הרשת של Firebase גם קובע שאין להעביר את פרוטוקול המסירה של FCM דרך פרוקסי HTTP רגיל. לכן העובדה שדפדפן עובד דרך פרוקסי האינטרנט הארגוני אינה מוכיחה דבר על סוקט ה-push: אלה שני לקוחות שונים עם נתיבים שונים.

בדקו את פסקי הזמן של חוסר פעילות שהורגים את הסוקט

חיבור FCM נשאר פתוח בין הודעות, מה שהופך אותו לרגיש לפסקי זמן של NAT ושל בדיקה מבוססת מצב. הנחיות Firebase מבקשות לפחות 30 דקות של סבילות לחוסר פעילות במקומות שבהם מדיניות כזו חלה. פסק זמן של חמש דקות מסיר את המיפוי בשקט, והטלפון מתחבר מחדש רק כשמשהו מעיר אותו, ולכן ההודעות מגיעות בהתפרצויות או לא מגיעות כלל.

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

מסירת push תלויה גם בכך שמיפוי נקודת הקצה ישרוד נדידה בין Wi-Fi לרשת סלולרית. מיפוי שנקשר לממשק אחד עלול להימחק בהעברה גם כששתי הרשתות מתירות את הפורטים.

החליטו אם עקיפת VPN מקובלת

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

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

הפרידו בין מסירה לתצוגה, ואז בדקו פעם אחת

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

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

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

מאמרים קשורים