Android-pusmelding kom nie deur op ’n VPN nie? Kontroleer hierdie punte
FCM hou sy eie uitgaande verbinding op poorte 5228-5230. Kontroleer die proxyreël, NAT-tydsperdatum en VPN-omleiding voordat jy aan meldingsinstellings raak.
Meldingen hou op arriveer op ’n foon wat andersins goed deur die korporatiewe VPN blaai. Webblaaie laai, die app maak oop, en boodskappe verskyn net by die huis of nadat die tonnel afgeskakel is. Vir ’n app wat op Firebase Cloud Messaging gebou is, is die pus-kanaal ’n aparte langdurige uitgaande verbinding, nie die HTTPS-pad wat die blaaier pas bewys het nie. Werk deur hierdie kontroles in volgorde en stop by die eerste een wat misluk.
Bevestig dat die app werklik FCM gebruik
Nie elke melding is ’n pus nie. Sommige word plaaslik deur die app geskeduleer, sommige word oor HTTPS opgevra, en sommige kom deur ’n verskafferkanaal wat niks met Firebase te doen het nie. As die app se manifest en afhanklikhede Firebase Messaging insluit, reis sy meldings gewoonlik oor die FCM-verbinding, en die kliëntbiblioteek teken registrasie onder ’n voorspelbare etiket aan.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase’n Registrasietoken in die log bevestig die transport. Sonder een debug jy ’n meldingspyplyn op app-vlak, en firewallveranderings sal nie help nie. Hierdie onderskeid is belangrik omdat ’n boodskap wat afgelewer maar nooit vertoon word en ’n boodskap wat nooit aankom nie vir die gebruiker identies lyk.
Kontroleer die uitgaande poorte, nie die webwerf nie
FCM-toestelverbindings is toestel-oorsprong TCP na poort 5228, met 5229 en 5230 as terugvalle en 443 as ’n laaste uitweg. ’n Firewall wat 443 vir blaai toelaat, kan steeds pus breek, en ’n reël wat ’n app se API-domein toelaat, dek nie die boodskap-eindpunte nie, want dit is aparte dienste.
Dit is uitgaande verbindings vanaf die foon. Jy publiseer nie ’n inkomende poort op die toestel of die VPN-gateway nie, so as iemand ’n poortaanstuur voorstel, het die ontwerp al verkeerd gegaan. Dieselfde geld vir ’n reël wat een poort vir elke adres op die internet oopmaak: beperk dit tot die gedokumenteerde bestemmings.
| 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 se netwerkriglyne sê ook dat die FCM-afleweringsprotokol nie oor ’n gewone HTTP-proxy gedra kan word nie. ’n Blaaier wat deur die korporatiewe webproxy slaag, bewys dus niks oor die pus-socket nie: die twee is verskillende kliënte met verskillende paaie.
Kontroleer die onaktiewe tydsperdatums wat die socket doodmaak
Die FCM-verbinding bly oop tussen boodskappe, wat dit sensitief maak vir NAT- en stateful-inspection-tydsperdatums. Firebase se riglyne vra ten minste 30 minute se onaktiewe verdraagsaamheid waar sulke beleide geld. ’n Sessie-tydsperdatum van vyf minute verwyder die kartering stilweg, en die foon herverbind net wanneer iets dit wakker maak, so boodskappe kom in sarsies of glad nie.
Lees die sessietabel op die firewall of VPN-gateway en vind die foon se verbinding na 5228-5230. Vergelyk die oorblywende leeftyd met die gedokumenteerde waarde. As dit korter is, verhoog die tydsperdatum vir daardie poorte eerder as om elke beleid op die toestel te verander, want ’n globale tydsperdatumverandering is moeilik om te regverdig en moeiliker om ongedaan te maak.
Pus-aflewering hang ook daarvan af dat die eindpunt-kartering ’n roaming tussen Wi-Fi en sellulêr oorleef. ’n Kartering wat aan een koppelvlak gekoppel is, kan by die oorhandiging laat val word selfs wanneer beide netwerke die poorte toelaat.
Besluit of VPN-omleiding aanvaarbaar is
Android-VPN-kliënte kan toelaat dat verkeer die tonnel omseil, en FCM kan die onderliggende netwerk gebruik wanneer daardie omleiding toegelaat word. Die pus-kanaal bly in daardie geval geënkripteer, maar dit dra nie meer die tonnel se adres nie, so die VPN se IP-verberging geld nie daarvoor nie. Dit is ’n beleidskompromis, nie ’n fout nie.
As jou beleid omleiding verbied, moet die tonnelpad die verbinding dra: poorte oop, tydsperdatums lank genoeg, proxy nie in die pad nie. Moenie stilweg ’n bestuurde diens uitsluit of die toesluiting verslap net omdat meldings op ’n onbestuurde netwerk werk nie. Die VPN-ikoon sê nie watter pad ’n gegewe diens gekies het nie.
Skei aflewering van vertoning en toets dan een keer
Toestemming, kanaalinstellings, Moenie Steur Nie en per-app-skakelaars bepaal of ’n afgelewerde boodskap vertoon word. Op Android 13 en later is die meldingstoestemming ’n looptydtoekenning, en ’n geweierde toekenning produseer stilte wat presies soos ’n geblokkeerde poort lyk. ’n Boodskap wat aangekom het maar nie vertoon is nie, is ’n voorstellingsprobleem; hanteer dit apart.
Voer een beheerde toets uit eerder as om boodskappe ad hoc te stuur. Hou die toestel, rekening en app vas, stuur ’n enkele boodskap met ’n bekende tydstempel, en vergelyk die VPN-toestand met ’n goedgekeurde nie-VPN-netwerk. Teken die logcat-ontvangstyd en die vertoningstyd vir elke lopie aan. As aflewering verskil maar vertoning nie, is die netwerkpad die veranderlike; as albei identies is, bly na die app kyk.
Gee die netwerk-eienaar die poorte, die proxybeperking, die gemete tydsperdatum en die omleidingsbesluit in een nota. Om die VPN af te skakel is nie ’n bevinding nie, en om alle Google-verkeer toe te laat is nie ’n beperkte oplossing nie.