Android-en push jakinarazpenak ez dabiltza VPN-rekin? Begiratu hauek
FCM-k bere irteerako konexioa mantentzen du 5228-5230 portuetan. Egiaztatu proxyaren araua, NAT denbora-muga eta VPNaren bypassa jakinarazpenen ezarpenak ukitu aurretik.
Jakinarazpenak iristeari uzten diote, bestela enpresa VPNaren bidez ondo nabigatzen duen telefono batean. Web orriak kargatzen dira, aplikazioa irekitzen da eta mezuak etxean bakarrik edo tunela itzalita gero agertzen dira. Firebase Cloud Messaging-en oinarritutako aplikazio batean, push kanala irteerako konexio luze independentea da, ez nabigatzaileak une horretan frogatu duen HTTPS bidea. Egin egiaztapen hauek hurrenez hurren eta gelditu lehenengoan huts egiten duenean.
Egiaztatu aplikazioak FCM erabiltzen duela benetan
Jakinarazpen guztiak ez dira push. Batzuk aplikazioak tokian bertan programatzen ditu, beste batzuk HTTPS bidez galdetzen dira eta beste batzuk Firebase-rekin zerikusirik ez duen hornitzailearen kanal batetik iristen dira. Aplikazioaren manifestuak eta menpekotasunek Firebase Messaging badute, haren jakinarazpenak FCM konexiotik bidaiatzen dute normalean, eta bezero-liburutegiak erregistroa etiketa aurreikusgarri baten pean erregistratzen du.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseLogeko erregistro-token batek garraioaren berri ematen du. Hura gabe, aplikazio mailako jakinarazpen-bidea ari zara arazten, eta suebakiko aldaketek ez dute lagunduko. Bereizketa honek garrantzia du, entregatutako mezu bat inoiz erakusten ez dena eta inoiz iristen ez den mezu bat berdinak baitira erabiltzailearentzat.
Begiratu irteerako portuak, ez webgunea
FCM gailu-konexioak gailuak sortutako TCP dira 5228 portura, 5229 eta 5230 ordezko gisa eta 443 azken aukera gisa. Nabigatzeko 443 baimetzen duen suebaki batek push-a honda dezake oraindik, eta aplikazio baten API domeinua baimentzen duen arauak ez ditu mezularitzako endpointak estaltzen, zerbitzu bereiziak baitira.
Hauek telefonotik irteten diren konexioak dira. Ez duzu sarrerako porturik argitaratzen gailuan edo VPN atean, beraz norbait portu-birbidalketa bat iradokitzen badu, diseinua gaizki joan da jada. Gauza bera gertatzen da interneteko helbide guztiei portu bat irekitzen dien arau batekin: mugatu dokumentatutako helmuguetara.
| 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-ren sare-gida-k ere dio FCM entrega-protokoloa ezin dela ohiko HTTP proxy baten bidez garraiatu. Beraz, nabigatzaile batek enpresa web proxya gainditzeak ez du ezer frogatzen push socketari buruz: bi bezero desberdin dira, bide desberdinak dituztenak.
Begiratu socketa hiltzen duten denbora-muga inaktiboak
FCM konexioa irekita geratzen da mezuen artean, eta horrek NAT eta egoera-ikuskapeneko denbora-mugen aurrean sentikor egiten du. Firebase-ren gidak gutxienez 30 minutuko inaktibitate-tolerantzia eskatzen du politika horiek aplikatzen diren lekuetan. Bost minutuko saio-denbora-muga batek mapaketa isilean kentzen du, eta telefonak berriro konektatzen da zerbait esnatzen duenean soilik, beraz mezuak boladaka iristen dira edo ez dira iristen.
Irakurri suebakiaren edo VPN atearen saio-taula eta aurkitu telefonoaren konexioa 5228-5230 portuetara. Alderatu geratzen zaion bizitza dokumentatutako balioarekin. Laburragoa bada, handitu portu horien denbora-muga, gailuko politika guztiak aldatu beharrean, denbora-muga globala aldatzea zaila baita justifikatzen eta are zailagoa desegiten.
Push entrega ere endpoint mapaketak Wi-Fi eta mugikorreko sarearen arteko roaming batean iraun behar du. Interfaze bakar bati lotutako mapaketa bat gal daiteke eskualdatzean, bi sareek portuak baimentzen dituztenean ere.
Erabaki VPN bypassa onargarria den
Android VPN bezeroek trafikoak tunela saihesteko aukera eman dezakete, eta FCM-ek azpiko sarea erabil dezake bypass hori baimentzen denean. Kasu horretan push kanalak enkriptatuta jarraitzen du, baina ez du tunelaren helbidea eramaten, beraz VPNaren IP maskaratzea ez zaio aplikatzen. Politika-erabakia da, ez funtzionamendu-akatsa.
Zure politikak bypassa debekatzen badu, tunelaren bideak konexioa garraiatu behar du: portuak irekita, denbora-mugak nahikoa luze, proxya erdian ez. Ez ezazu isilean kudeatutako zerbitzurik kanpo utzi ezta blokeoa lasaitu ere, jakinarazpenak kudeatu gabeko sare batean funtzionatzen dutelako soilik. VPNaren ikonoak ez du esaten zer bide aukeratu duen zerbitzu jakin batek
Bereizi entrega erakusketatik, eta probatu behin
Baimenak, kanalaren ezarpenek, Ez molestatu-k eta aplikazio bakoitzeko etengailuek erabakitzen dute entregatutako mezu bat erakutsi edo ez. Android 13 eta geroago jakinarazpen-baimena exekuzio-denborako emakida da, eta ukatutako emakida batek portu blokeatu baten itxura zehatza duen isiltasuna sortzen du. Iritsi baina erakutsi ez zen mezu bat aurkezpen-arazoa da; trata ezazu bereizita.
Egin proba kontrolatu bat, mezuak modu arbitrarioan bidali beharrean. Eutsi gailua, kontua eta aplikazioa finko, bidali mezu bakarra ezagututako denbora-marka batekin, eta konparatu VPN egoera onartutako VPNik gabeko sare batekin. Erregistratu logcat-eko harrera-ordua eta erakusteko ordua exekuzio bakoitzean. Entrega desberdina bada baina erakustea ez, sare-bidea da aldagaia; biak berdinak badira, jarraitu aplikazioari begira.
Eman sarearen arduradunari portuak, proxyaren muga, neurtutako denbora-muga eta bypass erabakia ohar bakarrean. «Itzali VPN-a» ez da aurkikuntza bat, eta Google trafiko guztia baimentzea ez da konponbide mugatua.