[Deleted]

С DHT никаких проблем нет, проверяю вот так:

magnet:?xt=urn:btih:MSUYBK7G4RECE25ZGC5AMFMS4RGDPANB

Это магнитка на ubuntu desktop 21.04, без указания трекеров в ней, в настройках Transmission выключен PEX, оставлен только DHT

Надолго ли это? Добавить новую сигнатуру для блокировки протокола на существующие dpi проще простого, а чтобы устранить в них дыры, это уже сложнее

Красиво звучит, но…
DoH уже блокируется, ESNI блокировали в виде эксперимента два года назад и вполне удачно. О проблемах с wireguard почитай в соседней теме. Единственное чего нет у нас - active probing, но это пока. В случае чего, можно взять готовое решение у Китая

Было замечено это еще во время создания этой темы. Я тоже этому удивился, видимо им просто лень

Чем больше сигнатур, тем медленнее будет работать DPI система. Пару месяцев назад в СМИ проходила информация, что на скоростях выше 10 Гбит/с уже в байпасс уходят.

Тем не менее, добавить пару самых популярных сигнатур, вроде bittorent (уже), да wireguard можно. Хотя замечание верное, хоть надежда есть, что они не смогут все протоколы порезать

Это лишь пока его массово не начнут форсировать Google/Mozilla в своих браузерах, игнорируя обычный DNS.

Сейчас DoT/DoH используют буквально единицы, т.е. особого шума от блокировки не будет.

Я вообще не понимаю чем им DoH мешает? Блокировки по DNS уже даже мелкие провайдеры не используют.

Хотят собирать досье через незашифрованный DNS, как делают в Великобритании что-ли?

DHT discovery и WireGuard блокировали по размеру пакета.

Весь трафик на 53 порту наверное каждый провайдер давно роутит на свои DNS-серверы, поэтому они и продолжают работать. Вам просто отвечает не 8.8.8.8, а местный сервер провайдера.

Проверить очень легко по скорости ответа. Если ниже 10 мс. - отвечает провайдер.

Чуть не до конца дочитал, бывает)
А так да, такие штуки довольно хороши, хотя уже крайняя мера, когда давно не будет работать goodbyedpi и заблочат обычные прокси и vpn

Где-то видел, что блокировали торренты по коомбинации размера пакета и первым пару байтам. С ESNI да, эффективное решение для его вычисления найти сложнее

Так все-таки зачем? Какой смысл в блокировке DoH?

Меня всегда такой факт забавлял. В РФ есть статя за порнографию, поэтому все ресурсы с ней блокируют. Вроде как в законе нет исключений, чтобы можно было разрешить ее распространять. Но, видимо, порнуха на порнхабе недостаточно порнушная в сравнении с другими ресурсами, чтобы его блокировать. Насколько я помню, у нас нет такого, что можно поставить фильтр на 18+ и создавать порносайт, но чудеса бывают, как в случае с разблоком порнхаба)

C полпинка очень трудно ответить на этот вопрос…

DNS у большинства пользователей - физических лиц и так настроен по простому протоколу без шифрования, любой провайдер, если захочет, развернет его себе. У кого-то это часть блокировок, кто-то желает анализировать, куда клиент ходит. DoH и DoT мало кто использует, но все стремительно меняется - стоит, например, Google включить это по умолчанию в новых версиях Андроида…

Есть надежда, что дадут задний ход, хотя бы немного проанализировав бессмысленность того, что делают.

Все просто. Раньше я мог зайти на рутрекер и скачать фильм. Потом мне пришлось использовать анонимайзер, потом vpn, потом пришлось пользоваться goodbyedpi (и написать свою dpitunnel-cli). Как видишь, с каждым разом приходится шевелиться все больше и больше, причем как пользователю, так и разработчикам/администраторам. Обычный юзер теперь пять раз подумает, а нужен ли ему этот фильм или, что актуально в последнее время, сайт УГ или нет. Отрицать то, что посещаемость УГ или рутрекера после блокировок, да еще сложнообходимых, упадет, просто глупо

Про одно из предназанчений тех же dpi - анализ трафика клиента, какую рекламу подсунуть и прочая маркетология, тоже звучит хорошо. Но ркн от этого выгоды мало

Уже нет. СМИ писали, что Ревизоры давно научились такое проверять и провайдеру прилетит огромный штраф в случае если блокировки выполняются только по DNS.

Мне тоже так кажется. В прошлом году видел презентацию одной DPI системы для провайдеров, в которой одной из фич как раз был анализ DNS и построение профиля каждого абонента на основе этих данных.

