Yota и мобильный МТС, Новосибирск. Оба сайта заблокированы.
Приложение Google Play работает, на МТС по крайней мере.
Может быть, чтобы не искали впны удобным способом из дома.
р. Дагестан, провайдер ноунейм, два аплинка - мтс, мегафон.
news.google.com и play.google.com работают. Instagram и Facebook тоже работают.
ТСПУ у провайдера еще не стоит.
У меня не воспроизводится, попробовал направить на свой сервер и так же на ya.ru
Воспроизвелось только когда подставил айпишник другого гуглсервиса (google.com)
Возможно, особенность направления.
% curl -v --max-time 10 https://play.google.com/ --connect-to ::ya.ru
* Connecting to hostname: ya.ru
* Trying 87.250.250.242:443...
* Connected to ya.ru (87.250.250.242) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* Operation timed out after 10000 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 10000 milliseconds with 0 bytes received
МО, ростелеком - оба были недоступны, сейчас заработал https://play.google.com/.
UPD, play опять отвалился
16:30: на РТ открывается
19:50: опять блок
16:15: У меня начал открываться на одном провайдере (ОБИТ), но не на другом (Ростелеком).
16:40: Перестал открываться на ОБИТ.
C:\Users\Dimon>ping play.google.com
Обмен пакетами с play.google.com [64.233.165.100] с 32 байтами данных:
Ответ от 64.233.165.100: число байт=32 время=58мс TTL=248
Ответ от 64.233.165.100: число байт=32 время=60мс TTL=248
Ответ от 64.233.165.100: число байт=32 время=108мс TTL=248
Ответ от 64.233.165.100: число байт=32 время=26мс TTL=248
Статистика Ping для 64.233.165.100:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 26мсек, Максимальное = 108 мсек, Среднее = 63 мсек
C:\Users\Dimon>ping news.google.com
Обмен пакетами с news.google.com [74.125.205.138] с 32 байтами данных:
Ответ от 74.125.205.138: число байт=32 время=22мс TTL=105
Ответ от 74.125.205.138: число байт=32 время=23мс TTL=105
Ответ от 74.125.205.138: число байт=32 время=23мс TTL=105
Ответ от 74.125.205.138: число байт=32 время=23мс TTL=105
Статистика Ping для 74.125.205.138:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 22мсек, Максимальное = 23 мсек, Среднее = 22 мсек
А толку от пинга? ICMP никто не блокирует
It looks like play.google.com has been included in the blocking registry, while news.google.com is not. Does this mean that for the latter, it is only blocked by TSPU (for now)?
And it looks like they get hard throttled rather than outright blocking: it looks like once a triggering client hello is sent, if both sides keep sending rate low (~500 Bps), the traffic is able to pass through. It looks very similar to Twitter throttling in the early days (Early March).
I see neither in the Registry.
Yes, as far as I understand, all these “tarpits” are actually very hard throttled traffic.
Тоже удалось воспроизвести блокировку при обращении к сторонним хостам с play.google.com в SNI:
▲ ~ curl -vik --resolve play.google.com:443:104.16.249.249 --max-time 10 https://play.google.com
* Added play.google.com:443:104.16.249.249 to DNS cache
* Hostname play.google.com was found in DNS cache
* Trying 104.16.249.249:443...
* Connected to play.google.com (104.16.249.249) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* Operation timed out after 10001 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 10001 milliseconds with 0 out of 0 bytes received
▲ ~ curl -vik --resolve test.google.com:443:104.16.249.249 --max-time 10 https://test.google.com
* Added test.google.com:443:104.16.249.249 to DNS cache
* Hostname test.google.com was found in DNS cache
* Trying 104.16.249.249:443...
* Connected to test.google.com (104.16.249.249) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare-dns.com
* start date: Oct 25 00:00:00 2021 GMT
* expire date: Oct 25 23:59:59 2022 GMT
* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x14d813200)
> GET / HTTP/2
> Host: test.google.com
> user-agent: curl/7.77.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 403
HTTP/2 403
< server: cloudflare
server: cloudflare
< date: Tue, 29 Mar 2022 11:15:58 GMT
date: Tue, 29 Mar 2022 11:15:58 GMT
< content-type: text/html
content-type: text/html
< content-length: 151
content-length: 151
< cf-ray: 6f3830d3f9419d43-DME
cf-ray: 6f3830d3f9419d43-DME
<
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>cloudflare</center>
</body>
</html>
* Connection #0 to host test.google.com left intact
Если делаю запрос на cloudflare с play.google.com в SNI - блокирует, если передаю test.google.com - нет
Кинул измерение через atlas, надеюсь всё правильно в настройках указал:
Чет я не очень доверяю этому результату, потому что детальное изучение показало там наличие моей собственной пробы, с успешным результатом, хотя гарантированно у меня оно не работает 
“Even I do not really trust this result, because a detailed study showed the presence of my own sample there, with a successful result, although it is guaranteed that it does not work for me” (from Google translation)
I feel the meaning is lost in translation, but it seems that you’re referring to some studies that show RIPE measurements can be skewed? Can you share the study? Thanks!
Hi! In this case it looks like my ISP’s DPI is being weird again, like it was in twitter study, so cannot attribute it directly to Atlas Probe. Seems like there is some load balancing involved and sometimes it gets lucky enough to pass as “Not blocked” result. Can send pcap if you interested
At least, I wouldn’t trust any results in that one from ertelecom/domru, because something weird is happening in here. For example, for AS12772 there is one successful and one failed result. For AS50543 there is two failed and two successful.
Seems like there is some load balancing involved and sometimes it gets lucky enough to pass as “Not blocked” result.
I’ve seen similar behaviors on other ISPs as well: there’s a chance (small though) that a connection which should have been blocked/hard-throttled can pass the DPI uncensored. It could be load-balancing, or it could be that the DPI has a fail-open policy. Would be interesting to do a stress test see if there’s a correlation between “pass rate” with the loads.
For example, for AS12772 there is one successful and one failed result. For AS50543 there is two failed and two successful.
I don’t know if AS-level provides sufficient granularity when it comes to identify TSPU deployment. I don’t have evidence that suggests otherwise (since currently only tested on two networks, with one vantage point for each), but here’s something interesting:
Say we have a client C and a server S, C sends a clienthello in an attempt to trigger censorship after TCP handshake. We know that if C.ip == non_RU and S.ip == RU (a connection from abroad), then the connection would not be censored (at least for TSPU). And the revered would be censored. The interesting case is C.ip == RU.local and S.ip == RU as well. If S is not in the same AS as C, the connection is censored. But if S and C belong to the same AS, the some connections would be censored and some not depending on S.ip. For both networks I tested, {S.ip} that would NOT trigger censorship is a (small) strict subset of all IPs from that AS.
The way I interpret this is that {S.ip} falls under the same TSPU box’s “jurisdiction” as C.ip. It could be that local connections pass through different interfaces or that the box maintains a list of IP blocks that are considered local. But either way, I feel this somewhat confirms that TSPUs are far away from the backbone and that observing a censorship event from some vantage points of an AS does not mean the whole AS is censored uniformly.
(Not sure if this makes sense)
Спустя почти два месяца получил ответ о причинах блокировки news.google.com Роскомнадзором:
В связи с Вашим обращением сообщаем следующее.
Статьей 15.3 Федерального закона от 27 июля 2006 г. № 149-ФЗ
«Об информации, информационных технологиях и о защите информации» (далее – Федеральный закон № 149-ФЗ) определен порядок ограничения доступа к информации, содержащей призывы к массовым беспорядкам, осуществлению экстремистской деятельности, участию в массовых (публичных) мероприятиях, проводимых с нарушением установленного порядка, ложных сообщений об актах терроризма и иной недостоверной общественно значимой информации, распространяемой под видом достоверных сообщений, которая создает угрозу причинения вреда жизни и (или) здоровью граждан, имуществу, угрозу массового нарушения общественного порядка и (или) общественной безопасности либо угрозу создания помех функционированию или прекращения функционирования объектов жизнеобеспечения, транспортной или социальной инфраструктуры, кредитных организаций, объектов энергетики, промышленности или связи, информации, содержащей обоснование и (или) оправдание осуществления экстремистской деятельности, включая террористическую деятельность, предложение о приобретении поддельного документа, предоставляющего права или освобождающего от обязанностей, информационных материалов иностранной или международной неправительственной организации, деятельность которой признана нежелательной на территории Российской Федерации в соответствии с Федеральным законом от 28 декабря 2012 г. № 272-ФЗ «О мерах воздействия на лиц, причастных к нарушениям основополагающих прав и свобод человека, прав и свобод граждан Российской Федерации», или организации, деятельность которой запрещена в соответствии с Федеральным законом от 25 июля 2002 г. № 114-ФЗ «О противодействии экстремистской деятельности» или Федеральным законом от 6 марта 2006 г. № 35-ФЗ «О противодействии терроризму», сведений, позволяющих получить доступ к указанным информации или материалам, информации, указанной в статье 6.2 Федерального закона от 10 июля 2002 г. № 86-ФЗ «О Центральном банке Российской Федерации (Банке России)», включая случай поступления уведомления о распространяемой с нарушением закона информации от федеральных органов государственной власти, органов государственной власти субъектов Российской Федерации, органов местного самоуправления, организаций или граждан, а также при поступлении уведомления о распространяемой с нарушением закона информации от Председателя Центрального банка Российской Федерации или его заместителей в отношении информации, указанной в статье 6.2 Федерального закона от 10 июля 2002 г. № 86-ФЗ «О Центральном банке Российской Федерации (Банке России)».В соответствии со статьей 15.3 Федерального закона № 149-ФЗ ограничение доступа к интернет-ресурсам, содержащим вышеуказанную информацию, осуществляется на основании требования Генерального прокурора Российской Федерации или его заместителей.
Так, на основании требования Генеральной прокуратуры Российской Федерации доступ к интернет-ресурсу https://news.google.com был ограничен на территории Российской Федерации.