Android-pushvarsler virker ikke over VPN? Sjekk disse punktene

Varsler slutter å dukke opp på en telefon som ellers fungerer fint gjennom bedriftens VPN. Nettsider lastes, appen åpnes, men meldinger vises bare hjemme eller etter at tunnelen er slått av. For en app som bygger på Firebase Cloud Messaging, er push-kanalen en egen, langvarig utgående forbindelse, ikke den HTTPS-ruten nettleseren nettopp beviste. Gå gjennom kontrollene nedenfor i rekkefølge, og stopp ved den første som svikter.

Kontroller at appen virkelig bruker FCM

Ikke alle varsler er push. Noen planlegges lokalt i appen, noen hentes via HTTPS, og noen kommer gjennom en leverandørkanal uten forbindelse til Firebase. Dersom appens manifest og avhengigheter omfatter Firebase Messaging, går varslene normalt over FCM-forbindelsen, og klientbiblioteket logger registreringen under en forutsigbar tagg.

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

Et registreringstoken i loggen bekrefter transporten. Mangler det, feilsøker du en varselkjede på appnivå, og brannmurjusteringer vil ikke hjelpe. Forskjellen er viktig fordi en levert melding som aldri vises, og en melding som aldri ankommer, oppleves likt av brukeren.

Sjekk de utgående portene, ikke nettstedet

FCM-tilkoblinger fra enheter er TCP som enheten selv starter mot port 5228, med 5229 og 5230 som reserve og 443 som siste utvei. En brannmur som slipper gjennom 443 for surfing kan likevel bryte push, og en regel som tillater en apps API-domene dekker ikke meldingsendepunktene, som er egne tjenester.

Dette er utgående forbindelser fra telefonen. Du publiserer ingen inngående port på enheten eller på VPN-gatewayen, så dersom noen foreslår portvideresending, er designet allerede feil. Det samme gjelder en regel som åpner én port mot alle adresser på internett: begrens den til de dokumenterte målene.

Firebases veiledning for nettverk slår også fast at FCM-leveringsprotokollen ikke kan fraktes over en vanlig HTTP-proxy. At en nettleser virker gjennom bedriftens webproxy, beviser derfor ingenting om push-socketen: dette er to forskjellige klienter med forskjellige ruter.

Sjekk lediggangstidsavbruddene som dreper socketen

FCM-forbindelsen holdes åpen mellom meldinger, og er derfor følsom for tidsavbrudd i NAT og tilstandskontroll. Firebases veiledning anbefaler minst 30 minutters toleranse for lediggang der slik praksis gjelder. Et sesjonstidsavbrudd på fem minutter fjerner mappingen uten varsel, og telefonen kobler seg bare til igjen når noe vekker den, derfor kommer meldinger i rykk eller ikke i det hele tatt.

Les sesjonstabellen på brannmuren eller VPN-gatewayen, og finn telefonens forbindelse mot 5228-5230. Sammenlign gjenstående levetid med den dokumenterte verdien. Er den kortere, øker du tidsavbruddet for disse portene fremfor å endre alle retningslinjer på enheten, siden en global endring er vanskelig å begrunne og enda vanskeligere å reversere.

Push-leveringen avhenger også av at endepunktmappingen overlever roaming mellom Wi-Fi og mobilnett. En mapping som er knyttet til ett grensesnitt, kan falle bort ved overgangen selv om begge nettverkene tillater portene.

Bestem om VPN-omgåelse er akseptabelt

Android VPN-klienter kan tillate at trafikk går utenom tunnelen, og FCM kan bruke det underliggende nettverket når en slik omgåelse er tillatt. Push-kanalen forblir kryptert i dette tilfellet, men den bærer ikke lenger tunnelens adresse, så VPN-ens IP-maskering gjelder ikke. Dette er en avveining i retningslinjene, ikke en feil.

Dersom retningslinjene forbyr omgåelse, må tunnelruten bære forbindelsen: portene åpne, tidsavbruddene lange nok, og proxyen ute av veien. Ikke utelat en administrert tjeneste i stillhet, og ikke lemp på låsen bare fordi varsler fungerer på et nettverk uten administrasjon. VPN-ikonet viser ikke hvilken rute en bestemt tjeneste valgte

Skille levering fra visning, og test én gang

Tillatelse, kanalinnstillinger, Ikke forstyrr og brytere per app avgjør om en levert melding blir vist. Fra Android 13 gis varseltillatelsen ved kjøring, og en avslått tillatelse gir stillhet som ser nøyaktig ut som en blokkert port. En melding som ankom men ikke ble vist, er et visningsproblem og bør håndteres separat.

Utfør én kontrollert test i stedet for å sende meldinger tilfeldig. Hold enhet, konto og app uendret, send én melding med kjent tidsstempel, og sammenlign VPN-situasjonen med et godkjent nettverk uten VPN. Noter mottakstid i logcat og visningstid for hver kjøring. Er leveringen ulik men visningen lik, er nettverksruten variabelen; er begge like, fortsett å undersøke appen.

Gi nettverksansvarlig portene, proxybegrensningen, det målte tidsavbruddet og beslutningen om omgåelse i ett notat. «Slå av VPN» er ikke et funn, og å tillate all Google-trafikk er ikke en avgrenset rettelse.