Telefon korporativ VPN ilə normal gəzirsə də, bildirişlər gəlməyi dayandırır. Veb səhifələr açılır, tətbiq işə düşür, mesajlar isə yalnız evdə və ya tunel söndürüldükdən sonra görünür. Firebase Cloud Messaging üzərində qurulmuş tətbiq üçün push kanalı ayrıca uzunmüddətli çıxış bağlantısıdır, brauzerin sübut etdiyi HTTPS yolu deyil. Bu yoxlamaları sıra ilə aparın və ilk uğursuzluqda dayanın.

Tətbiqin həqiqətən FCM istifadə etdiyini təsdiqləyin

Hər bildiriş push deyil. Bəziləri tətbiq tərəfindən yerli olaraq planlaşdırılır, bəziləri HTTPS ilə sorğulanır, bəziləri isə Firebase ilə əlaqəsi olmayan təchizatçı kanalından gəlir. Tətbiqin manifesti və asılılıqları Firebase Messaging-i ehtiva edirsə, bildirişlər adətən FCM bağlantısı ilə gedir və müştəri kitabxanası qeydiyyatı gözlənilən teq altında loq edir.

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

Loqda qeydiyyat tokeni nəqli təsdiqləyir. O olmadan tətbiq səviyyəsində bildiriş boru xəttini sazlayırsınız və firewall dəyişiklikləri kömək etməyəcək. Bu fərq vacibdir, çünki çatdırılmış amma heç göstərilməmiş mesaj ilə heç gəlməmiş mesaj istifadəçi üçün eyni görünür.

Vebsaytı deyil, çıxış portlarını yoxlayın

FCM cihaz bağlantıları cihazdan başlayan TCP bağlantılarıdır və 5228 portuna, ehtiyat olaraq 5229 və 5230-a, son variant kimi 443-ə gedir. Gəzinti üçün 443-ə icazə verən firewall push-u yenə poza bilər, tətbiqin API domeninə icazə verən qayda isə mesajlaşma son nöqtələrini əhatə etmir, onlar ayrı xidmətlərdir.

Bunlar telefondan çıxan bağlantılardır. Cihazda və ya VPN şlüzündə daxil olan port dərc etmirsiniz, ona görə kimsə port yönləndirmə təklif edirsə, dizayn artıq səhvdir. İnternetdəki hər ünvana bir port açan qayda üçün də eyni şey keçərlidir: onu sənədləşdirilmiş təyinat larla məhdudlaşdırın.

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-in şəbəkə təlimatı da bildirir ki, FCM çatdırma protokolu adi HTTP proksisindən keçirilə bilməz. Brauzerin korporativ veb proksisindən keçməsi push soketi haqqında heç nə sübut etmir: bunlar fərqli müştərilər və fərqli yollardır.

Soketi öldürən boşdayanma taymautlarını yoxlayın

FCM bağlantısı mesajlar arasında açıq qalır, bu da onu NAT və vəziyyət yoxlama taymautlarına həssas edir. Firebase təlimatı belə siyasətlərdə ən azı 30 dəqiqə boşdayanma tolerantlığı tələb edir. Beş dəqiqəlik sessiya taymautu xəritələməni səssizcə silir və telefon yalnız oyandığında yenidən qoşulur, ona görə mesajlar dəstə-dəstə gəlir ya da heç gəlmir.

Firewall və ya VPN şlüzündə sessiya cədvəlini oxuyun və telefonun 5228-5230 ilə bağlantısını tapın. Qalan ömrünü sənədləşdirilmiş dəyərlə müqayisə edin. Qısadırsa, cihazdakı bütün siyasətləri dəyişmək əvəzinə həmin portlar üçün taymautu artırın.

Çatdırılma həm də son nöqtə xəritələməsinin Wi-Fi və mobil şəbəkə arasında keçiddə qalmasından asılıdır. Bir interfeysə bağlanmış xəritələmə, hər iki şəbəkə portlara icazə versə də, ötürmə zamanı düşə bilər.

VPN keçidinin məqbul olub-olmadığını qərarlaşdırın

Android VPN müştəriləri trafikin tuneli yan keçməsinə icazə verə bilər və bu keçidə icazə verildikdə FCM əsas şəbəkədən istifadə edə bilər. Bu halda push kanalı şifrəli qalır, lakin tunelin ünvanını daşımır, ona görə VPN-in IP gizlətməsi ona aid deyil. Bu siyasət mübadiləsidir, nasazlıq deyil.

Siyasətiniz keçidi qadağan edirsə, tunel yolu bağlantını daşımalıdır: portlar açıq, taymautlar kifayət qədər uzun, proksi yolda deyil. Bildirişlər idarə olunmayan şəbəkədə işləyir deyə idarə olunan xidməti səssizcə kənarlaşdırmayın. VPN ikonu hansı xidmətin hansı yolu seçdiyini demir.

Çatdırılmanı göstərmədən ayırın, sonra bir dəfə sınaqdan keçirin

İcazə, kanal ayarları, Rahatsız Etmə və tətbiq üzrə açarlar çatdırılmış mesajın göstərilib-göstərilməyəcəyini müəyyən edir. Android 13 və sonrasında bildiriş icazəsi işləmə vaxtı verilən icazədir və rədd edilmiş icazə bloklanmış porta tam bənzəyən səssizlik yaradır. Gəlmiş amma göstərilməmiş mesaj təqdimat problemidir, onu ayrıca araşdırın.

Mesajları təsadüfi göndərmək əvəzinə bir nəzarətli sınaq keçirin. Cihazı, hesabı və tətbiqi sabit saxlayın, məlum vaxt damğası olan bir mesaj göndərin və VPN vəziyyətini təsdiqlənmiş VPN-siz şəbəkə ilə müqayisə edin. Hər cəhd üçün logcat qəbul vaxtını və göstərmə vaxtını qeyd edin. Çatdırılma fərqlənib göstərmə eyni qalsa, şəbəkə yolu dəyişəndir; hər ikisi eynidirsə, tətbiqə baxmağa davam edin.

Şəbəkə sahibinə portları, proksi məhdudiyyətini, ölçülmüş taymautu və keçid qərarını bir qeyddə verin. VPN-i söndürün bir tapıntı deyil, bütün Google trafikinə icazə vermək də məhdud bir düzəliş deyil.

Əlaqəli məqalələr