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. Порівняйте залишковий час життя з документованим значенням. Якщо він коротший, збільште тайм-аут для цих портів, а не змінюйте всі політики на пристрої, бо глобальну зміну тайм-ауту важко обґрунтувати і ще важче скасувати.

Доставка push також залежить від того, чи переживе зіставлення кінцевої точки роумінг між Wi-Fi і стільниковою мережею. Зіставлення, прив'язане до одного інтерфейсу, може бути відкинуте під час переходу, навіть коли обидві мережі дозволяють ці порти.

Вирішіть, чи прийнятний обхід VPN

Клієнти VPN в Android можуть дозволяти трафіку обходити тунель, і FCM може використовувати мережу під ним, коли такий обхід дозволено. У цьому разі канал push залишається зашифрованим, але вже не несе адресу тунелю, тож маскування IP через VPN на нього не поширюється. Це компроміс політики, а не несправність.

Якщо ваша політика забороняє обхід, шлях тунелю має нести з'єднання: порти відкриті, тайм-аути достатньо довгі, проксі не заважає. Не виключайте мовчки керовану службу і не послаблюйте блокування лише тому, що сповіщення працюють у некерованій мережі. Значок VPN не показує, який шлях обрала конкретна служба

Відокремте доставку від відображення, потім перевірте один раз

Дозвіл, налаштування каналу, «Не турбувати» та перемикачі для кожного застосунку вирішують, чи буде показано доставлене повідомлення. У Android 13 і новіших дозвіл на сповіщення надається під час виконання, і відмова створює тишу, яка виглядає точно як заблокований порт. Повідомлення, яке надійшло, але не відобразилося, — це проблема відображення; розглядайте її окремо.

Проведіть один контрольований тест замість випадкового надсилання повідомлень. Тримайте пристрій, обліковий запис і застосунок незмінними, надішліть одне повідомлення з відомою міткою часу та порівняйте стан із VPN і в схваленій мережі без VPN. Запишіть час отримання в logcat і час відображення для кожного запуску. Якщо доставка відрізняється, а відображення ні, змінною є мережевий шлях; якщо обидва однакові, далі дивіться на застосунок.

Передайте власнику мережі порти, обмеження проксі, виміряний тайм-аут і рішення про обхід однією нотаткою. «Вимкни VPN» — не висновок, а дозвіл усього трафіку Google — не точкове виправлення.