Android-pushvarsel fungerer ikkje med VPN? Sjekk dette

Varsel sluttar å kome på ein telefon som elles surfar fint gjennom bedrifts-VPN-en. Nettsider lastar, appen opnar, og meldingar viser seg berre heime eller etter at tunnelen er slått av. I ein app bygd på Firebase Cloud Messaging er push-kanalen ei eiga langvarig utgåande tilkopling, ikkje HTTPS-ruta nettlesaren nettopp prova. Gå gjennom desse sjekkane i rekkjefølgje og stopp ved den første som feilar.

Stadfest at appen faktisk brukar FCM

Ikkje kvart varsel er ein push. Nokre planlegg appen lokalt, nokre blir henta over HTTPS, og nokre kjem via ein leverandørkanal som ikkje har noko med Firebase å gjere. Viss manifestet og avhengnadene til appen inneheld Firebase Messaging, går varsla vanlegvis over FCM-tilkoplinga, og klientbiblioteket loggar registreringa under ein føreseieleg tagg.

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

Eit registreringstoken i loggen stadfester transporten. Utan det feilsøkjer du ei varselpipeline på appnivå, og brannmur-endringar vil ikkje hjelpe. Denne skilnaden er viktig fordi ei levert melding som aldri blir vist og ei melding som aldri kjem ser like ut for brukaren.

Sjekk dei utgåande portane, ikkje nettstaden

FCM-einingskoplingar er TCP som eininga startar mot port 5228, med 5229 og 5230 som reserve og 443 som siste utveg. Ein brannmur som tillèt 443 for surfing kan framleis bryte push, og ein regel som tillèt API-domenet til ein app dekkjer ikkje endepunkta for meldingstenesta, som er eigne tenester.

Dette er utgåande tilkoplingar frå telefonen. Du publiserer ikkje ein inngåande port på eininga eller VPN-gatewayen, så viss nokon føreslår portvideresending, har designet alt gått gale. Det same gjeld ein regel som opnar éin port for alle adresser på internett: avgrens han til dei dokumenterte destinasjonane.

Nettverksrettleiinga til Firebase seier også at FCM-leveringsprotokollen ikkje kan berast over ein vanleg HTTP-proxy. At ein nettlesar fungerer gjennom bedriftswebproxyen beviser derfor ingenting om push-socketen: dei er to ulike klientar med ulike ruter.

Sjekk lediggangstidsavbrota som drep socketen

FCM-tilkoplinga held seg open mellom meldingar, noko som gjer ho følsam for NAT- og tilstandskontrolltidsavbrot. Rettleiinga til Firebase ber om minst 30 minuttars lediggangstoleranse der slik praksis gjeld. Eit sesjonstidsavbrot på fem minutt fjernar mappinga stille, og telefonen koplar berre til att når noko vekkjer han, så meldingar kjem i puljar eller ikkje i det heile.

Les sesjonstabellen på brannmuren eller VPN-gatewayen og finn tilkoplinga til telefonen mot 5228-5230. Samanlikn gjenverande levetid med den dokumenterte verdien. Er ho kortare, auk tidsavbrotet for desse portane i staden for å endre alle retningslinjer på eininga, fordi ei global tidsavbrotendring er vanskeleg å forsvare og endå vanskelegare å angre.

Push-levering er også avhengig av at endepunktmappinga overlever roaming mellom Wi-Fi og mobilnett. Ei mapping knytt til eitt grensesnitt kan bli droppa ved overleveringa sjølv når begge netta tillèt portane.

Avgjer om VPN-omgjæring er akseptabelt

Android VPN-klientar kan tillate trafikk å omgå tunnelen, og FCM kan bruke det underliggjande nettet når den omgjæringa er tillaten. Push-kanalen blir verande kryptert i så fall, men han ber ikkje lenger adressa til tunnelen, så IP-maskeringa til VPN-en gjeld ikkje for han. Det er eit kompromiss i retningslinjene, ikkje ein feil.

Viss retningslinjene dine forbyr omgjæring, må tunnelruta bere tilkoplinga: portar opne, tidsavbrot lange nok, proxy ute av vegen. Ikkje utelat ein administrert teneste i det stille og ikkje lett på låsen berre fordi varsel fungerer på eit uadministrert nett. VPN-ikonet seier ikkje kva rute ei gjeven teneste valde

Skil levering frå vising, og test éin gong

Løyve, kanalinnstillingar, Ikkje forstyrr og brytarar per app avgjer om ei levert melding blir vist. På Android 13 og nyare er varselløyvet ei godkjenning ved køyring, og ei avslått godkjenning gir stillheit som ser nøyaktig ut som ein blokkert port. Ei melding som kom men ikkje vart vist, er eit visingsproblem; handsam det separat.

Gjer éin kontrollert test i staden for å sende meldingar vilkårleg. Hald eininga, kontoen og appen fast, send éi melding med eit kjent tidsstempel, og samanlikn VPN-tilstanden med eit godkjent nett utan VPN. Noter mottakstida i logcat og visingstida for kvar køyring. Viss leveringa er ulik men visinga ikkje, er nettverksruta variabelen; viss begge er like, hald fram med å sjå på appen.

Gi nettverkseigaren portane, proxyavgrensinga, det målte tidsavbrotet og omgjæringsavgjerda i eitt notat. «Slå av VPN-en» er ikkje eit funn, og å tillate all Google-trafikk er ikkje ei avgrensa retting.