Android-ի push ծանուցումները չեն աշխատում VPN-ով? Ստուգեք սրանք
FCM-ը պահում է իր սեփական ելքային կապը 5228-5230 պորտերում։ Ստուգեք proxy-ի կանոնը, NAT-ի ժամկետը և VPN-ի շրջանցումը նախքան ծանուցումների կարգավորումներին դիպչելը։
Ծանուցումները դադարում են հասնել մի հեռախոսի, որը մնացած դեպքերում լավ զննում է կորպորատիվ VPN-ով։ Վեբ էջերը բեռնվում են, հավելվածը բացվում է, և հաղորդագրությունները հայտնվում են միայն տանը կամ թունելն անջատելուց հետո։ Firebase Cloud Messaging-ի վրա կառուցված հավելվածում push ալիքը առանձին, երկարատև ելքային կապ է, ոչ այն HTTPS ուղին, որը զննարկիչը հենց նոր ապացուցեց։ Անցեք այս ստուգումները հերթականությամբ և կանգ առեք առաջինում, որը ձախողվում է։
Հաստատեք, որ հավելվածն իսկապես օգտագործում է FCM
Ամեն ծանուցում push չէ։ Ոմանց հավելվածը պլանավորում է տեղում, ոմանք հարցվում են HTTPS-ով, իսկ ոմանք գալիս են մատակարարի ալիքով, որը կապ չունի Firebase-ի հետ։ Եթե հավելվածի manifest-ը և կախվածությունները ներառում են Firebase Messaging, նրա ծանուցումները սովորաբար անցնում են FCM կապով, և հաճախորդի գրադարանը գրանցումը մուտքագրում է կանխատեսելի պիտակի տակ։
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseՄատյանում գրանցման token-ը հաստատում է փոխադրումը։ Առանց դրա դուք կարգաբերում եք հավելվածի մակարդակի ծանուցումների խողովակաշար, և firewall-ի փոփոխությունները չեն օգնի։ Այս տարբերությունը կարևոր է, որովհետև հասցված, բայց երբեք չցուցադրվող հաղորդագրությունը և երբեք չհասնող հաղորդագրությունը օգտատիրոջը նույնն են թվում։
Ստուգեք ելքային պորտերը, ոչ թե կայքը
FCM սարքի կապերը սարքից սկսված TCP են դեպի 5228 պորտ, 5229-ը և 5230-ը որպես պահուստ, իսկ 443-ը՝ որպես վերջին տարբերակ։ Firewall-ը, որը թույլ է տալիս 443-ը զննելու համար, դեռ կարող է կոտրել push-ը, և հավելվածի API դոմեյնը թույլատրող կանոնը չի ծածկում հաղորդագրությունների վերջնակետերը, որոնք առանձին ծառայություններ են։
Սրանք ելքային կապեր են հեռախոսից։ Դուք մուտքային պորտ չեք հրապարակում սարքում կամ VPN դարպասում, ուստի եթե ինչ-որ մեկը առաջարկում է պորտի փոխանցում, դիզայնն արդեն սխալ է գնացել։ Նույնը վերաբերում է կանոնին, որը մեկ պորտ բացում է ինտերնետի բոլոր հասցեների համար․ սահմանափակեք այն փաստաթղթավորված նպատակակետերով։
| 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-ի ցանցային ուղեցույցը-ը նույնպես նշում է, որ FCM-ի առաքման արձանագրությունը հնարավոր չէ փոխանցել սովորական HTTP proxy-ով։ Ուստի զննարկիչի աշխատանքը կորպորատիվ վեբ proxy-ով ոչինչ չի ապացուցում push socket-ի մասին․ դրանք երկու տարբեր հաճախորդներ են՝ տարբեր ուղիներով։
Ստուգեք պարապուրդի ժամկետները, որոնք սպանում են socket-ը
FCM կապը բաց է մնում հաղորդագրությունների միջև, ինչը զգայուն է դարձնում NAT-ի և վիճակային ստուգման ժամկետների նկատմամբ։ Firebase-ի ուղեցույցը պահանջում է առնվազն 30 րոպե պարապուրդի հանդուրժողականություն այնտեղ, որտեղ նման քաղաքականություններ են գործում։ Հինգ րոպեի session ժամկետը լուռ հեռացնում է քարտեզագրումը, և հեռախոսը նորից միանում է միայն այն ժամանակ, երբ ինչ-որ բան արթնացնում է այն, ուստի հաղորդագրությունները գալիս են պոռթկումներով կամ ընդհանրապես չեն գալիս։
Կարդացեք firewall-ի կամ VPN դարպասի session աղյուսակը և գտեք հեռախոսի կապը 5228-5230-ին։ Համեմատեք նրա մնացած կյանքի տևողությունը փաստաթղթավորված արժեքի հետ։ Եթե այն ավելի կարճ է, ավելացրեք ժամկետը այդ պորտերի համար՝ սարքի բոլոր քաղաքականությունները փոխելու փոխարեն, որովհետև գլոբալ ժամկետի փոփոխությունը դժվար է հիմնավորել և էլ ավելի դժվար՝ հետարկել։
Push-ի առաքումը նաև կախված է նրանից, թե վերջնակետի քարտեզագրումը կդիմանա Wi-Fi-ի և բջջային ցանցի միջև ռոումինգին։ Մեկ ինտերֆեյսին կապված քարտեզագրումը կարող է կորչել անցման պահին, նույնիսկ երբ երկու ցանցերն էլ թույլ են տալիս պորտերը։
Որոշեք՝ VPN-ի շրջանցումը ընդունելի է
Android VPN հաճախորդները կարող են թույլ տալ, որ երթևեկությունը շրջանցի թունելը, և FCM-ը կարող է օգտագործել հիմքում ընկած ցանցը, երբ այդ շրջանցումը թույլատրված է։ Այդ դեպքում push ալիքը մնում է գաղտնագրված, բայց այլևս չի կրում թունելի հասցեն, ուստի VPN-ի IP քողարկումը դրա վրա չի տարածվում։ Սա քաղաքականության փոխզիջում է, ոչ թե անսարքություն։
Եթե ձեր քաղաքականությունն արգելում է շրջանցումը, թունելի ուղին պետք է կրի կապը․ պորտերը բաց, ժամկետները բավական երկար, proxy-ն ճանապարհին չէ։ Մի կողմ չդնեք կառավարվող ծառայությունը լուռ և մի թուլացրեք կողպումը միայն այն պատճառով, որ ծանուցումները աշխատում են չկառավարվող ցանցում։ VPN-ի պատկերակը չի ասում, թե որ ուղին է ընտրել տվյալ ծառայությունը
Առանձնացրեք առաքումը ցուցադրումից, ապա փորձարկեք մեկ անգամ
Թույլտվությունը, ալիքի կարգավորումները, Մի անհանգստացրեք և յուրաքանչյուր հավելվածի անջատիչները որոշում են՝ ցուցադրվելու է հասցված հաղորդագրությունը։ Android 13-ում և ավելի նորերում ծանուցումների թույլտվությունը գործարկման պահի տրամադրում է, և մերժված տրամադրումը ստեղծում է լռություն, որը ճիշտ արգելափակված պորտի տեսք ունի։ Հասած, բայց չցուցադրված հաղորդագրությունը ներկայացման խնդիր է․ զբաղվեք դրանով առանձին։
Արեք մեկ վերահսկվող փորձարկում՝ հաղորդագրություններ պատահական ուղարկելու փոխարեն։ Պահեք սարքը, հաշիվը և հավելվածը անփոփոխ, ուղարկեք մեկ հաղորդագրություն հայտնի ժամադրոշմով և համեմատեք VPN-ի վիճակը հաստատված առանց VPN ցանցի հետ։ Գրանցեք logcat-ի ստացման ժամանակը և ցուցադրման ժամանակը յուրաքանչյուր աշխատանքի համար։ Եթե առաքումը տարբերվում է, իսկ ցուցադրումը՝ ոչ, ցանցային ուղին է փոփոխականը․ եթե երկուսն էլ նույնն են, շարունակեք նայել հավելվածին։
Ցանցի պատասխանատուին տվեք պորտերը, proxy-ի սահմանափակումը, չափված ժամկետը և շրջանցման որոշումը մեկ նշումով։ «Անջատիր VPN-ը» արդյունք չէ, և ամբողջ Google երթևեկությունը թույլատրելը սահմանափակ լուծում չէ։