Android push bildirishnomalari VPN bilan ishlamayaptimi? Bularni tekshiring
FCM o'zining chiquvchi ulanishini 5228-5230 portlarida ushlab turadi. Bildirishnoma sozlamalariga tegishdan oldin proksi qoidasi, NAT muddati va VPN chetlab o'tishni tekshiring.
Boshqa hamma narsada korporativ VPN orqali yaxshi ko'rishadigan telefonda bildirishnomalar kela olmay qoladi. Veb-sahifalar yuklanadi, ilova ochiladi, xabarlar esa faqat uyda yoki tunnel o'chirilgandan keyin paydo bo'ladi. Firebase Cloud Messaging asosidagi ilovada push kanali alohida, uzoq umrli chiquvchi ulanish bo'lib, brauzer hozir isbotlagan HTTPS yo'li emas. Bu tekshiruvlarni tartib bilan bajaring va birinchi muvaffaqiyatsizlikda to'xtang.
Ilova haqiqatan FCM ishlatishini tasdiqlang
Har bir bildirishnoma push emas. Ba'zilarini ilova mahalliy rejalashtiradi, ba'zilari HTTPS orqali so'raladi, yana ba'zilari Firebase bilan aloqasi yo'q sotuvchi kanali orqali keladi. Agar ilovaning manifesti va bog'liqliklari Firebase Messagingni o'z ichiga olsa, uning bildirishnomalari odatda FCM ulanishi orqali o'tadi, va mijoz kutubxonasi ro'yxatdan o'tishni oldindan aytish mumkin bo'lgan teg ostida qayd etadi.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseJurnaldagi ro'yxatdan o'tish tokeni tashishni tasdiqlaydi. Usiz siz ilova darajasidagi bildirishnoma quvurini tuzatyapsiz va xavfsizlik devori o'zgarishlari yordam bermaydi. Bu farq muhim, chunki yetkazilgan, lekin hech qachon ko'rsatilmagan xabar va hech qachon kelmaydigan xabar foydalanuvchiga bir xil ko'rinadi.
Chiquvchi portlarni tekshiring, veb-saytni emas
FCM qurilma ulanishlari qurilmadan boshlanadigan TCP bo'lib 5228 portiga boradi, 5229 va 5230 zaxira, 443 esa oxirgi chora sifatida. Ko'rish uchun 443 ga ruxsat beruvchi xavfsizlik devori ham pushni buzishi mumkin, va ilovaning API domeniga ruxsat beruvchi qoida alohida xizmatlar bo'lgan xabar so'nggi nuqtalarini qamrab olmaydi.
Bular telefondan chiquvchi ulanishlar. Siz qurilmada yoki VPN darvozasida kiruvchi port e'lon qilmaysiz, shuning uchun kimdir port yo'naltirishni taklif qilsa, dizayn allaqachon noto'g'ri. Xuddi shu narsa bir portni internetdagi barcha manzillarga ochuvchi qoidaga ham tegishli: uni hujjatlashtirilgan manzillar bilan cheklang.
| Port | Role | What to verify |
|---|---|---|
| 5228 | Primary FCM connection | Outbound allowed and session state kept |
| 5229, 5230 | Fallback ports | Often missing from hand-written allowlists |
| 443 | Last-resort fallback | Works only if the client actually falls back |
| HTTP proxy | Not a supported FCM transport | Proxy exclusion or bypass, not a port rule |
Firebase tarmoq yo'riqnomasi shuningdek FCM yetkazib berish protokolini oddiy HTTP proksi orqali o'tkazib bo'lmaydi, deydi. Shuning uchun brauzerning korporativ veb-proksi orqali ishlashi push soketi haqida hech narsani isbotlamaydi: bular turli yo'llarga ega ikki xil mijoz.
Soketni o'ldiradigan bo'sh turish muddatlarini tekshiring
FCM ulanishi xabarlar orasida ochiq qoladi, bu uni NAT va holat tekshiruvi muddatlariga sezgir qiladi. Firebase yo'riqnomasi bunday siyosatlar qo'llaniladigan joylarda kamida 30 daqiqa bo'sh turishga chidamlilikni so'raydi. Besh daqiqalik sessiya muddati xaritalashni jimgina olib tashlaydi va telefon faqat biror narsa uni uyg'otganda qayta ulanadi, shuning uchun xabarlar to'da bo'lib keladi yoki umuman kelmaydi.
Xavfsizlik devori yoki VPN darvozasidagi sessiyalar jadvalini o'qing va telefonning 5228-5230 ga ulanishini toping. Uning qolgan umrini hujjatlashtirilgan qiymat bilan solishtiring. Agar qisqaroq bo'lsa, qurilmadagi barcha siyosatlarni o'zgartirish o'rniga o'sha portlar uchun muddatni oshiring, chunki global muddat o'zgarishini asoslash qiyin, uni bekor qilish esa undan ham qiyin.
Push yetkazib berish, shuningdek, so'nggi nuqta xaritalashi Wi-Fi va uyali tarmoq o'rtasidagi roumingda omon qolishiga bog'liq. Bitta interfeysga bog'langan xaritalash ikkala tarmoq portlarga ruxsat bergan taqdirda ham o'tishda bekor qilinishi mumkin.
VPNni chetlab o'tish maqbulmi, shuni hal qiling
Android VPN mijozlari trafikning tunneldan chetlab o'tishiga ruxsat berishi mumkin, va bu chetlashuvga ruxsat berilganda FCM ostidagi tarmoqdan foydalanishi mumkin. Bunday holda push kanali shifrlangan holda qoladi, lekin endi tunnel manzilini tashimaydi, shuning uchun VPNning IP yashirilishi unga taalluqli emas. Bu siyosat kompromissi, nosozlik emas.
Agar siyosatingiz chetlashuvni taqiqlasa, tunnel yo'li ulanishni tashishi kerak: portlar ochiq, muddatlar yetarlicha uzoq, proksi yo'lda to'sqinlik qilmasligi kerak. Boshqariladigan xizmatni jimgina chetlab o'tmang va bildirishnomalar boshqarilmaydigan tarmoqda ishlaydi deb qulfni bo'shashtirmang. VPN belgisi qaysi xizmat qaysi yo'lni tanlaganini aytmaydi
Yetkazib berishni ko'rsatishdan ajrating, keyin bir marta sinab ko'ring
Ruxsat, kanal sozlamalari, Bezovta qilmang va har bir ilova kaliti yetkazilgan xabar ko'rsatilishini hal qiladi. Android 13 va undan yuqorisida bildirishnoma ruxsati ish vaqtida beriladi, rad etilgan ruxsat esa bloklangan portga aynan o'xshab ko'rinadigan sukunat tug'diradi. Kelgan, lekin ko'rsatilmagan xabar taqdimot muammosi; uni alohida ko'rib chiqing.
Xabarlarni o'zboshimchalik bilan yuborish o'rniga bitta nazorat ostidagi sinov o'tkazing. Qurilma, hisob va ilovani o'zgarmas holda ushlab turing, ma'lum vaqt belgisi bilan bitta xabar yuboring va VPN holatini tasdiqlangan VPNsiz tarmoq bilan solishtiring. Har bir ishga tushirish uchun logcat qabul qilish vaqtini va ko'rsatish vaqtini yozib oling. Agar yetkazib berish boshqacha bo'lsa-yu ko'rsatish bo'lmasa, tarmoq yo'li o'zgaruvchi; agar ikkalasi bir xil bo'lsa, ilovani ko'rishda davom eting.
Tarmoq egasiga portlar, proksi cheklovi, o'lchangan muddat va chetlashuv qarorini bitta eslatmada bering. «VPNni o'chir» topilma emas, va barcha Google trafigiga ruxsat berish cheklangan tuzatish emas.