Android-pushnotifikationer virker ikke på en VPN? Tjek dette

Notifikationer holder op med at komme på en telefon, der ellers browser fint gennem virksomhedens VPN. Sider indlæses, appen åbner, og beskeder dukker kun op derhjemme eller efter tunnelens slukning. For en app bygget på Firebase Cloud Messaging er pushkanalen en separat langvarig udgående forbindelse, ikke den HTTPS-vej, browseren lige har bevist. Gå gennem disse kontroller i rækkefølge, og stop ved den første, der fejler.

Bekræft, at appen faktisk bruger FCM

Ikke hver notifikation er et push. Nogle planlægges lokalt af appen, nogle hentes over HTTPS, og nogle kommer gennem en leverandørkanal uden forbindelse til Firebase. Hvis appens manifest og afhængigheder indeholder Firebase Messaging, rejser dens notifikationer normalt over FCM-forbindelsen, og klientbiblioteket logger registreringen under et forudsigeligt tag.

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

Et registreringstoken i loggen bekræfter transporten. Uden et sådant fejlretter du en notifikationskæde på appniveau, og ændringer i firewallen hjælper ikke. Forskellen er vigtig, fordi en besked, der blev leveret men aldrig vist, og en besked, der aldrig nåede frem, ser ens ud for brugeren.

Tjek de udgående porte, ikke webstedet

FCM-enhedsforbindelser er udgående TCP fra telefonen til port 5228, med 5229 og 5230 som reserver og 443 som sidste udvej. En firewall, der tillader 443 til browsing, kan stadig bryde push, og en regel, der tillader appens API-domæne, dækker ikke beskedendepunkterne, fordi de er separate tjenester.

Det er udgående forbindelser fra telefonen. Du udgiver ikke en indgående port på enheden eller VPN-gatewayen, så hvis nogen foreslår portforwarding, er designet allerede forkert. Det samme gælder en regel, der åbner én port mod hver adresse på internettet: begræns den til de dokumenterede destinationer.

Firebases netværksvejledning siger også, at FCM-leveringsprotokollen ikke kan bæres over en almindelig HTTP-proxy. At browseren kommer igennem virksomhedens webproxy beviser derfor intet om push-socketten: de er to forskellige klienter med hver sin vej.

Tjek de inaktivitets-timeouts, der dræber socketten

FCM-forbindelsen står åben mellem beskeder, hvilket gør den følsom over for NAT- og tilstandskontrol-timeouts. Firebases vejledning kræver mindst 30 minutters inaktivitets tolerance, hvor sådanne politikker gælder. En sessionstimeout på fem minutter fjerner stille mappingen, og telefonen genopretter først forbindelsen, når noget vækker den, så beskeder ankommer i klumper eller slet ikke.

Læs sessionstabellen på firewallen eller VPN-gatewayen, og find telefonens forbindelse til 5228-5230. Sammenlign dens resterende levetid med den dokumenterede værdi. Er den kortere, så hæv timeoutet for de porte i stedet for at ændre hver politik på enheden.

Levering afhænger også af, at endepunktsmappingen overlever et skift mellem Wi-Fi og mobilt netværk. En mapping bundet til ét interface kan blive tabt ved overdragelsen, selv når begge netværk tillader portene.

Beslut, om VPN-omgåelse er acceptabel

Android VPN-klienter kan tillade trafik at omgå tunnelen, og FCM kan bruge det underliggende netværk, når den omgåelse er tilladt. Pushkanalen forbliver krypteret, men bærer ikke længere tunnelens adresse, så VPNens IP-maskering gælder ikke for den. Det er en politikafvejning, ikke en fejl.

Hvis din politik forbyder omgåelse, skal tunnelvejen bære forbindelsen: porte åbne, timeouts lange nok, proxy ikke i vejen. Udstød ikke stille en administreret tjeneste, og lemp ikke låsen, blot fordi notifikationer virker på et ikke-administreret netværk. VPN-ikonet fortæller ikke, hvilken vej en given tjeneste valgte.

Adskil levering fra visning, og test én gang

Tilladelse, kanalindstillinger, Forstyr ikke og kontakter pr. app afgør, om en leveret besked vises. På Android 13 og nyere gives notifikationstilladelsen ved kørsel, og et afslag giver en tavshed, der ligner en blokeret port præcis. En besked, der er ankommet men ikke vist, er et visningsproblem; behandl det separat.

Kør én kontrolleret test i stedet for at sende beskeder tilfældigt. Hold enhed, konto og app fast, send en enkelt besked med et kendt tidsstempel, og sammenlign VPN-tilstanden med et godkendt netværk uden VPN. Notér logcat-modtagelsestiden og visningstiden for hver kørsel. Hvis leveringen afviger, men visningen ikke, er netværksvejen variablen; er begge ens, så kig videre på appen.

Giv netværksejeren portene, proxybegrænsningen, det målte timeout og beslutningen om omgåelse i ét notat. Sluk for VPN er ikke en konstatering, og at tillade al Google-trafik er ikke en afgrænset rettelse.