Самое забавное, что та система умела анализировать через DNS и SNI зашел ли абонент на сайт провайдера-конкурента, что трактуется как желание сменить провайдера, а значит нужно ему позвонить и предложить скидку и т.п.

@zhenyolka

Возможно, кое-где сработает domain fronting. Сходу для google такого домена не нашел.

I, too, have not found a domain that works for fronting with dns.google. There were many that worked with dns.google.com, but not dns.google, if I remember correctly.

Hmm, but the goal is not to hide the Host header, but to hide the SNI and DNS query. Connecting to dns.google and sending a Host of whatever.google.com may work, but it is still blockable because the censor sees a connection to dns.google. You need the opposite: connecting to whatever.google.com and sending a Host of dns.google. In my tests, the latter technique does not work.

I believe this is what you are describing. It “works” in the sense of returning a response, but the censor still sees a DNS query and SNI for dns.google, which means it can be blocked.

$ curl -H 'Host: docs.google.com' 'https://dns.google/resolve?name=example.com&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"example.com.","type":1}],"Answer":[{"name":"example.com.","type":1,"TTL":13490,"data":"93.184.216.34"}]}

What you really want is the following, but in my tests it does not work:

$ curl -H 'Host: dns.google' 'https://docs.google.com/resolve?name=example.com&type=A'
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  ...
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That’s an error.</ins>
  <p>The requested URL <code>/resolve</code> was not found on this server.  <ins>That’s all we know.</ins>

Note, in these examples I used the JSON /resolve endpoint, not the RFC 8484 /dns-query endpoint, but I believe the result is the same in terms of domain fronting.

Sending request to 8.8.8.8 or 8.8.4.4 with google.com SNI works for DNS resolving, but not for other (regular) IP addresses.

$ curl --resolve *:443:8.8.4.4 -k 'https://google.com/resolve?name=example.com&type=A'

{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"example.com.","type":1}],"Answer":[{"name":"example.com.","type":1,"TTL":4786,"data":"93.184.216.34"}]}

Тот пример, что привели вы — не domain fronting. Domain Fronting заключается в подмене SNI (это то, что видит DPI), а вы наоборот подменяете Host.

Ни мне, ни @tango не удаётся найти такой домен, при нормальном обращении к которому (на оригинальные IP-адреса и с оригинальным SNI) можно бы было отправить DNS-запрос внутри установленной TLS-сессии — а именно в этом суть domain fronting.

Есть ненулевая вероятность, что весь этот цирк с конями начали ровно за 10 дней до выборов только из-за одной проги Навальный, чтобы ко дню голосования максимально затруднить получение информаци по кандидатам про УмГ.

Хм, а что, у кого-то есть другие предположения? По-моему, это довольно очевидно.
Сторонники Навального рекламировали SDK NewNode, которое использует DHT, а в Android-приложении вбиты dns.google и doh.opendns.com, но не dns.google.com (поэтому он работает).

Тогда флаг им в руки блокировать или замедлять YouTube. Вроде бы там обещали зачитывать список кандидатов.

dns.google.com может быть указан в качестве DoH, но не DoT-резолвера, я правильно понимаю?

Да, но он отсутствует в Android-приложении Навального, поэтому его не блокируют.

Однако, удалось протестировать dns.google.com в качестве приватного DNS в Андроиде (если я правильно понимаю, там может быть только резолвер с DoT). Хотя точно не знаю. Но оно работает.

А вот сделать запрос формата https://dns.google.com/dns-query не вышло.

Всё верно, на дроиде только DoT и dns.google.com всегда работал

Помогите, пожалуйста, разобраться с тем, как обрабатываются DNS-запросы в Андроиде.
В системе указан “Частный DNS” (Сloudflare) - DoT.
В браузере указан DoH cloudflare-dns.com.
Я правильно понимаю, что прописанное в настройках браузера - первично и все имена резолвятся именно тем резолвером, который указан в браузере? А если отключить DoH в браузере, то резолв ляжет на “частный DNS”, указанный в настройках?

По идее, все должно быть именно так. Но при этом все эти запросы проходят в нешифрованном виде, на 53 порт резолвера Cloudflare (что хоть и работает, но небезопасно) - это видно с помощью вайршарка. Получается, что где-то происходит fallback. Интересно, где… и почему он происходит. Или в Андроиде так задумано - если недоступен DoT, то уходит обычный незашифрованный запрос?

