इतर सर्व गोष्टींमध्ये कॉर्पोरेट VPN वरून व्यवस्थित ब्राउझ करणाऱ्या फोनवर सूचना येणे थांबते. वेब पृष्ठे लोड होतात, ॲप उघडते, आणि संदेश फक्त घरी किंवा टनल बंद केल्यानंतर दिसतात. Firebase Cloud Messaging वर बांधलेल्या ॲपमध्ये पुश चॅनेल हे स्वतंत्र, दीर्घकालीन आउटबाउंड कनेक्शन आहे, ब्राउझरने नुकतेच सिद्ध केलेला HTTPS मार्ग नाही. या तपासण्या क्रमाने करा आणि पहिल्या अयशस्वी तपासणीवर थांबा.

ॲप खरोखर FCM वापरते याची खात्री करा

प्रत्येक सूचना पुश नसते. काही ॲप स्थानिक पातळीवर नियोजित करते, काही 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 ला परवानगी देणारा फायरवॉलही पुश तोडू शकतो, आणि ॲपचे 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 प्रॉक्सीवरून नेता येत नाही. म्हणून कॉर्पोरेट वेब प्रॉक्सीवरून ब्राउझर चालणे पुश सॉकेटबद्दल काहीही सिद्ध करत नाही: हे वेगवेगळ्या मार्गांचे दोन वेगळे क्लायंट आहेत.

सॉकेट मारणारे निष्क्रिय टाइमआउट तपासा

FCM कनेक्शन संदेशांमध्ये उघडे राहते, त्यामुळे ते NAT आणि स्टेटफुल-इन्स्पेक्शन टाइमआउटसाठी संवेदनशील होते. Firebase चे मार्गदर्शन अशा धोरणे लागू असलेल्या ठिकाणी किमान 30 मिनिटांची निष्क्रिय सहनशीलता मागते. पाच मिनिटांचा सत्र टाइमआउट मॅपिंग गुपचूप काढून टाकतो, आणि फोन काहीतरी जागे केल्यावरच पुन्हा जोडतो, त्यामुळे संदेश गठ्ठ्यांमध्ये येतात किंवा अजिबात येत नाहीत.

फायरवॉल किंवा VPN गेटवेवरील सत्र सारणी वाचा आणि फोनचे 5228-5230 शी कनेक्शन शोधा. त्याचे उर्वरित आयुष्य दस्तऐवजी मूल्याशी तुलना करा. ते कमी असेल तर उपकरणावरील सर्व धोरणे बदलण्याऐवजी त्या पोर्टसाठी टाइमआउट वाढवा, कारण जागतिक टाइमआउट बदल न्याय्य ठरवणे कठीण आणि तो परत करणे अधिक कठीण.

पुश वितरण Wi-Fi आणि सेल्युलर दरम्यानच्या रोमिंगमध्ये एंडपॉइंट मॅपिंग टिकून राहण्यावरही अवलंबून आहे. एका इंटरफेसशी बांधलेले मॅपिंग दोन्ही नेटवर्क पोर्टना परवानगी देत असतानाही हस्तांतरणात वगळले जाऊ शकते.

VPN बायपास स्वीकारार्ह आहे का ते ठरवा

Android VPN क्लायंट ट्रॅफिकला टनल बायपास करू देतात, आणि तो बायपास परवानगी असल्यास FCM अंतर्निहित नेटवर्क वापरू शकते. त्या बाबतीत पुश चॅनेल एन्क्रिप्टेड राहते, पण आता टनलचा पत्ता घेत नाही, त्यामुळे VPN चे IP मास्किंग त्यावर लागू होत नाही. ही धोरणात्मक तडजोड आहे, बिघाड नाही.

तुमचे धोरण बायपास प्रतिबंधित करत असेल, तर टनल मार्गानेच कनेक्शन न्यावे लागेल: पोर्ट उघडे, टाइमआउट पुरेसे लांब, प्रॉक्सी वाटेत नाही. व्यवस्थापित सेवा गुपचूप वगळू नका आणि सूचना अव्यवस्थापित नेटवर्कवर चालतात म्हणून लॉकडाउन सैल करू नका. VPN चिन्ह सांगत नाही की कोणत्या सेवेने कोणता मार्ग निवडला

वितरण व प्रदर्शन वेगळे करा, मग एकदा चाचणी करा

परवानगी, चॅनेल सेटिंग्ज, त्रास देऊ नका आणि प्रत्येक ॲपचे टॉगल पोहोचवलेला संदेश दाखवायचा का हे ठरवतात. Android 13 आणि नंतर सूचना परवानगी रनटाइम अनुदान आहे, आणि नाकारलेले अनुदान अडवलेल्या पोर्टसारखेच दिसणारे मौन निर्माण करते. आलेला पण न दाखवलेला संदेश प्रदर्शनाची समस्या आहे; तो वेगळा हाताळा.

संदेश अव्यवस्थित पाठवण्याऐवजी एक नियंत्रित चाचणी करा. उपकरण, खाते आणि ॲप स्थिर ठेवा, ज्ञात टाइमस्टॅम्पसह एकच संदेश पाठवा, आणि VPN स्थितीची मंजूर बिना-VPN नेटवर्कशी तुलना करा. प्रत्येक फेरीसाठी logcat प्राप्ती वेळ आणि प्रदर्शन वेळ नोंदवा. वितरण वेगळे पण प्रदर्शन नाही असेल, तर नेटवर्क मार्ग हा चल आहे; दोन्ही सारखे असतील, तर ॲपकडे पाहत राहा.

नेटवर्क मालकाला पोर्ट, प्रॉक्सी मर्यादा, मोजलेला टाइमआउट आणि बायपास निर्णय एकाच टिपेत द्या. «VPN बंद करा» हा निष्कर्ष नाही, आणि सर्व Google रहदारीला परवानगी देणे ही मर्यादित दुरुस्ती नाही.

संबंधित लेख