Notifikácie prestanú prichádzať na telefóne, ktorý inak dobre prehliada web cez firemnú VPN. Webové stránky sa načítavajú, aplikácia sa otvára, ale správy sa zobrazujú len doma alebo po vypnutí tunela. V aplikácii postavenej na Firebase Cloud Messaging je push kanál samostatné dlhodobé odchádzajúce spojenie, nie cesta HTTPS, ktorú práve preukázal prehliadač. Prejdite tieto kontroly v poradí a zastavte sa pri prvej, ktorá zlyhá.

Potvrďte, že aplikácia skutočne používa FCM

Nie každá notifikácia je push. Niektoré plánuje aplikácia lokálne, niektoré sa dopytujú cez HTTPS a niektoré prichádzajú kanálom dodávateľa, ktorý nemá s Firebase nič spoločné. Ak manifest a závislosti aplikácie obsahujú Firebase Messaging, jej notifikácie zvyčajne putujú cez FCM spojenie a klientská knižnica zaznamenáva registráciu pod predvídateľnou značkou.

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

Registračný token v logu potvrdzuje prenos. Bez neho ladíte pipeline notifikácií na úrovni aplikácie a zmeny firewallu nepomôžu. Tento rozdiel je dôležitý, pretože doručená, ale nikdy nezobrazená správa a správa, ktorá nikdy nepríde, vyzerajú pre používateľa rovnako.

Skontrolujte odchádzajúce porty, nie webovú stránku

Spojenia zariadení s FCM sú TCP iniciované zariadením na port 5228, s 5229 a 5230 ako záložnými a 443 ako poslednou možnosťou. Firewall, ktorý povoľuje 443 na prehliadanie, môže push napriek tomu pokaziť, a pravidlo povoľujúce doménu API aplikácie nepokrýva koncové body na doručovanie správ, ktoré sú samostatnými službami.

Toto sú odchádzajúce spojenia z telefónu. Nepublikujete vstupný port na zariadení ani na VPN bráne, takže ak niekto navrhne presmerovanie portu, návrh je už nesprávny. To isté platí pre pravidlo, ktoré otvára jeden port všetkým adresám na internete: obmedzte ho na zdokumentované ciele.

PortRoleWhat to verify
5228Primary FCM connectionOutbound allowed and session state kept
5229, 5230Fallback portsOften missing from hand-written allowlists
443Last-resort fallbackWorks only if the client actually falls back
HTTP proxyNot a supported FCM transportProxy exclusion or bypass, not a port rule

Sieťové odporúčania Firebase tiež uvádza, že protokol doručovania FCM sa nedá prenášať cez bežné HTTP proxy. To, že prehliadač funguje cez firemnú webovú proxy, teda nič nedokazuje o push sockete: sú to dva rôzne klienty s rôznymi cestami.

Skontrolujte časové limity nečinnosti, ktoré zabíjajú socket

Spojenie FCM zostáva otvorené medzi správami, čo ho robí citlivým na časové limity NAT a kontroly stavu. Odporúčania Firebase žiadajú aspoň 30 minút tolerancie nečinnosti tam, kde také pravidlá platia. Päťminútový limit relácie potichu odstráni mapovanie a telefón sa znova pripojí len vtedy, keď ho niečo zobudí, takže správy prichádzajú v dávkach alebo vôbec.

Prečítajte tabuľku relácií na firewalle alebo VPN bráne a nájdite spojenie telefónu na 5228-5230. Porovnajte zostávajúcu životnosť s dokumentovanou hodnotou. Ak je kratšia, zvýšte časový limit pre tie porty namiesto zmeny všetkých pravidiel v zariadení, pretože globálnu zmenu limitu je ťažké obhájiť a ešte ťažšie vrátiť späť.

Doručovanie push závisí aj od toho, či mapovanie koncového bodu prežije roaming medzi Wi-Fi a mobilnou sieťou. Mapovanie naviazané na jedno rozhranie môže byť pri prechode zahodené, aj keď obe siete porty povoľujú.

Rozhodnite, či je obchádzanie VPN prijateľné

Klienti VPN v Androide môžu povoliť prevádzke obísť tunel a FCM môže vtedy použiť sieť pod ním. Push kanál zostáva v tom prípade šifrovaný, ale už nenesie adresu tunela, takže maskovanie IP cez VPN naň neplatí. Je to kompromis v pravidlách, nie porucha.

Ak vaše pravidlá obchádzanie zakazujú, cesta tunela musí niesť spojenie: porty otvorené, časové limity dostatočne dlhé, proxy nie na ceste. Nevynechávajte potichu spravovanú službu a neuvoľňujte zámok len preto, že notifikácie fungujú v nespravovanej sieti. Ikona VPN nehovorí, ktorú cestu zvolila konkrétna služba

Oddeľte doručovanie od zobrazovania, potom otestujte raz

Povolenie, nastavenia kanála, Nerušiť a prepínače pre jednotlivé aplikácie rozhodujú, či sa doručená správa zobrazí. V Androide 13 a novšom sa povolenie na notifikácie udeľuje za behu a odmietnuté povolenie vytvára ticho, ktoré vyzerá presne ako zablokovaný port. Správa, ktorá dorazila, ale nezobrazila sa, je problém prezentácie; riešte ho samostatne.

Urobte jeden kontrolovaný test namiesto náhodného odosielania správ. Držte zariadenie, účet a aplikáciu nezmenené, pošlite jednu správu so známou časovou značkou a porovnajte stav s VPN a v schválenej sieti bez VPN. Zapíšte čas prijatia v logcat a čas zobrazenia pre každý beh. Ak sa doručovanie líši, ale zobrazovanie nie, premennou je sieťová cesta; ak sú obe rovnaké, pokračujte v skúmaní aplikácie.

Odovzdajte správcovi siete porty, obmedzenie proxy, nameraný časový limit a rozhodnutie o obchádzaní v jednej poznámke. «Vypni VPN» nie je zistenie a povolenie celej prevádzky Google nie je cielená oprava.

Súvisiace články