Клиенты использовали нестандартные 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 - Diff Checker
У вас в дампе подтверждение для “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 апдейта
Можете пожалуйста привести пример кода для обеих платформ?..
А вообще возможно кто то на флаттер это реализовал, можете скинуть?