Nem jönnek az Android push értesítések VPN alatt? Ellenőrizze ezeket

Az értesítések elmaradnak egy olyan telefonon, amely egyébként gond nélkül böngészik a vállalati VPN-en keresztül. A weboldalak betöltődnek, az alkalmazás megnyílik, és az üzenetek csak otthon vagy az alagút kikapcsolása után jelennek meg. A Firebase Cloud Messagingre épülő alkalmazásban a push csatorna külön, hosszú életű kimenő kapcsolat, nem az a HTTPS útvonal, amelyet a böngésző épp bizonyított. Végezze el ezeket az ellenőrzéseket sorrendben, és álljon meg az elsőnél, amelyik elbukik.

Erősítse meg, hogy az alkalmazás valóban FCM-et használ

Nem minden értesítés push. Egyeseket az alkalmazás helyben ütemez, másokat HTTPS-en keresztül kérdeznek le, és megint mások olyan szállítói csatornán érkeznek, amelynek semmi köze a Firebase-hez. Ha az alkalmazás manifestje és függőségei tartalmazzák a Firebase Messaginget, az értesítések általában az FCM kapcsolaton keresztül utaznak, és az ügyfélkönyvtár kiszámítható címke alatt naplózza a regisztrációt.

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

A naplóban megjelenő regisztrációs token igazolja az átvitelt. Enélkül egy alkalmazásszintű értesítési folyamatot hibakeres, és a tűzfal módosításai nem segítenek. Ez a megkülönböztetés azért fontos, mert a kézbesített, de soha meg nem jelenített üzenet és a soha meg nem érkező üzenet a felhasználónak ugyanúgy néz ki.

A kimenő portokat ellenőrizze, ne a webhelyet

Az FCM eszközkapcsolatai eszköz által indított TCP-k az 5228 port felé, tartalékként 5229 és 5230, végső esetben 443. Egy tűzfal, amely a 443-at engedi a böngészéshez, még mindig megtörheti a pusht, és az alkalmazás API-domainjét engedő szabály nem fedi le az üzenetkezelési végpontokat, amelyek külön szolgáltatások.

Ezek kimenő kapcsolatok a telefonról. Nem tesz közzé bejövő portot az eszközön vagy a VPN-átjárón, tehát ha valaki porttovábbítást javasol, a tervezés már elromlott. Ugyanez igaz arra a szabályra, amely egy portot az internet minden címének megnyit: szűkítse a dokumentált célpontokra.

A Firebase hálózati útmutatója azt is kimondja, hogy az FCM kézbesítési protokollja nem vihető át közönséges HTTP proxy-n. Az, hogy egy böngésző működik a vállalati webproxyn keresztül, ezért semmit nem bizonyít a push foglalatról: két különböző kliens, különböző útvonalakkal.

Ellenőrizze az üresjárati időtúllépéseket, amelyek megölik a foglalatot

Az FCM kapcsolat az üzenetek között nyitva marad, ami érzékennyé teszi a NAT és az állapotkövető vizsgálat időtúllépéseire. A Firebase útmutatása legalább 30 perc üresjárati tűrést kér ott, ahol ilyen szabályok érvényesek. Egy ötperces munkamenet-időtúllépés csendben eltávolítja a leképezést, és a telefon csak akkor csatlakozik újra, ha valami felébreszti, így az üzenetek csoportosan érkeznek vagy egyáltalán nem.

Olvassa ki a tűzfal vagy a VPN-átjáró munkamenet-táblázatát, és keresse meg a telefon kapcsolatát az 5228-5230 portokhoz. Hasonlítsa össze a hátralévő élettartamát a dokumentált értékkel. Ha rövidebb, növelje az időtúllépést ezekre a portokra, ahelyett hogy az eszköz összes szabályát módosítaná, mert a globális időtúllépés-változást nehéz indokolni, és még nehezebb visszavonni.

A push kézbesítés attól is függ, hogy a végpont leképezése túléljen egy Wi-Fi és mobilhálózat közötti barangolást. Az egy interfészhez kötött leképezés az átadáskor elveszhet, még akkor is, ha mindkét hálózat engedi a portokat.

Döntse el, elfogadható-e a VPN megkerülése

Az Android VPN-kliensek engedhetik, hogy a forgalom megkerülje az alagutat, és az FCM ilyenkor használhatja az alatta lévő hálózatot. A push csatorna ebben az esetben titkosítva marad, de már nem hordozza az alagút címét, így a VPN IP-maszkolása nem vonatkozik rá. Ez szabályozási kompromisszum, nem meghibásodás.

Ha a szabályzat tiltja a megkerülést, az alagút útvonalának kell vinnie a kapcsolatot: nyitott portok, elég hosszú időtúllépések, proxy az útból kifelé. Ne zárjon ki csendben egy felügyelt szolgáltatást, és ne lazítsa a zárolást csak azért, mert az értesítések nem felügyelt hálózaton működnek. A VPN ikon nem mondja meg, melyik útvonalat választotta egy adott szolgáltatás

Válassza el a kézbesítést a megjelenítéstől, majd teszteljen egyszer

Az engedély, a csatornabeállítások, a Ne zavarjanak és az alkalmazásonkénti kapcsolók döntik el, megjelenik-e egy kézbesített üzenet. Android 13-tól az értesítési engedély futásidejű jóváhagyás, és az elutasított jóváhagyás olyan csendet okoz, amely pontosan úgy néz ki, mint egy blokkolt port. Az az üzenet, amely megérkezett, de nem jelent meg, megjelenítési probléma; kezelje külön.

Végezzen egy ellenőrzött tesztet ahelyett, hogy összevissza küldene üzeneteket. Tartsa rögzítve az eszközt, a fiókot és az alkalmazást, küldjön egyetlen üzenetet ismert időbélyeggel, és hasonlítsa össze a VPN-es helyzetet egy jóváhagyott VPN nélküli hálózattal. Jegyezze fel a logcat fogadási idejét és a megjelenítési időt minden futásnál. Ha a kézbesítés eltér, a megjelenítés nem, akkor a hálózati útvonal a változó; ha mindkettő azonos, nézze tovább az alkalmazást.

Adja át a hálózat tulajdonosának a portokat, a proxy korlátját, a mért időtúllépést és a megkerülési döntést egyetlen feljegyzésben. A «Kapcsold ki a VPN-t» nem megállapítás, és az összes Google-forgalom engedélyezése nem célzott javítás.