Android-pushvarsler virker ikke med VPN? Sjekk dette

Varsler slutter å komme på en telefon som ellers surfer fint gjennom bedrifts-VPN-en. Nettsider lastes, appen åpnes, og meldinger vises bare hjemme eller etter at tunnelen er slått av. I en app bygget på Firebase Cloud Messaging er push-kanalen en separat langvarig utgående forbindelse, ikke HTTPS-ruten nettleseren nettopp beviste. Gå gjennom disse sjekkene i rekkefølge og stopp ved den første som feiler.

Bekreft at appen faktisk bruker FCM

Ikke hvert varsel er en push. Noen planlegges lokalt av appen, noen hentes over HTTPS, og noen kommer via en leverandørkanal som ikke har noe med Firebase å gjøre. Hvis appens manifest og avhengigheter inkluderer Firebase Messaging, går varslene vanligvis 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. Uten det feilsøker du en varselpipe på appnivå, og brannmur-endringer vil ikke hjelpe. Denne forskjellen betyr noe fordi en levert melding som aldri vises og en melding som aldri kommer ser like ut for brukeren.

Sjekk de utgående portene, ikke nettstedet

FCM-enhetsforbindelser er TCP som enheten starter mot port 5228, med 5229 og 5230 som reserver og 443 som siste utvei. En brannmur som tillater 443 for surfing kan fortsatt bryte push, og en regel som tillater en apps API-domene dekker ikke meldingstjenestens endepunkter, som er separate tjenester.

Dette er utgående forbindelser fra telefonen. Du publiserer ikke en inngående port på enheten eller VPN-gatewayen, så hvis noen foreslår portvideresending, har designet allerede gått galt. Det samme gjelder en regel som åpner én port for alle adresser på internett: begrens den til de dokumenterte destinasjonene.

Firebases nettverksveiledning sier også at FCM-leveringsprotokollen ikke kan bæres over en vanlig HTTP-proxy. At en nettleser fungerer gjennom bedriftens webproxy beviser derfor ingenting om push-socketen: de er to forskjellige klienter med forskjellige ruter.

Sjekk lediggangstidsavbruddene som dreper socketen

FCM-forbindelsen holdes åpen mellom meldinger, noe som gjør den følsom for NAT- og tilstandskontrolltidsavbrudd. Firebases veiledning ber om minst 30 minutters lediggangstoleranse der slik praksis gjelder. Et sesjonstidsavbrudd på fem minutter fjerner mappingen stille, og telefonen kobler bare til igjen når noe vekker den, så meldinger kommer i puljer eller ikke i det hele tatt.

Les sesjonstabellen på brannmuren eller VPN-gatewayen og finn telefonens forbindelse til 5228-5230. Sammenlign gjenværende levetid med den dokumenterte verdien. Er den kortere, øk tidsavbruddet for disse portene i stedet for å endre alle retningslinjer på enheten, fordi en global tidsavbruddsendring er vanskelig å forsvare og enda vanskeligere å angre.

Push-levering avhenger også av at endepunktmappingen overlever roaming mellom Wi-Fi og mobilnett. En mapping knyttet til ett grensesnitt kan droppes ved overleveringen selv når begge nettverkene tillater portene.

Avgjør om VPN-omgåelse er akseptabelt

Android VPN-klienter kan tillate trafikk å omgå tunnelen, og FCM kan bruke det underliggende nettverket når den omgåelsen er tillatt. Push-kanalen forblir kryptert i så fall, men den bærer ikke lenger tunnelens adresse, så VPN-ens IP-maskering gjelder ikke for den. Det er et kompromiss i retningslinjene, ikke en feil.

Hvis retningslinjene dine forbyr omgåelse, må tunnelruten bære forbindelsen: porter åpne, tidsavbrudd lange nok, proxy ute av veien. Ikke utelat en administrert tjeneste i stillhet og ikke lett på låsen bare fordi varsler fungerer på et uadministrert nettverk. VPN-ikonet sier ikke hvilken rute en gitt tjeneste valgte

Skill levering fra visning, og test én gang

Tillatelse, kanalinnstillinger, Ikke forstyrr og brytere per app avgjør om en levert melding vises. På Android 13 og nyere er varseltillatelsen en kjøretidsgodkjenning, og en avslått godkjenning gir stillhet som ser nøyaktig ut som en blokkert port. En melding som kom men ikke ble vist, er et presentasjonsproblem; håndter det separat.

Gjør én kontrollert test i stedet for å sende meldinger vilkårlig. Hold enheten, kontoen og appen fast, send én melding med et kjent tidsstempel, og sammenlign VPN-tilstanden med et godkjent nettverk uten VPN. Noter mottakstiden i logcat og visningstiden for hver kjøring. Hvis leveringen er forskjellig men visningen ikke, er nettverksruten variabelen; hvis begge er like, fortsett å se på appen.

Gi nettverkseieren portene, proxybegrensningen, det målte tidsavbruddet og omgåelsesbeslutningen i ett notat. «Slå av VPN-en» er ikke et funn, og å tillate all Google-trafikk er ikke en avgrenset retting.