И недавно, как раз с началом новых блокировочных битв, при открытии некоторых (не всех) страниц в браузере возникает вот такая проблема

Примерно на секунду-две, после этого происходит повторная попытка и страница загружается нормально.
Это просто как мимолетное виденье, не сразу смог поймать и заскринить.

Человек, которому я пытаюсь помочь избавиться от проблем с DNSами, использует Shadowsocks (сервер в Европе, без каких-либо блокировок). Получается, Shadowsocks не проксирует DNS-запросы или такова общая политика Андроида?

Странно получается: трафик вроде бы проксируется, а DNS-запросы нет и усилиями РКН интернет все равно ломается.

В клиенте Shadowsocks, используемом этим пользователем, есть настройка “DNS-сервер”, но, такое впечатление, она игнорируется - что бы там ни было прописано, никакого эффекта это не имеет (если оставлять ее пустой - тоже).

Буду рад, если поможете разобраться и помочь человеку.

Да, важное дополнение - при проверке на https://www.dnsleaktest.com/ выдаются DNS-резолверы, используемые на Shadowsocks-сервере (не имеют никакого отношения к Cloudflare, там резолверы от Google и два резолвера Tor).

This story says that the RKN press service warned DNS and CDN providers over access to the Smart Voting app:

“Роскомнадзор и Центр мониторинга управления сетями связи общего пользования РФ (ЦМУ ССОП РФ) на основании требований Центральной избирательной комиссии и Генеральной прокуратуры России направили в адрес ряда иностранных компаний, в том числе провайдерам DNS- и CDN-сервисов, письма с требованиями прекратить предоставление возможностей для обхода ограничения доступа к приложению и сайту “Умное голосование” на территории Российской Федерации”, - сказали в пресс-службе.

…

Кроме того, Роскомнадзором и ЦМУ ССОП РФ установлено, что средства обхода блокировок предоставляют более 10 иностранных провайдеров, расположенных на территории США, Украины, Германии, Франции, Японии, Великобритании и других государств. Законные требования о недопустимости предоставления технических средств для обхода ограничения доступа игнорируются магазинами приложений компаний Apple и Google, DNS- и CDN-сервисами Google, Cisco, Cloudflare и ряда других компаний.

“Roskomnadzor and the Public Communications Network Management Monitoring Center of the Russian Federation (PCMC RF) sent letters to a number of foreign companies, including providers of DNS and CDN services, with demands to stop providing opportunities to circumvent access restrictions to the Smart Voting app and website in the Russian Federation, based on the requirements of the Central Election Commission and the Prosecutor General’s Office of Russia,” the press service said.

…

In addition, Roskomnadzor and the SSOP CMU found that more than 10 foreign providers located in the United States, Ukraine, Germany, France, Japan, the United Kingdom and other countries provide blocking circumvention tools. Legal requirements regarding the inadmissibility of providing technical means to bypass access restrictions are ignored by Apple and Google app stores, DNS and CDN services of Google, Cisco, Cloudflare and a number of other companies.

I found the TASS story through a web search that led me to the following site, which also says something about YouTube:

According to Klimarev, the Russian authorities may block YouTube in the country during the elections on September 18-19.

Прилично поломал голову с этим Shadowsocks, в итоге установил человеку OVPN-сервер и большую часть проблем как ветром сдуло.

И с частным сервером сейчас нет затруднений, и резолвер антизапрета (проверял и этот конфиг) отрабатывает как надо.

На следующей неделе ситуация в России, вероятно, станет вообще веселой.

Ростелеком рассылает по клиентам запрет на использование DNS-серверов Google и Cloudflare и рекомендует использовать свои DNS-серверы или серверы “Национальной системы доменных имен”.

Об изменении DNS адресации.pdf (229.3 КБ)

Скорее всего, состоятся блокировки крупнейших публичных DNS-серверов перед выборами (и может пострадать множество клиентских устройств).

В клиенте SS есть несколько настроек, которые могут влиять на проксирование DNS-трафика. В частности в опциях маршруты должны быть выставлены в положение “Все”.

Ты только сейчас до этого догадался? Я уже был уверен в этом еще при принятии чебурнета, а когда создавал эту тему неделю назад, убедился окончательно.

Никакое множество устройств не пострадает. Большинство роутеров исполтзуют днс от оператора, а значит и их клиенты. Тем, кто ручками вписал вражеские сервера, просто скажут сменить на наши, а открытые днс запросы начнут/уже начали перенаправляться на сервера оператора

