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