Les notifications push Android ne fonctionnent pas avec un VPN ? Vérifiez ceci

Les notifications cessent d'arriver sur un téléphone qui, par ailleurs, navigue sans problème via le VPN de l'entreprise. Les pages web se chargent, l'application s'ouvre et les messages n'apparaissent qu'à la maison ou après la coupure du tunnel. Pour une application bâtie sur Firebase Cloud Messaging, le canal push est une connexion sortante distincte et de longue durée, pas le chemin HTTPS que le navigateur vient de prouver. Déroulez ces vérifications dans l'ordre et arrêtez-vous à la première qui échoue.

Confirmez que l'application utilise réellement FCM

Toute notification n'est pas un push. Certaines sont planifiées localement par l'application, d'autres sont interrogées via HTTPS, et d'autres arrivent par un canal fournisseur sans aucun rapport avec Firebase. Si le manifeste et les dépendances de l'application incluent Firebase Messaging, ses notifications passent normalement par la connexion FCM, et la bibliothèque cliente journalise l'enregistrement sous une étiquette prévisible.

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

Un jeton d'enregistrement dans le journal confirme le transport. Sans lui, vous déboguez une chaîne de notification au niveau applicatif, et les modifications du pare-feu n'aideront pas. Cette distinction compte, car un message livré mais jamais affiché et un message qui n'arrive jamais sont identiques pour l'utilisateur.

Vérifiez les ports sortants, pas le site web

Les connexions des appareils à FCM sont des TCP émises par l'appareil vers le port 5228, avec 5229 et 5230 en secours et 443 en dernier recours. Un pare-feu qui autorise 443 pour la navigation peut toujours casser le push, et une règle qui autorise le domaine API d'une application ne couvre pas les points de terminaison de messagerie, qui sont des services distincts.

Ce sont des connexions sortantes depuis le téléphone. Vous ne publiez pas de port entrant sur l'appareil ni sur la passerelle VPN, donc si quelqu'un propose une redirection de port, la conception a déjà échoué. Il en va de même d'une règle qui ouvre un port à toutes les adresses d'internet : limitez-la aux destinations documentées.

Les recommandations réseau de Firebase indique aussi que le protocole de livraison FCM ne peut pas passer par un proxy HTTP ordinaire. Qu'un navigateur fonctionne via le proxy web de l'entreprise ne prouve donc rien sur la socket push : ce sont deux clients différents avec des chemins différents.

Vérifiez les délais d'inactivité qui tuent la socket

La connexion FCM reste ouverte entre les messages, ce qui la rend sensible aux délais d'expiration du NAT et de l'inspection avec état. Les recommandations de Firebase demandent au moins 30 minutes de tolérance à l'inactivité là où ces politiques s'appliquent. Un délai de session de cinq minutes supprime silencieusement le mappage, et le téléphone ne se reconnecte que lorsque quelque chose le réveille, si bien que les messages arrivent par rafales ou pas du tout.

Lisez la table de sessions du pare-feu ou de la passerelle VPN et trouvez la connexion du téléphone vers 5228-5230. Comparez sa durée de vie restante avec la valeur documentée. Si elle est plus courte, augmentez le délai pour ces ports plutôt que de changer toutes les politiques de l'appareil, car un changement global de délai est difficile à justifier et plus difficile encore à annuler.

La livraison push dépend aussi du maintien du mappage de point de terminaison lors d'une itinérance entre Wi-Fi et réseau mobile. Un mappage lié à une seule interface peut être supprimé lors du transfert, même quand les deux réseaux autorisent les ports.

Décidez si le contournement du VPN est acceptable

Les clients VPN Android peuvent autoriser le trafic à contourner le tunnel, et FCM peut utiliser le réseau sous-jacent quand ce contournement est permis. Le canal push reste chiffré dans ce cas, mais il ne porte plus l'adresse du tunnel, donc le masquage IP du VPN ne s'y applique pas. C'est un compromis de politique, pas un dysfonctionnement.

Si votre politique interdit le contournement, le chemin du tunnel doit porter la connexion : ports ouverts, délais assez longs, proxy hors du chemin. N'excluez pas discrètement un service géré et ne relâchez pas le verrouillage simplement parce que les notifications fonctionnent sur un réseau non géré. L'icône du VPN ne dit pas quel chemin un service donné a choisi

Séparez la livraison de l'affichage, puis testez une fois

L'autorisation, les réglages de canal, Ne pas déranger et les interrupteurs par application décident si un message livré est affiché. Sur Android 13 et versions ultérieures, l'autorisation de notification est accordée à l'exécution, et un refus produit un silence qui ressemble exactement à un port bloqué. Un message arrivé mais non affiché est un problème de présentation ; traitez-le séparément.

Lancez un test contrôlé au lieu d'envoyer des messages au hasard. Gardez l'appareil, le compte et l'application fixes, envoyez un seul message avec un horodatage connu et comparez la condition VPN avec un réseau sans VPN approuvé. Notez l'heure de réception dans logcat et l'heure d'affichage pour chaque exécution. Si la livraison diffère mais pas l'affichage, le chemin réseau est la variable ; si les deux sont identiques, continuez à examiner l'application.

Donnez au responsable réseau les ports, la limitation du proxy, le délai mesuré et la décision de contournement dans une seule note. « Éteignez le VPN » n'est pas un constat, et autoriser tout le trafic Google n'est pas un correctif ciblé.