Вас послушать, так создается впечатление, что никакого Интернета вещей нет, а есть только “роутеры”.

Это я прочитал, найдя в гугле комментарий об этом от одного из разработчиков SS, да.
Маршрут был установлен именно как “Все”. И, несмотря на это, запросы почему-то не проксировались.

Нет, догадался не только сейчас. Я по натуре пессимист и всегда готовлюсь к худшему. Но какая-то надежда все-таки теплилась.

Что будет делать ТСПУ с открытыми запросами на 8.8.8.8? Спуфить ответы? Сам перенаправлять на рекурсоры НСДИ? Просто заблокируют 8.8.8.8 и 8.8.4.4 по IP-адресам?

Точный ответ не знает никто. На моем операторе, к примеру, запросы перенаправляются на сервер провайдера. Думаю, ничего сложного в том, чтобы прямо на ТСПУ перенаправлять запросы к нужным адресам, нет. Во всяком случае, намного менее затратно, чем блочить wireguard/bittorent, а на это у них мощностей хватает. Блокировать по ip совершенно нельзя, так как в таком случае реально много устройств с прошитыми dns просто отвалятся

Пришло буквально минут 10 назад, спб, skynet.

image783×729 64.7 KB

Такая блокировка, видимо, все же на несколько часов была (9 или 10 сентября) на мобильном Билайне. При подключении к WiFi-сети Huawei E8372 с этой SIM-картой (DNS там были указаны именно от Гугла) Android-телефон наотрез отказывался потреблять интернет из этой сети, показывая пиктограмму в виде восклицательного знака (Нет соединения с интернетом). После замены DNS-серверов в роутере на Яндексовские, возможность использования этой сети телефонами вернулась.

Длилось около часа, потом проблема исчезла.

To me, this looks like a letter sent from company management to employees, not to customers.

от 08.09.2021 №
01/05/23104/21

Согнасно списка рассылки

Об изменении DNS адресации

Уважаемые коллеги!

В целях организации устойчивого доступа абонентов в сеть «Интернет» прошу вас дать указания всем заинтересованным подразделениям, запретить к использованию для выдачи абонентам с BRAS / DHCP и в технологических сетях адресов DNS Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1) и сервиса doh.opendns.com. Для выдачи абонентам и в технологических сетях использовать DNS сервера под управлением ПАО «Ростелеком» или IP адреса Национальной системы доменных имен (195.208.6.1, 195.208.7.1, 2a0c:c9c7:a::1, 2a0c:a9c7:b::1). В случае отработки клиентских обращений пользователей с неработоспособностью сервисов, исключить рекомендации по использованию IP адресов DNS 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1.

Директор по мониторингу и оперативно-техническому управлению сетями связи
В.Ю. Серман

М.В. ИВанов
(700) 2588

dated 08.09.2021 №
01/05/23104/21

According to the mailing list

About the change of DNS addressing

Dear colleagues!

In order to organize stable access to the Internet for subscribers, I ask you to instruct all departments concerned to prohibit the use of DNS addresses Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1) and doh.opendns.com service for issuing to subscribers with BRAS / DHCP and in technology networks. Use DNS servers managed by Rostelecom or IP addresses of the National Domain Name System (195.208.6.1, 195.208.7.1, 2a0c:c9c7:a::1, 2a0c:a9c7:b::1) for issuing to subscribers and in technological networks. In the case of handling client requests from users with service unavailability, to exclude recommendations for the use of DNS IP addresses 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1.

Director for Monitoring and Operational Management of Communications Networks
V.Y. Serman

M.V. Ivanov
(700) 2588

Опубликовано в Новости

знаю что многие любят использовать DNS 8.8.8.8 или 1.1.1.1

обратите внимание что Роскомнадзор стал их фильтровать время от времени. вероятно в целях посмотреть что да как будет если фильтрануть.

в общем если у вас вдруг пропал интернет на пару часов а потом появился, вы посмотрите может это у вас внешний DNS просто перестал работать

наши адреса приходят автоматически но на всякий случай:
93.100.1.2
94.19.255.3

— Форум сети SkyNet!

Posted in News

I know that many people like to use DNS 8.8.8.8 or 1.1.1.1

note that Roskomnadzor filters them from time to time. probably in order to see what happens if you filter it.

in general, if you suddenly lost the internet for a couple of hours and then appeared, you look may be you external DNS simply stopped working

Our addresses come automatically, but just in case:
93.100.1.2
94.19.255.3

- SkyNet Forum!

