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 сообраќај не е ограничена поправка.