Внереестровая блокировка Google Firebase (firebaseapp.com, forms.gle, posts.gle)

Подтверждаю. Тоже есть периодические проблемы с доступом к Firebase через Мегафон и Ростелеком (Теле2). Начались примерно 3-4 дня назад. Database location: nam5 (не знаю имеет ли это значение).

Не знаю куда копать…

У меня все началось в ночь 7-8.10.2023. С каждым днем у большего числа людей начинает глючить. Домашние, мобильные сети, уже независимо от провайдера. Но еще есть у кого нормально работает. Видимо постепенно вводят свои блокировки :rage:

Все предыдущие домены, которые были недоступны год назад, работают.

Аналогично, всё так. С каждым днём всё большее количество пользователей жалуются на ошибку о недоступности БД Firebase. Подскажите, какая у вас локация серверов в Firebase, nam5 или другая?

Пока не понимаю как отловить заблокированные IP-адреса, чтобы сообщить здесь. У тех пользователей, у которых проблема с доступностью Firebase если включить VPN - всё работает отлично.

Такая же проблема, началась 3 дня назад.
Firestore сервер используем eur3.
Есть подозрение, что проблема именно с авторизацией в Firebase, а не с самой базой данных.

Если кто найдет решение этой проблемы, было бы здорово.

С VPN тоже все работает.

Коллеги, есть у кого-нибудь возможность попробовать отловить какие IP-адреса все-таки попали под блокировку? У нас авторизации нет, но проблема с запуском приложений из-за недоступности Firebase - есть.

Я попробую сегодня собрать дамп через PCAPdroid, может тоже кто-нибудь попробует отловить заблокированные адреса? Едва ли такая частичная блокировка серверов Firebase носит преднамеренный характер?

Firebase изначально работал по протоколу XMPP, но сейчас он объявлен deprecated и используется HTTP API.
Возможно, в вашем ПО используется XMPP-версия, а проблемы вызваны Обсуждение: Блокировка Jabber/XMPP в России?

Database location: eur3

У нас тоже проблема, у многих пользователей (зависит походу от интернет провайдера) не работают запросы к firestore, причем только во flutter-библиотеке. Firebase Admin SDK и Firebase web SDK ок.
Предполагаю тогда что cloud_firestore | Flutter Package работет на XMPP и из за этого возникают проблемы. Пока непонятно как это решать.

Firebase Cloud Messaging XMPP protocol
Authorize send requests

// Production
fcm-xmpp.googleapis.com:5235

// Testing
fcm-xmpp.googleapis.com:5236

You must initiate a Transport Layer Security (TLS) connection. Note that FCM doesn’t currently support the STARTTLS extension.

it is just a wrapper around native Firebase SDKs

В Android Cloud Firestore такая же проблема, flutter не используется, да и FCM не используем.
Пока работает только через VPN.

Аналогично. Flutter и не FCM не используем в этом проекте, но доступа у пользователей без VPN - нет. Значит вряд ли ошибка в блокировке XMPP?

Экспериментальным путем выяснили, что проблема с доступом к Cloud Firestore, доступ к Firebase Remote Config, например, есть у всех пользователей.

У firebaseremoteconfig.googleapis.com туча адресов, у firestore.googleapis.com один. Они иногда пересекаются.

Адреса firestore.googleapis.com для разных geoip клиентов

142.250.179.234
142.250.181.170
142.250.182.138
142.250.184.138
142.250.184.170
142.250.193.170
142.250.201.74
142.250.218.234
142.250.65.170
142.250.65.234
142.250.68.42
142.250.74.138
142.250.74.74
142.250.80.42
142.251.221.138
142.251.221.74
142.251.36.202
142.251.40.138
142.251.40.234
142.251.41.10
142.251.47.202
172.217.0.170
172.217.169.106
172.217.2.138
172.217.215.95
172.217.23.202
216.58.215.234
34.64.4.10
74.125.130.95

Если я правильно смотрю дамп, то нет ответа на Client Hello как минимум от двух IP-адресов.

25 2.264054 192.168.1.118 216.58.209.202 TLSv1 234 Client Hello
32 2.527785 192.168.1.118 216.58.209.202 TCP 234 [TCP Retransmission] 39206 → 443 [PSH, ACK] Seq=1 Ack=1 Win=87616 Len=168 TSval=4294938752 TSecr=1926719265

61 3.566939 192.168.1.118 216.58.211.226 TLSv1 583 Client Hello
71 4.101006 192.168.1.118 216.58.211.226 TCP 583 [TCP Retransmission] 58744 → 443 [PSH, ACK] Seq=1 Ack=1 Win=87616 Len=517 TSval=4294939224 TSecr=2701383711

По некоторым IP-адресам есть ответ Server Hello:
37 2.710146 192.168.1.118 216.58.209.170 TLSv1.2 247 Client Hello
40 2.758502 216.58.209.170 192.168.1.118 TLSv1.2 1466 Server Hello

Но не уверен, что правильно смотрю.

Чем заканчиваются TCP streams c этими Retransmission?

PCAPdroid использует zdtun, реализуя логику tun2socket. Пишет пакеты клиента на VPN интерфейсе, транслируя дату в сетевые сокеты. ACK’ает пакеты клиента при удачной записи в сокет, связь с ответом сервера косвенная. Дампы, при блокировке, могут сильно отличаться от снятых на внешнем интерфейсе или далее в сети. Retransmission может совсем не быть в дампах PCAPdroid, при реальной блокировке. Получается, надо смотреть все streams.

РКН ранее уже блокировал Google. Было масштабней, не нужно было искать иголку в стогу сена. Но можно использовать тот опыт для сбора всех адресов используемых гуглом для apis. Только не понятно, каких apis, блокируют ли проблемные адреса на всех ТСПУ, что именно по адресам блокируют.

что делать то, ребят?

Мобильные платформы существуют в мире единорогов и розовых пони, там никогда не бывает сетевых сбоев. “client is offline” (unavailable) возвращает также когда проблемы с бэкендом, но апи доступно и отвечает. Идеальная цель для РКН, могут кошмарить и отмараживаться.

Удалось выяснить, к какому домену идут эти запросы?

googleapis.com
firestore.googleapis.com
oauth2.googleapis.com
play.googleapis.com

dns.google