Android-Push-Benachrichtigungen kommen über VPN nicht an? Prüfen Sie das

Benachrichtigungen kommen auf einem Telefon nicht mehr an, das über das Firmen-VPN sonst einwandfrei surft. Seiten laden, die App öffnet sich, und Nachrichten erscheinen nur zu Hause oder nach dem Abschalten des Tunnels. Bei einer App auf Basis von Firebase Cloud Messaging ist der Push-Kanal eine eigene langlebige ausgehende Verbindung, nicht der HTTPS-Pfad, den der Browser gerade bewiesen hat. Gehen Sie diese Prüfungen der Reihe nach durch und hören Sie bei der ersten auf, die scheitert.

Bestätigen Sie, dass die App tatsächlich FCM nutzt

Nicht jede Benachrichtigung ist ein Push. Manche plant die App lokal, manche werden über HTTPS abgerufen, und manche kommen über einen Anbieterkanal ohne Bezug zu Firebase. Enthalten Manifest und Abhängigkeiten der App Firebase Messaging, laufen ihre Benachrichtigungen normalerweise über die FCM-Verbindung, und die Client-Bibliothek protokolliert die Registrierung unter einem vorhersehbaren Tag.

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

Ein Registrierungstoken im Log bestätigt den Transport. Ohne ihn debuggen Sie eine Benachrichtigungskette auf App-Ebene, und Firewall-Änderungen helfen nicht. Dieser Unterschied ist wichtig, weil eine zugestellte, aber nie angezeigte Nachricht und eine nie angekommene Nachricht für den Nutzer gleich aussehen.

Prüfen Sie die ausgehenden Ports, nicht die Website

FCM-Geräteverbindungen sind ausgehende TCP-Verbindungen vom Telefon zu Port 5228, mit 5229 und 5230 als Rückfallebene und 443 als letzter Möglichkeit. Eine Firewall, die 443 zum Surfen erlaubt, kann Push trotzdem brechen, und eine Regel für die API-Domain der App deckt die Messaging-Endpunkte nicht ab, weil das eigene Dienste sind.

Das sind ausgehende Verbindungen vom Telefon. Sie veröffentlichen keinen eingehenden Port am Gerät oder am VPN-Gateway, wer also Port-Forwarding vorschlägt, hat den Entwurf schon falsch. Dasselbe gilt für eine Regel, die einen Port für jede Adresse im Internet öffnet: begrenzen Sie sie auf die dokumentierten Ziele.

Firebases Netzwerkhinweise sagen außerdem, dass sich das FCM-Zustellprotokoll nicht über einen gewöhnlichen HTTP-Proxy übertragen lässt. Dass der Browser durch den Firmen-Webproxy kommt, beweist daher nichts über den Push-Socket: Es sind zwei verschiedene Clients mit verschiedenen Wegen.

Prüfen Sie die Idle-Timeouts, die den Socket töten

Die FCM-Verbindung bleibt zwischen Nachrichten offen, was sie empfindlich gegen NAT- und Stateful-Inspection-Timeouts macht. Firebases Hinweise verlangen mindestens 30 Minuten Idle-Toleranz, wo solche Richtlinien gelten. Ein Sitzungs-Timeout von fünf Minuten entfernt die Zuordnung still, und das Telefon verbindet sich erst wieder, wenn etwas es weckt, sodass Nachrichten in Schüben oder gar nicht ankommen.

Lesen Sie die Sitzungstabelle auf der Firewall oder dem VPN-Gateway und suchen Sie die Verbindung des Telefons zu 5228-5230. Vergleichen Sie die Restlebensdauer mit dem dokumentierten Wert. Ist sie kürzer, erhöhen Sie das Timeout für diese Ports, statt jede Richtlinie auf dem Gerät zu ändern.

Die Zustellung hängt auch davon ab, ob die Endpunkt-Zuordnung einen Wechsel zwischen WLAN und Mobilfunk überlebt. Eine an eine Schnittstelle gebundene Zuordnung kann bei der Übergabe verloren gehen, selbst wenn beide Netze die Ports erlauben.

Entscheiden Sie, ob ein VPN-Bypass vertretbar ist

Android-VPN-Clients können zulassen, dass Verkehr den Tunnel umgeht, und FCM darf dann das darunterliegende Netz nutzen. Der Push-Kanal bleibt verschlüsselt, trägt aber nicht mehr die Adresse des Tunnels, sodass die IP-Verschleierung des VPN für ihn nicht gilt. Das ist ein Richtlinienkompromiss, keine Fehlfunktion.

Verbietet Ihre Richtlinie den Bypass, muss der Tunnelpfad die Verbindung tragen: Ports offen, Timeouts lang genug, kein Proxy im Weg. Schließen Sie keinen verwalteten Dienst still aus und lockern Sie die Sperre nicht, nur weil Benachrichtigungen in einem unverwalteten Netz funktionieren. Das VPN-Symbol sagt nicht, welchen Weg ein Dienst gewählt hat.

Trennen Sie Zustellung von Anzeige und testen Sie einmal

Berechtigung, Kanaleinstellungen, Nicht stören und Schalter pro App entscheiden, ob eine zugestellte Nachricht angezeigt wird. Ab Android 13 wird die Benachrichtigungsberechtigung zur Laufzeit erteilt, und eine Ablehnung erzeugt Stille, die genau wie ein blockierter Port aussieht. Eine angekommene, aber nicht angezeigte Nachricht ist ein Anzeigeproblem; behandeln Sie es getrennt.

Führen Sie einen kontrollierten Test durch, statt Nachrichten ad hoc zu senden. Halten Sie Gerät, Konto und App fest, senden Sie eine einzelne Nachricht mit bekanntem Zeitstempel und vergleichen Sie den VPN-Zustand mit einem freigegebenen Netz ohne VPN. Notieren Sie die Empfangszeit im Logcat und die Anzeigezeit pro Lauf. Weicht die Zustellung ab, die Anzeige aber nicht, ist der Netzwerkpfad die Variable; sind beide gleich, schauen Sie weiter auf die App.

Geben Sie dem Netzwerkverantwortlichen die Ports, die Proxy-Einschränkung, das gemessene Timeout und die Bypass-Entscheidung in einer Notiz. VPN ausschalten ist kein Befund, und den gesamten Google-Verkehr zu erlauben ist keine eng begrenzte Korrektur.