Push-апавяшчэнні Android не працуюць праз VPN? Праверце гэта

Апавяшчэнні перастаюць прыходзіць на тэлефон, які інакш нармальна працуе праз карпаратыўны VPN. Старонкі загружаюцца, праграма адкрываецца, а паведамленні паказваюцца толькі дома або пасля адключэння тунеля. Для праграмы на Firebase Cloud Messaging push-канал — гэта асобнае доўгае зыходнае злучэнне, а не шлях HTTPS, які толькі што даказаў браўзер. Прайдзіце гэтыя праверкі па парадку і спыніцеся на першай няўдачы.

Пераканайцеся, што праграма сапраўды выкарыстоўвае FCM

Не кожнае апавяшчэнне — гэта push. Частка плануецца лакальна праграмай, частка апытваецца праз HTTPS, а частка прыходзіць праз канал пастаўшчыка, які не мае дачынення да Firebase. Калі маніфест і залежнасці праграмы ўключаюць Firebase Messaging, яе апавяшчэнні звычайна ідуць праз злучэнне FCM, а кліенцкая бібліятэка піша рэгістрацыю пад прадказальным тэгам.

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

Токен рэгістрацыі ў лозе пацвярджае транспарт. Без яго вы адладжваеце канвеер апавяшчэнняў на ўзроўні праграмы, і змены ў фаерволе не дапамогуць. Гэта важна, бо дастаўленае, але ніколі не паказанае паведамленне і паведамленне, якое не прыйшло, для карыстальніка выглядаюць аднолькава.

Праверце зыходныя парты, а не вэб-сайт

Злучэнні прылад FCM — гэта зыходныя TCP-злучэнні з тэлефона на порт 5228, з 5229 і 5230 як рэзервовымі і 443 як апошнім варыянтам. Фаервол, які дазваляе 443 для прагляду, можа ўсё роўна зламаць push, а правіла, якое дазваляе дамен API праграмы, не пакрывае канчатковыя пункты паведамленняў — гэта асобныя сэрвісы.

Гэта зыходныя злучэнні з тэлефона. Вы не публікуеце ўваходны порт на прыладзе ці VPN-шлюзе, таму калі хтосьці прапануе перанакіраванне порта, праект ужо памылковы. Тое ж самае з правілам, якое адкрывае адзін порт для кожнага адраса ў інтэрнэце: абмяжуйце яго дакументаванымі прызначэннямі.

Сеткавыя рэкамендацыі Firebase таксама сцвярджаюць, што пратакол дастаўкі FCM нельга перадаць праз звычайны HTTP-проксі. Поспех браўзера праз карпаратыўны вэб-проксі нічога не даказвае пра push-сокет: гэта розныя кліенты з рознымі шляхамі.

Праверце тайм-аўты прастою, якія забіваюць сокет

Злучэнне FCM застаецца адкрытым паміж паведамленнямі, што робіць яго адчувальным да тайм-аўтаў NAT і праверкі стану. Рэкамендацыі Firebase патрабуюць не менш за 30 хвілін дапушчальнага прастою там, дзе дзейнічаюць такія палітыкі. Тайм-аўт сеансу ў пяць хвілін маўкліва выдаляе адпаведнасць, і тэлефон перападключаецца толькі калі нешта яго разбудзіць, таму паведамленні прыходзяць пакетамі або не прыходзяць зусім.

Прачытайце табліцу сеансаў на фаерволе або VPN-шлюзе і знойдзіце злучэнне тэлефона з 5228-5230. Параўнайце яго астатні тэрмін жыцця з дакументаваным значэннем. Калі ён карацейшы, павялічце тайм-аўт для гэтых портаў, а не змяняйце ўсе палітыкі на прыладзе.

Дастаўка таксама залежыць ад таго, ці вытрымае адпаведнасць канчатковага пункта пераход паміж Wi-Fi і сотавай сеткай. Адпаведнасць, прывязаная да аднаго інтэрфейса, можа быць скінута пры перадачы, нават калі абедзве сеткі дазваляюць гэтыя парты.

Вырашыце, ці дапушчальны абыход VPN

Кліенты Android VPN могуць дазваляць трафіку абыходзіць тунель, і FCM можа выкарыстоўваць базавую сетку, калі такі абыход дазволены. Push-канал у гэтым выпадку застаецца зашыфраваным, але ўжо не нясе адрас тунеля, таму маскіроўка IP праз VPN да яго не прымяняецца. Гэта кампраміс палітыкі, а не няспраўнасць.

Калі ваша палітыка забараняе абыход, шлях тунеля павінен несці злучэнне: парты адкрытыя, тайм-аўты дастатковыя, проксі не перашкаджае. Не выключайце маўкліва кіраваны сэрвіс і не паслабляйце блакіроўку толькі таму, што апавяшчэнні працуюць у некіраванай сетцы. Значок VPN не паведамляе, які шлях выбраў канкрэтны сэрвіс.

Аддзяліце дастаўку ад паказу і праверце адзін раз

Дазвол, налады канала, Не турбаваць і пераключальнікі для кожнай праграмы вырашаюць, ці будзе паказана дастаўленае паведамленне. На Android 13 і пазней дазвол на апавяшчэнні выдаецца падчас працы, і адмова стварае цішыню, якая выглядае гэтак жа, як заблакаваны порт. Паведамленне, якое прыйшло, але не было паказана, — гэта праблема паказу, разглядайце яе асобна.

Правядзіце адзін кантраляваны тэст замест рассылання паведамленняў наўздагад. Зафіксуйце прыладу, уліковы запіс і праграму, адпраўце адно паведамленне з вядомым часавым штампам і параўнайце ўмову VPN з ухваленай сеткай без VPN. Запішыце час атрымання ў logcat і час паказу для кожнага прагону. Калі дастаўка адрозніваецца, а паказ не, зменная — сеткавы шлях; калі абодва аднолькавыя, працягвайце глядзець на праграму.

Дайце ўладальніку сеткі парты, абмежаванне проксі, вымераны тайм-аўт і рашэнне пра абыход у адной запісцы. Выключыце VPN — не выснова, і дазвол усяго трафіку Google — не абмежаванае выпраўленне.