27.02.2022 наблюдается блокировка IP-адреса 199.36.158.100 сервиса Google Firebase, который используется на доменах forms.gle, posts.gle и firebaseapp.com от Google.
Блокировка осуществляется системой ТСПУ DPI, на провайдерах, где эта система установлена. TCP-соединение закрывается пакетом TCP RSTACK в ответ на SYN, ICMP-ответ (ping) не получается.
Сервис ping-admin показывает доступность сервиса в целом. ОБИТ, Ростелеком, МТС и Tele2 (все с ТСПУ) не устанавливают соединение до этого IP-адреса, причём с соседними адресами 199.36.158.99, 199.36.158.101 и 199.36.158.102 проблем не наблюдается.
В Реестре данный адрес не значится. Потенциальные заблокированные домены, ссылающиеся на этот адрес, также не найдены.
# traceroute 199.36.158.100 --tcp
traceroute to 199.36.158.100 (199.36.158.100), 30 hops max, 60 byte packets
1 _gateway (192.168.69.1) 0.431 ms 0.388 ms 0.583 ms
2 185-171-192-41.obit.ru (185.171.192.41) 1.378 ms 1.774 ms 2.161 ms
3 172.29.192.206 (172.29.192.206) 1.748 ms 1.949 ms 2.132 ms
4 172.29.192.121 (172.29.192.121) 2.720 ms 2.965 ms 3.103 ms
5 172.29.194.77 (172.29.194.77) 2.692 ms 2.945 ms 2.938 ms
6 172.29.194.102 (172.29.194.102) 2.930 ms 1.633 ms 1.762 ms
7 172.29.255.217 (172.29.255.217) 1.079 ms 1.867 ms 1.282 ms
8 172.29.194.121 (172.29.194.121) 1.694 ms 1.888 ms 1.880 ms
9 172.29.194.37 (172.29.194.37) 1.872 ms 1.864 ms 2.061 ms
10 censor-02.obit.ru (85.114.3.53) 2.053 ms 2.046 ms 2.039 ms
11 vi-xx-1874.brc1.spb.obit.ru (85.114.3.56) 2.440 ms 2.637 ms 2.835 ms
12 ae1-144.rt.ov.spb.ru.retn.net (87.245.250.65) 2.828 ms 1.884 ms 1.867 ms
13 * * *
14 * * *
15 * * *
16 ae0-3.rt.irx.fkt.de.retn.net (87.245.232.181) 33.290 ms * 33.267 ms
17 gw-fastly.retn.net (87.245.236.129) 32.644 ms 32.447 ms 32.603 ms
18 199.36.158.100 (199.36.158.100) 33.621 ms 30.754 ms 38.735 ms
Traceroute соседнего адреса:
# traceroute 199.36.158.102 --tcp
traceroute to 199.36.158.102 (199.36.158.102), 30 hops max, 60 byte packets
1 _gateway (192.168.69.1) 0.466 ms 0.450 ms 0.625 ms
2 185-171-192-41.obit.ru (185.171.192.41) 1.438 ms 1.838 ms 2.241 ms
3 172.29.194.72 (172.29.194.72) 1.823 ms 2.020 ms 2.221 ms
4 172.29.192.121 (172.29.192.121) 2.467 ms 2.563 ms 2.760 ms
5 172.29.194.77 (172.29.194.77) 2.447 ms 2.441 ms 2.435 ms
6 172.29.194.102 (172.29.194.102) 2.428 ms 1.063 ms 0.954 ms
7 172.29.255.217 (172.29.255.217) 1.353 ms 2.251 ms 1.136 ms
8 172.29.194.121 (172.29.194.121) 1.515 ms 1.508 ms 1.500 ms
9 172.29.194.37 (172.29.194.37) 2.931 ms 2.923 ms 3.115 ms
10 ae1-144.rt.ov.spb.ru.retn.net (87.245.250.65) 2.501 ms 2.494 ms 2.488 ms
11 * * *
12 gw-fastly.retn.net (87.245.236.129) 31.493 ms 31.068 ms 31.060 ms
13 199.36.158.102 (199.36.158.102) 38.291 ms 38.266 ms 38.859 ms
mars-stub.web.app
$ host mars-stub.web.app
mars-stub.web.app has address 199.36.158.100
mars-stub.web.app has IPv6 address 2620:0:890::100
199.36.158.100 разблокировали?
Да.
все еще не пашет, причем уже давно
It looks like the IP is still being blocked, same mechanism as the tor entry IP.
Убедился еще раз — 199.36.158.100 с моих провайдеров доступен.
forms.gle, posts.gle, firebaseapp.com открываются.
В последнее время ни у кого не было проблем с доступом к firebase из МегаФон и МТС? Именно мобильных сетей. С VPN все нормально начинает работать.
Firebase клиент пишет “Failed to fetch document because the client is offline”. И это все, что у меня есть.
Подтверждаю. Тоже есть периодические проблемы с доступом к Firebase через Мегафон и Ростелеком (Теле2). Начались примерно 3-4 дня назад. Database location: nam5 (не знаю имеет ли это значение).
Не знаю куда копать…
У меня все началось в ночь 7-8.10.2023. С каждым днем у большего числа людей начинает глючить. Домашние, мобильные сети, уже независимо от провайдера. Но еще есть у кого нормально работает. Видимо постепенно вводят свои блокировки 
Все предыдущие домены, которые были недоступны год назад, работают.
Аналогично, всё так. С каждым днём всё большее количество пользователей жалуются на ошибку о недоступности БД 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
Всё TLS на порт 443?
Доступно отовсюду, проблем не наблюдаю.
У меня проблема решилась перенаправлением трафика через прокси-сервер, который находится в СПб. Squid с дефолтными настройками и вот такой кусочек кода в андроид приложении.
System.setProperty("https.proxyHost", "x.x.x.x");
System.setProperty("https.proxyPort", "1234");
System.setProperty("com.google.api.client.should_use_proxy", "true");
Может кому-то поможет.
Firebase ios SDK вроде тоже так умеет, но я бы сам не отказался если бы кто-то показал как сделать подобное на ios.
Там есть другие внереестровые блокировки?
Я не знаю, с тех пор как подключил этот сервер пользователи больше не жаловались. В будущем если и на нем появятся блокировки - поставлю VPN прямо на сервер. Как-то так придумал.
Проверка на внереестровые блокировки
curl https://play.google.com/
Именно в таком виде ничего не выводит. С опцией -v много текста и в конце Connection … left intact.
Нет ошибок.
Блокировок нет.
Тогда, думаю, можно рекомендовать этот подход. Сервер брал самый дешевый на selectel.ru
Почему сurl на play.google.com? Все запросы в моем приложении шли на .googleapis.com правда это уже с включенным прокси в приложении.
Потому что .googleapis.com пока непонятно где и что блокируют, а https://play.google.com стабильно везде где есть внереестровые блокировки, и сайт близок к теме.
Есть полный список доменов которое приложение запрашивает при нулевом старте (без кеша, даты)?
firebaselogging-pa.googleapis.com
firebasestorage.googleapis.com
firestore.googleapis.com
firebaseinappmessaging.googleapis.com
firebaseremoteconfig.googleapis.com
Как у вас успехи? Приложение с базой firebase работает только через впн или ноунем провайдеров. Стоит ли ожидать разрешения проблемы со стороны Firebase Support. Написал им, но пока тишина.
У нас присвоен регион eur3 - мультирегион в восточной Европе. Сейчас нельзя изменить регион, его можно менять только при создании нового проекта в файрбейс. Может стоит попробовать создать новый проект, присвоить другой регион (Азию, Восток) и перенести на него базу? Спасибо. PS не программист.
Кстати, у пользователей, у которых отваливалась firestore database, вполне себе нормально в браузере открывался firestore.googleapis.com И еще, когда я сразу пытался поднять nginx чтобы проксировать все в него приходили CONNECT запросы по каждому адресу выше. Может это важно.
У iOS пользователей приложения были те же проблемы?
Попробовал создать проекты в разных регионах и все также. Не помогает
Да, они и остались. Прямо сейчас пытаюсь что-то похожее, как я сделал на Android, провернуть и на ios, но ничего не выходит. Задать “глобальный прокси” для ios приложения не выходит. Можно только перед отправкой самого запроса. Если кто поможет, буду признателен
Без сетевого дампа от клиента проблему не понять, imho.
firebase-ios-sdk и firebase-android-sdk используют разные стеки для TLS, у iOS С++ либы, у Android java. При этом через браузер работает (только неизвестно какой ip адрес получали для firestore). Если это не блок на стороне самих apis (не сетевой или TLS), возможно есть попытка цензора отсечь не api трафик и случился false positive. Вариантов у цензора масса, даже с данными из дампа воспроизвести блокировку из другой точки будет сложно. Это сетевой ад.
У меня есть пара пользователей у которых стабильно воспроизводится. Если есть способ снять дамп максимально просто, так чтобы бабуля разобралась, то возможно я смогу этот дамп добыть.
Всем привет. Через прокси тоже заработало.
Вот настройки для реализации на iOS:
Firebase осуществляет сетевой слой посредством gRPC.
Необходимо найти класс C++ “grpc_connection”
(лежит в папке FirebaseFirestore)
Найти Метод - CreateChannel (у меня на строке 300)
В параметрах к ChannelArguments добавить две строки
args.SetString(GRPC_ARG_HTTP_PROXY, “http://proxyHost:proxyPort”); (url и порт одной строкой (порт через двоеточие))
args.SetInt(GRPC_ARG_ENABLE_HTTP_PROXY, 1);
Непосредственно процедуру формирования данных для сетевого соединения с учетом настроек прокси можно отследить (проверить) в классе http_proxy (лежит в папке gRPC-Core) это строка 132 - absl::optionalstd::string HttpProxyMapper::MapName
Если прокси url указан некорректно, то Firebase в консоле напишет что-то вроде - cannot parse value of ‘http_proxy’ итп
Важно! При обновлении зависимостей Firestore проекта, эти правки перетрутся.
Надеюсь помог
Есть вариант чуть проще.
setenv("grpc_proxy", "http://x.x.x.x:yyyy", 1);
Вот это в любом месте своего кода и не будет перетираться.
Спасибо usnevst!
Ого, круто! А я ковырял гугловский SDK, тоже полезно )))
Вместо того, чтобы использовать обходные решения, гораздо продуктивнее было бы захватить трафик, как описано, например, здесь, выявить причину проблемы и проанализировать её, чтобы не гадать.
Есть примеры, когда проблема исчезала при переключении на wi-fi проводного провайдера?
Да, есть, провайдер к-телеком
Есть, причем множество. И есть примеры когда в сести wi-fi проводного провайдера те же проблемы.
Клиенты использовали нестандартные dns настройки? Провайдеры известны?
Переписываюсь с ТП Файрбейс,
Скриншот Ой!
Предлагаю вам также написать в ТП, более подробно изложить проблему (не программист), возможно у вас получится донести все нюансы данной проблемы, возможно предложить им решение.
Чтобы сообщить о проблеме, нужно сначала понять, где она происходит: блокируется ли какой-то конкретный домен, IP-адрес, порт. Без этой информации ни провайдер, ни поддержка Google вам никак не поможет.
Чтобы собрать эту информацию, достаточно захватить трафик и проанализировать его, либо выложить дамп сюда.
Все IP-адреса домена firestore.googleapis.com, которые мне удалось найти, открываются со всех точек в России, которые у меня имеются.
Я не разбираюсь особо в этом. Но вот попытался перехватить трафик, у меня пакеты идут туда когда пытаюсь обратиться к firestore базе данных. А в ответ никаких.
Хотя пинг к lu-in-f95.1e100.net проходит
У меня есть 1 пользователь, у которого сваливается по таймауту http://play.google.com Мегафон и NetByNet даже VPN не помогает. Какую информацию мы можем от него получить? Мой метод с прокси у него не работает. Т.е. даже запросы, которые проксируются через мой сервер в СПб у него не проходят.
Захватите трафик с помощью Wireshark, в pcap-файл. На вашем скриншоте недостаточно информации.
- Установите WireShark
- Выберите в нём сетевой интерфейс и укажите в строке filter:
port 53 or port 443 - Запустите захват
- Откройте сервис/запустите программу, которая не работает
- Проверьте, есть ли какие-то адреса, на которые не удаётся подключение (много красных строк TCP SYN либо много повторений ClientHello).
- Остановите захват кнопкой с красным квадратом, сохраните в pcap-файл.
Выложите дамп (pcap-файл) сюда или отправьте личным сообщением.
Он заблокирован с марта 2022: Блокировка news.google.com и недоступность play.google.com
Я нашел причину — Android-приложение meduza в режиме обхода блокировок обращается к Firebase (firestore.googleapis.com) при запуске.
Блокируют сочетание TLS ciphersuites + server_name + supported_groups средствами ТСПУ. Как я понимаю, оно стандартное, из Firebase SDK.
meduza-firebase.pcap (11.6 KB)
Столкнулся с той же проблемой. Заметил, что на некоторых операторах начали зависать обращения к firestore документам и отваливаться транзакции. Меняешь сеть или используешь vpn - проблема уходит. Налицо блокировки. Начал копать и разбираться. Приложение на Flutter. Работает нативно на android и ios, и есть web версия.
Любопытно, что на операторе, на котором нативные flutter (AOT) версии блокируются, web версия работает! Первое предположение было, что может как-то хитро разные IP используются, для натива и web, отсюда и разное поведение (с блокировкой и без) Забегая вперед - нет, IP адреса одинаковые. [64.233.165.95] Ну и это же логично, их же выдает DNS по UDP, а там user-agent’a нет.
Первое что потребовалось, это исключить влияние Flutter. Сделал тестовый проект на Android. Чистое Android приложение на kotlin с последними версиями библиотек - симптомы те же.
В логах немного разные ошибки в зависимости от провайдера, видимо зависит от того как провайдеры рубят коннекшен, или не рубят его. все не сохранилось, вот одна из них такая:
Caused by: io.grpc.StatusException: UNAVAILABLE: Channel shutdownNow invoked
Когда сеть без блокировок firestore работает по gRPC и создание документа выглядит так:
POST https://firestore.googleapis.com/google.firestore.v1.Firestore/Write HTTP/2.0
user-agent: grpc-java-okhttp/1.52.1
...
POST https://firestore.googleapis.com/google.firestore.v1.Firestore/Commit HTTP/2.0
user-agent: grpc-java-okhttp/1.52.1
...
Начал снимать TCP DUMP на разных провайдерах и анализировать их.
- не блочится на мобильном tele2
- блочится на домашнем wifi - оператор ufanet.ru
в том числе запечатлел нюанс, что web версия на “плохом” операторе работает и не блочится
tele2_not_blocked.pcap (9,8 КБ)
wifi_blocked.pcap (1,2 КБ)
web_wifi_not_blocked_long.pcap (13,4 КБ)
Обнаружил, что при handshake после “Client Hello” сервер не отвечает “Server Hello”. Handshake просто прерывается.
Далее начал искать по ключевым словам “Client Hello” и наткнулся на этот сайт и это обсуждение.
Надеюсь мои наблюдения будут полезны.
У меня два вопроса:
- Как ValdikSS узнал что блокировка была нацелена на программу от meduza?
- такая блокировка не является точечной, кто отвечает за то, чтобы уведомить РКН о необходимости пересмотреть правило блокировки, и будет ли это сделано в обозримом будущем? Или нам нужно костылять прокси обходы на клиентах?
Дополню, сейчас речь об од wifi сети оператора ufanet, который блочит работу с firestore.
Но как было замечено, блочатся только наивные приложения android и ios (Flutter).
То же самое приложение запущенное в браузере, web версия (Fluter) - не блочится.
Девайс тот же самый, приложение нативное и web работает с одним и тем же firestore, сеть одна и та же.
пакет Client Hello для handshake собираются немного по разному:
сравнить весь кусок wifi_hello_native_and_web - Diffchecker
У вас в дампе подтверждение для “Client Hello” приходит через 0.3 мс. Подтверждал явно не сервер.
Можете показать дампы для iOS?
Так, я сейчас уехал из дома на квартиру, поэтому сеть другая.
Но dom.ru тоже блочит.
mac подключен проводом к роутеру. share internet через wifi.
ios подключен к маку по wifi на созданный hotspot
на маке запущен wireshark
ip срезолвился другой 209.85.233.95
дамп domru_widi_blocked_ios_through_mac.pcapng (15,5 КБ)
Интересно TLS_CHACHA20_POLY1305_SHA256 идет первым, хотя в коде grpc++ он третий. В сборке отдельно от SDK, он таки третий.
Причина в железе, run-time условие:
// Order the bulk ciphers. First the preferred AEAD ciphers. We prefer
// CHACHA20 unless there is hardware support for fast and constant-time
// AES_GCM. Of the two CHACHA20 variants, the new one is preferred over the
// old one.
железка была iPhone xs, iOS 16.7.1
В сети пишут, что начиная с 5 iPhone используемые процессоры имеют поддержку AES инструкций.
Но в BoringSSL по факту игнорируют эту поддержку. Можно при сборке отдельно включить, но тогда приложение может упасть на древних гаджетах, если поддерживаются.
То есть нет ситуации, что где-то есть пользователи у которых отсутствуют блокировки по причине железа, у всех будет едино. Но вот есть ситуация, когда невозможно воспроизвести блокировку вне блокируемой платформы, даже если можно собрать тот же код. Тот, да не тот.
Возможно я не до конца понял Вас, но вот мои наблюдения насчет устройств:
На всех наблюдаемых устройствах (и android и iOS) блокировка на “плохих” операторах присутствует, если запускать нативную версию приложения. Как Flutter так и обычные. А вот если запустить веб версию (Fluttre) приложения блокировки нет.
Если есть подозрения, что поведение может отличаться в зависимости от устройств, обоснуйте причины и я проведу серию тестов на устройствах, до которых могу дотянуться.
Если говорить про Apple оборудование, вот такие устройства есть рядом.
iphone xs
iphone 12
iphone 13 pro max
iphone 14
ipad pro (не M)
ipad air 4
Можно попробовать приложение еще на маке запустить
Android оборудование тоже есть разнообразное.
А если на уровне приложения задать прокси, то повляет ли это на модерацию приложения в Apple/Google? Не будет проблем с тем, что трафик проксируется?
У нас всё норм на обеих платформах прошло.
У меня на обеих платформах все норм. Крутится уже 2 недели, 4 апдейта
Можете пожалуйста привести пример кода для обеих платформ?..
А вообще возможно кто то на флаттер это реализовал, можете скинуть?
Там выше, на 15 дней назад необходимо ленту отмотать. Есть примеры кода
Медуза добавила новый способ обхода блокировок Важнейшее объявление: мы придумали еще один хитрый способ, помогающий читать «Медузу» в России без VPN. Мы называем его волшебным! — Meduza
Они используют для своих ссылок домен storage.googleapis.com
Ждем ответа от РКН
Товарищи, никто в последние 3 дня не сталкивался с проблемами доступа к firebase? Очень похоже, что опять началось. И обход со squid сервером перестал работать. Пока есть 2 пользователя Питер - Билайн, Екатерингбург - Теле2. VPN помогает.