I can’t confirm it, but some people said Rostelecom sent these letters to several corporate customers as well.

Как выяснить перехватывает ли провайдер DNS ?

Как проверить эту самую скорость ответа ? nslookup’ом ? Или time + nslookup ? Если последнее, то

Server: 8.8.8.8
Address 1: 8.8.8.8 dns.google

Name: rutracker.org
Address 1: 195.82.146.214 rutracker.org
Address 2: 2a03:42e0::214

real 0m1.622s
user 0m0.690s
sys 0m0.130s

значит ли это, что происходит перехват запросов ?

Если у вас linux, то можно вот так:

dig a rutracker.org @8.8.8.8

dig a ya.ru @8.8.8.8

Внизу будет Query time, если для заблокированного сайта (rutracker.org) время сильно меньше, чем для незаблокированного (ya.ru) - значит перехватывает только для заблокированных. Если для обоих хотя бы двузначное - то скорее всего не перехватывает. Если для обоих что-то нереалистичное (вроде 3-4 мс) - перехватывает всё.

А каким параметром вы смотрите время в nslookup?

rutracker.org через dig показывает 133ms. Результат не сильно отличает от использования time с результатом в поле sys time. Для ya.ru dig показывает 81ms

Там утилита time перед nslookup использовалась. У меня нет полной уверенности, что там точное время отображается.

Само собой, еще можно посмотреть на айпишник, который вернулся. Мой провайдер подменяет айпишник на айпишник своей странички с “бла-бла-бла сайт был заблокирован”

Это дело пока глушится gdpi. Или для чистоты эксперимента нужно его вырубать ? Вроде gdpi на dns не влияет.

Все помнят о письмах Ростелекома в региональные филиалы?
Так вот, сегодня в канале ЗаТелеком Telegram: Contact @zatelecom
появился документ от Минобрнауки, который очень похож на письма Ростелекома, но в нем есть фраза “…в срок до 17 сентября 2021 подключится к DNS-сервисам российских операторов или к Национальной системе доменных имен…”. Может эта информация уже была, но меня заинтересовал срок 17 сентября 2021 года. Ранее я его нигде не видел. Возможно, это дата блокировки DNS?

Плюс там, помимо прочего, говорится не только об ограничении DoH протокола, но и DoT и обычного DNS для указанных серверов

15.09.2021 ~21:30-22:45
провайдеры мегафон и теле2 спб

внезапно https://docs.google.com стал возвращать RST
на трех разных подключениях - с модема huawei и независимо с 2х телефонов на этих двух операторах
проверка показала, что идет блокировка по SNI.
на любом IP
остальной инет работает нормально на тех же устройствах

предположительно тестируют что-то на ТСПУ

Работают следующие методы обхода
disorder2 - деление clienthello на 2 части и перепутывание порядка отправки tcp сегментов
split - деление clienthello на 2 части и вставка нулевых фейков между ними
Не работает
split2 - простое деление clienthello на 2 части

эта схема блокировки отличается от основного блокировщика на теле2 - он от rdp.ru. обходится через fake
следовательно, вывод - блокировка выполняется на отдельном девайсе

Из-за вот этого?

Мегафон, спб, отвал - RST

Screenshot_20210915-231235_Chrome1080×2220 106 KB

Теле2, СПб, проблем не наблюдается.

Домру/Йота Красноярск - проблем не было (и нет сейчас)

Ртк/МТС Смоленска - пока что проблем не возникало, посмотрим что будет к утру.

telegra.ph также отвал, видимо кто-то сделал УГ-over-telegra.ph

в реестре нет, на ТСПУ блок

Создал отдельный топик для телеграфа:

https://ntc.party/t/telegra-ph/1302/3

минутка политоты, вытирайте если хотите

спасибо главным пентестерам гулага паше и леше
после паши получили госдпи
после леши будут белые списки на протоколы и адреса

нет, это не репрессивный перенос. возможно конспирология

p.s. начали энфорсить протоколы на iana портах для подозреваемых адресов

Подозреваемых в чём? Хотите сказать, что на порту 443 для каких-то адресов не разрешается не-TLS-трафик?

подозреваемых к принадлежности к блокируемому сервису
блокируют “мусор” и трафик “неизвестного” источника на 1194 удп, 443 тсп, 53 удп

Предоставьте pcap’ы.

Потрясающей скудоумности пост

В 2018 применялся как минимум против Socks5-прокси для Telegram. См. слайды 16 и 17 моего старого рассказа на CIF.