Android push обавештења не раде са 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. Упоредите преостали животни век са документованом вредношћу. Ако је краћи, повећајте истек за те портове уместо да мењате сва правила на уређају, јер је глобалну промену истека тешко оправдати и још теже поништити.

Push испорука такође зависи од тога да ли мапирање завршне тачке преживи роминг између Wi-Fi и мобилне мреже. Мапирање везано за једно сучеље може бити одбачено при прелазу чак и кад обе мреже дозвољавају портове.

Одлучите да ли је заобилажење VPN-а прихватљиво

Android VPN клијенти могу дозволити саобраћају да заобиђе тунел, а FCM може користити основну мрежу кад је то заобилажење дозвољено. Push канал у том случају остаје шифрован, али више не носи адресу тунела, па се маскирање IP-а VPN-а на њега не примењује. То је политичка размена, а не квар.

Ако ваша политика забрањује заобилажење, пут тунела мора носити везу: портови отворени, истеци довољно дуги, прокси ван пута. Не искључујте тихо управљану услугу и не попуштајте закључавање само зато што обавештења раде на неуправљаној мрежи. Икона VPN-а не говори којим је путем одређена услуга кренула

Одвојите испоруку од приказа, па тестирајте једном

Дозвола, подешавања канала, Не узнемиравај и прекидачи по апликацији одлучују хоће ли се достављена порука приказати. На Android-у 13 и новијем дозвола за обавештења даје се током извршавања, а одбијена дозвола ствара тишину која изгледа тачно као блокиран порт. Порука која је стигла али није приказана проблем је приказа; решавајте је засебно.

Направите један контролисани тест уместо слања порука насумице. Држите уређај, рачун и апликацију непромењенима, пошаљите једну поруку с познатом временском ознаком и упоредите стање VPN-а са одобреном мрежом без VPN-а. Забележите време пријема у logcat и време приказа за свако извођење. Ако се испорука разликује, а приказ не, мрежни је пут променљива; ако су оба иста, наставите да гледате апликацију.

Дајте власнику мреже портове, ограничење проксија, измерени истек и одлуку о заобилажењу у једној белешци. «Искључи VPN» није налаз, а дозвољавање целог Google саобраћаја није циљана поправка.