Android-pushmeldingen werken niet met een VPN? Controleer dit

Meldingen komen niet meer aan op een telefoon die verder prima browset via de bedrijfs-VPN. Webpagina's laden, de app opent, en berichten verschijnen alleen thuis of nadat de tunnel is uitgeschakeld. In een app op basis van Firebase Cloud Messaging is het pushkanaal een aparte, langdurige uitgaande verbinding, niet het HTTPS-pad dat de browser zojuist bewees. Werk deze controles op volgorde af en stop bij de eerste die faalt.

Bevestig dat de app echt FCM gebruikt

Niet elke melding is een push. Sommige plant de app lokaal in, andere worden via HTTPS opgehaald, en weer andere komen via een leverancierskanaal dat niets met Firebase te maken heeft. Als het manifest en de afhankelijkheden van de app Firebase Messaging bevatten, gaan de meldingen normaal over de FCM-verbinding, en de clientbibliotheek logt de registratie onder een voorspelbare tag.

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

Een registratietoken in de log bevestigt het transport. Zonder token debugt u een meldingspijplijn op app-niveau, en firewallwijzigingen helpen niet. Dit onderscheid is belangrijk omdat een afgeleverd bericht dat nooit wordt getoond en een bericht dat nooit aankomt er voor de gebruiker hetzelfde uitzien.

Controleer de uitgaande poorten, niet de website

FCM-apparaatverbindingen zijn door het apparaat gestarte TCP naar poort 5228, met 5229 en 5230 als terugval en 443 als laatste redmiddel. Een firewall die 443 voor browsen toestaat kan push alsnog breken, en een regel die het API-domein van een app toestaat dekt de berichtgevingseindpunten niet, die aparte diensten zijn.

Dit zijn uitgaande verbindingen vanaf de telefoon. U publiceert geen inkomende poort op het apparaat of de VPN-gateway, dus als iemand port forwarding voorstelt, is het ontwerp al verkeerd. Hetzelfde geldt voor een regel die één poort opent voor elk adres op internet: beperk die tot de gedocumenteerde bestemmingen.

Firebase's netwerkrichtlijnen stelt ook dat het FCM-leveringsprotocol niet over een gewone HTTP-proxy kan worden vervoerd. Dat een browser via de bedrijfswebproxy werkt, bewijst dus niets over de pushsocket: het zijn twee verschillende clients met verschillende paden.

Controleer de idle-time-outs die de socket doden

De FCM-verbinding blijft open tussen berichten, wat hem gevoelig maakt voor NAT- en stateful-inspection-time-outs. De richtlijnen van Firebase vragen minstens 30 minuten idle-tolerantie waar zulk beleid geldt. Een sessie-time-out van vijf minuten verwijdert de mapping stil, en de telefoon verbindt pas opnieuw wanneer iets hem wekt, dus berichten komen in golven of helemaal niet.

Lees de sessietabel op de firewall of VPN-gateway en zoek de verbinding van de telefoon naar 5228-5230. Vergelijk de resterende levensduur met de gedocumenteerde waarde. Is die korter, verhoog dan de time-out voor die poorten in plaats van al het beleid op het apparaat te wijzigen, want een globale time-outwijziging is moeilijk te rechtvaardigen en nog moeilijker terug te draaien.

Pushlevering hangt er ook van af of de endpoint-mapping een roaming tussen Wi-Fi en mobiel overleeft. Een mapping die aan één interface is gekoppeld, kan bij de overdracht vervallen, zelfs wanneer beide netwerken de poorten toestaan.

Bepaal of VPN-bypass aanvaardbaar is

Android-VPN-clients kunnen verkeer toestaan de tunnel te omzeilen, en FCM kan het onderliggende netwerk gebruiken wanneer die bypass is toegestaan. Het pushkanaal blijft in dat geval versleuteld, maar het draagt niet langer het adres van de tunnel, dus de IP-maskering van de VPN geldt er niet voor. Dat is een beleidsafweging, geen storing.

Als uw beleid bypass verbiedt, moet het tunnelpad de verbinding dragen: poorten open, time-outs lang genoeg, proxy niet in de weg. Sluit een beheerde dienst niet stilzwijgend uit en versoepel de vergrendeling niet alleen omdat meldingen op een onbeheerd netwerk werken. Het VPN-pictogram vertelt niet welk pad een bepaalde dienst koos

Scheid levering van weergave en test één keer

Toestemming, kanaalinstellingen, Niet storen en schakelaars per app bepalen of een afgeleverd bericht wordt getoond. Op Android 13 en later is de meldingstoestemming een toekenning tijdens runtime, en een geweigerde toekenning levert stilte op die er precies uitziet als een geblokkeerde poort. Een bericht dat aankwam maar niet werd getoond, is een weergaveprobleem; behandel dat apart.

Doe één gecontroleerde test in plaats van berichten lukraak te sturen. Houd het apparaat, het account en de app vast, stuur één bericht met een bekend tijdstempel en vergelijk de VPN-situatie met een goedgekeurd netwerk zonder VPN. Noteer de ontvangsttijd in logcat en de weergavetijd voor elke run. Als de levering verschilt maar de weergave niet, is het netwerkpad de variabele; als beide gelijk zijn, blijf dan naar de app kijken.

Geef de netwerkeigenaar de poorten, de proxybeperking, de gemeten time-out en de bypassbeslissing in één notitie. «Zet de VPN uit» is geen bevinding, en al het Google-verkeer toestaan is geen afgebakende oplossing.