
Комментарии 193
Ещё этот DNS очень тормозит и плохо отвечает на запросы.
Всегда, когда разбираешь работу этой системы, помни - ребята с "той" стороны тоже хабровчане и скорее всего у них уже открыт тикет с пометкой "срочно" :D
Запрету v1 10 лет скоро, работает. Так что не на все "срочно" есть "решено".
Да, разумеется! Я просто не очень четко мысль выразил. Я имел в виду разбор новых изменений и решений.
Жаль zapret не справляется, когда нет связи с игровыми серверами wb games при игре на playstation.
Но выход все равно есть. Направлять траффик для нужного домена на другой DNS сервер

Таким образом работает умный дом Tuya и мои розетки для аквариума. А также сегодня настроила для Hogwarts Legacy, чтоб не крашится при заходе в игру.
У меня openwrt 24+ doh и zapret2, но я не заметила каких-то проблем с doh, только с dns запросами к игровым серверам. Провайдер Skynet. Долго я с ними ругалась они вместо помощи до сих пор считают, что решать проблемы связи не обязаны, "мы не обходим блокировки" - а где хоть один документ что сервера wb games блокируются? Это вполне легальный трафик, тем не менее поддержка давно болт забила на то что она техническая. Давно пожалела что оплатила по акции до ноября. Никому не советую - будете за свой счёт еб##### при каждом удобном и неудобном случае.
Они даже пишут тут в корпоративном блоге
Это да только они мне заблочили Московский рабочий ВПН, страшно важный для всей страны, ну по крайней мере по словам Мантурова. Хорошо что заметили и починили а то работать через сотовую сеть очень медленно.
СПб, DOCSIS Ростелеком, около часа ночи 24 августа заблокировали DoT 8.8.8.8 и 1.1.1.1 - до этого много лет работало. Не знаю, как там ТСПУ, просто заблокировано.
Ростелеком, как замечают люди, пытается бежать впереди паровоза и даже без всяких ТСПУ блокирует (не известно каким образом, но дубово) порой то, что совсем не запрещено, а "им показалось". И делают они это уже давненько.
Ну и хорошо, значит, меньше мешать работе будут.
У меня кстати не так. В одной квартире Ростелеком, в другой местечковый провайдер, так он гораздо агрессивнее и быстрее всё блокирует
Провайдер, с некоторых пор (а именно - с момента установки ему в добровольно-принудительном порядке комплекса ТСПУ), сам по себе НИЧЕГО не блокирует. Так что не грешите на обычных людей, это не они.
емнип, установка тспу никак не отменяет обязанность провайдера самостоятельно блокировать ресурсы из реестра. и я не слушал, чтобы кто-то упразднял «ревизор», который стоит у провайдера и проверяет как он блокирует.
работаю в провайдере, ничего сами не блокируем, ревизоры тоже запускаются очень интересным способом)
установка тспу никак не отменяет обязанность провайдера самостоятельно блокировать
Отменяет, и обязанность, и ответственность за неблокировку. В закон было внесено соответствующее изменение, и (по нашим временам) - достаточно давно уже.
Но некоторые провайдеры сохраняют существующую систему в дополнение к ТСПУ.
Насколько я знаю имеют место старые решения и старые методы блокировок (через суд), по которому некоторые пространства рутрекера блокируются и по сей день.
Старые - это до принятия поправок в закон "Об информации...", когда вообще по предписаниям прокуратуры блокировали. По нынешним временам - это очень давно.
В данном случае блокировали на основании закона по реестру, и на основании изменений в этот же закон - сняли ответственность (вообще любую, в т.ч. перед абонентами) с провайдеров в случае установки ТСПУ. Но зато наказывается самовольный пропуск трафика мимо ТСПУ.
Но изменение не запретило блокировать собственными силами провайдеров, потому продолжает работать у некоторых провайдеров.
Не подскажете, где об этом почитать? Можно в личку. Спасибо.
Подскажите НПА, которым с операторов сняли ответственность за неблокировку? Тоже работаю в операторе связи, у нас нет ТСПУ (мы мелкие), у апликнов конечно есть. Так нам можно теперь убрать систему блокировки?
Эта норма действует с 1 ноября 2019 года.
Федеральный закон «О связи». Статья 46. Пункт 5.1.
“Оператор связи, оказывающий услуги по предоставлению доступа к информационно-телекоммуникационной сети “Интернет”, не обязан ограничивать доступ к информации, распространяемой посредством информационно-телекоммуникационной сети “Интернет”, доступ к которой должен быть ограничен в соответствии с Федеральным законом от 27 июля 2006 года N 149-ФЗ “Об информации, информационных технологиях и о защите информации”, если доступ к такой информации в сети связи оператора связи ограничивается с помощью технических средств противодействия угрозам в порядке централизованного управления сетью связи общего пользования”
А, ну это для тех, у кого ТСПУ стоит. Не наш случай.
Обязанность ставить "ревизор" - никуда не делась, тут всё по прежнему.
А вот получать выгрузки из реестра и самостоятельно блокировать по ним - походу отменили (сам удивился, когда узнал что теперь этого не требуют).
местечковый провайдер, так он гораздо агрессивнее и быстрее всё блокирует
Ему страшнее. У него в отличие от ростелекома, не Медведев директор.
Ростелеком, как замечают люди, пытается бежать впереди паровоза
Тем не менее, он отстаёт от Дома.Ру, который начал это практиковать примерно неделю назад.
«Дом.ру», по моим наблюдениями, начал практиковать забеги перед паровозом еще в 2017.
Да-да, lawfilter.ertelecom.ru только на оголённых DNS-серверах был как раз примерно с 2017.
Так Роскомнадзор ещё году в 2018 рекомендовал провайдерам перехватывать трафик по 53 порту и заворачивать на провайдерский резолвер.
И дело тут не в беготне впереди паровоза, а в том, что это позволяло снижать нагрузку на провайдерский DPI. Когда абонент, использующий незащищённый DNS, пытается зайти на условный navalny.com, то перед установкой соединения его оборудование запрашивает у DNS-сервера "а какой IP-адрес у этого домена?". Если запрос перехватить и в ответ отдать NXDOMAIN или адрес заглушки, то соединение с navalny.com попросту не случится, следовательно, это соединение не придётся разбирать с помощью DPI, обнюхивая SNI. Завернул трафик по 53 порту через iptables на свой резолвер (который для "определенных" сайтов выдаёт неправильные ответы) - и можно нехило так снизить нагрузку на свой DPI.
В некоторых странах типа Великобритании или Австралии это (фильтрация ответов провайдерского DNS, без перехвата трафика к сторонним DNS) вообще единственный способ, которым провайдеры блокируют доступ к определенным сайтам. Там считают, что если уж пользователь очень захочет, то блокировку обойдёт, поэтому не видят смысла устраивать гонку брони и снаряда. Государство требует хоть как-то блокировать - вот вам формально заблокировано.
Относительно перехвата DNS запросов со стороны операторов связи у меня есть следующие наблюдения:
Эр-телеком: подмены dst адреса нет, при использовании стороннего резолвера используется реально введённый DNS сервер в настройках системы или роутера (это видно по пингу и по всяким различным тестам "DNS утечки"), однако при попытке резолвинга заблокированных доменов по реестру, будет отдаваться IP-адрес заглушки (отдаёт так же только по UDP). Они отдают заглушку даже если резолвить домены извне:
~# dig rutracker.org @188.187.188.255 ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> rutracker.org @188.187.188.255 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21106 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;rutracker.org. IN A ;; ANSWER SECTION: rutracker.org. 600 IN A 188.186.146.207 ;; Query time: 46 msec ;; SERVER: 188.187.188.255#53(188.187.188.255) (UDP) ;; WHEN: Sat Aug 29 12:38:58 MSK 2026 ;; MSG SIZE rcvd: 47При этом реального DNS сервера на
188.187.188.255- нет~# dig 2ip.ru @188.187.188.255 ;; communications error to 188.187.188.255#53: timed out(IP-адрес был взят наугад)
Уфанет: подмены ответа при использовании других резолверов нет, но на операторских DNS серверах заблокированные домены по реестру не резолвятся
Ростелеком: на их резолверах отдаётся в ответе
127.0.0.1при резолвинге фейсбука или инстаграма, с остальными ресурсами по типу рутрекера всё хорошо, при использовании сторонних серверов отдачи заглушки нет
Принцип работы перехвата DNS эр-телекома и ТСПУ значительно отличаются.
У меня с 21 августа комп кирпич, я думала я с обходками и впн намудрила
Так Ростелеком всю эту движуху и затеял.
Помнится, лет 10-15 назад у Ростелекома уже был свой 8.8.8.8. Трассировка не выходила за их локалку.
Не только он.
Т-Мобайл, который является виртуальным провайдером Т2 тоже очень перегибает палки блокируя многие сети Гугла, из-за чего периодически не работают уведомления, сам Гугл и плеймаркет.
В начале 2026 наблюдал интересное
На моей бывшей работе много лет сервер на Селектеле. В начале года стал работать как-то непонятно как — "то потухнет, то погаснет", сбои классификации не поддаются. Позвонили мне, попросили разобраться.
Перелопатил весь код, все чисто. Сисадмин говорит что у него прекрасно работает, у меня как раз непонятно что: первая страница сайта отрабатывает, а далее начинаются глюки, не поддающиеся классификации.
Устроили с сисадмином мозговой штурм и совершенно случайно выяснилось что сервер прекрасно работает если у посетителя провайдер не-ростелеком. Как только заходишь с ростелекома — всё, приехали.
У Селектела оказались лапки, а воевать с ростелекомом обычному юрлицу не вариант. Пришлось моей бывшей работе переехать на довольно измазанного во всяком хостера. Мы с сисадмином их перевозили — с тех. стороны у этого хостера полный кошмар, зато он весь такой из себя официальный, реклама на госсайтах висит и всё такое.
А зачем этот западный DNS нужен? У нас свой DNS есть. И МВидео есть. Выбирайте.
Почему же западный? Абоненты билайн в Хабаровске ходят на восток - в Японию:

МТС же ходит через Гонконг:

Еще Ростелеком на коротке был с Google DNS, но он закрыл свой Looking Glass.
Яндекс doh, dot никакой не работает кроме провайдерских
У нас давно все мобильные операторы или перехватывают, или блочат все паблик DNS. Переодически без чего-то типа AdGuard даже до белого списка не достучишься.
С одной стороны, запомнить 77.88.8.8 вроде несложно, но вот что Яндекс, который уже давно ри за что не отвечает, однажды решит там отдавать - вопрос.
Ой не, эти вообще странные ребята. Поначалу(когда вот эта вся фигня только началась) хотели для стабильности офисный выход в инет на я. Днс перевести. Через день выяснилось, что они по одному ркн известной причине не отдают mx некоторых почтовых серверов в южной Америке. Почему? Хрен знает, но вернули православные 8.8.8.8 и забыли как страшный сон.
у нас в офисе был любитель порно (не последний человек в конторе).
так я ему через dhcp стал отдавать яндексовский детский dns. он ругался, что интернет не работает, но при проверке - все сайты работали. какие именно не работали, человек не мог сказать )
А его хобби приносило какой-то вред окружающим, раз пришлось принять меры?
<s>А то знаете, кто ещё решает за людей, что им смотреть в интернете?.. </s>
.
А ведь Вы себя ведёте как РКН.
Добивает ещё и то, что комментарий плюсуют и плюсуют.
Чтож Вы, господа плюсующие, РКН-то тогда недолюбливаете? Или это другое?
В своё время мой директор(если что, очень шарил в IT) следил за менеджерами по продажам. Проверял кто куда лазит. И если человек больше 20% времени лазил не по делу, то вызывал его, показывал логи с развёрнутой статистикой, и конкретно намекал, что со следущего месяца премия будет рассчитываться из рассчёта проведённого времени "там где надо" и "где не надо". Менеджеры схватывали информацию с первого же предупреждения.
Понятно, что директор себя вёл как тов.майор. Но это всё же не так обидно, в отличии еслиб он себя вёл как Вы и РКН.
Это было совершенно недавно, когда у нас канал в 256k считался очень хорошим, а мегабайт стоил около 2 рублей.
Финдиректор (по совместительству - жена председателя) очень скрупулёзно подсчитывала, кто и сколько трафика потребил (отчёт в excel выгружался из Traffic Inspector), если кто-то в обед смотрел допустим новости - вычитали с ЗП. И на меня в итоге ложилось всё это, объяснять, почему кто-то пошёл вот на этот сайт, и почему вообще есть возможность ходить туда.
Признаю, может поступал я тогда и некрасиво, но как же мне тогда обрыдло всё это, лавировать между ними. А после "подсовывания" безопасного dns - проблема ушла сама собой.
И это повлияло на эффективность работы примерно никак. Потому что "лазить не по делу" начали с смартфонов вместо компа.
У яндекса еще прикол есть (ну или был в прошлом году) - почта с Proton mail на все(?) домены что используют яндексовскую почту для домена(или во что ее переименовали сейчас) - отбивается прямо при SMTP мол "спам". Насколько помню - техподдержка яндекса говорила что это РКН так сказал сделать.
Ну с другой стороны - вполне себе был повод устроить скандал с получателем мол у вас почта сломана вот логи (при этом зная что те кто на той стороне - не знают таких сложных деталей) и мол если хотите подтверждение - дайте рабочий адрес.
Это следствие довоенной истории со лжеминированиями, когда якобы один из кинутых пользователей биржи BTC-E (активы которой, как считается, отжал бизнесмен Малофеев) массово рассылал письма о бомбах. Сделать с отправителем ничего не могли, не реагировать на письма тоже не могли, поэтому российским почтовым сервисам приказали не принимать почту с популярных анонимных почтовиков (там не только Протон) по принципу "нет письма - нет проблемы".
Шутки шутками, а какие альтернативы? Я вот пробовал яндекс ДНС, рабаоет плохо :(
unbound в режиме рекурсивного ресолвера
на какие DNS? В unbound их и так 6 штук стоит, вопрос на что направлять, если вдруг эти заблочат (а они могут)?
Вы сейчас о чем?
В режиме рекурсивного ресолвера он не форвардит запрос, он сам ищет ответ, проходя все этапы: от корневых серверов до авторитетных самого домена.
А запросы к корневым серверам ещё не перехватывают? Проверил, рекурсивные запросы пока работают.
РКН требовал от владельцев ASN подключиться к НСДИ при наличии своих резольверов.
А запросы к корневым серверам ещё не перехватывают?
Пока перехватывают только определённые DNS сервера
Я бы только аккуратно скачивал список рутовых серверов, проверяя контрольную сумму....
Unbound в этом плане не самый лучший вариант.
Лучше обратить внимание на SmartDNS:
1. Параллельные запросы вместо последовательных
2. В режиме response-mode fastest-ip или first-ping с заблокированным маршрутом на "госзаглушки" будет отдавать "правильный a/aaaa" с "удаленного медленного аплинка" даже если быстрый ближний ответит nxdomain или перенаправит на "заглушку"
DNSCrypt настроил... На московский DNSCrypt-резолвер, в основном. Сейчас думаю, а не фигню ли я сделал...
DNSCrypt при желании блокируется легко. Просто пока это неуловимый Джо, которым не шибко много народа пользуется.
Из интересного: перехватывают, похоже, только UDP, поэтому пока можно использовать TCP.
dnsmasq с разделением по доменам довольно неплохо работает. Часть доменов обслуживает один днс, часть другой. Я понятия не имею что там и как у ни работает но при таком способе настройки днс - перестает ломаться SSH сессия, браузер становится гораздо отзывчивее. И наоборот. Как только весь трафик dns идет в открытом виде - начинаются проблемы буквально со всем.
Ну что, подудосим ТСПУ?while dig youtube.com @8.8.8.8 | grep NXDOMAIN; do :; done
что это даст?
Там вроде пока ещё есть байпасы, если ТСПУ захлёбывается, часть данных через открытый канал начинает течь.
Т.е. чем больше подобных запросов будет - тем сложнее будет работать оборудованию тспу?
вот затем grep и нужен. Как только не увидит nxdomain - цикл завершается.
Это, имхо, атака на свой собственный компьютер, а не на вражеские рогатки. Тут скорее надо запускать сертифицированные средства запутывания от известных товарищей и оставлять их крутиться 24/7/365. Пусть попробуют прожевать.
Статью за атаку на служебное оборудование
Почему на служебное? 8.8.8.8 - это адрес гугла. Так что это операция по выведению вражеского оборудования из строя.
Кажется мы стали забывать как выглядит "атака на служебное оборудование")
*Вспоминает путинвзрываетдома.рф
1 сентября всё ближе
Я слышал, что кто-то эту идею реализовал ещё тогда, когда таким перехватом баловались сами провайдеры. Некто сгенерировал колоссальное количество исходящего трафика к стороннему DNS по 53 порту и в результате завалил DNS-сервер своего провайдера, на который весь этот трафик полетел в результате перехвата.
Чем закончилось, не знаю. Но формально это проблемы провайдера, который чужой трафик, не предназначенный ему, перенаправляет на свой сервис. У меня, скажем, торрент-клиент по 30000 порту отправляет 10 терабайт в месяц. Если провайдеру моча в голову стукнет этот трафик направить на какой-то свой сервис, то он сам себе злобный буратино.
Я сменил DNS с 8.8.8.8. Однако, другие серверы DNS выдают для 4pda.to и еще несколько сервисов уже заблокированные ip-адреса, а 8.8.8.8 выдают рабочие. Пришлось вручную задавать для некоторых адресов DNS 8.8.8.8 на роутере.
(я не программер на столько , на сколько в статье и комментах речь идет) но как понимаю видать еще чуть чуть и вправду на едине с чэбрнтом останемся (
Интересно, какие для этого есть законные основания? Или уже даже изображать законность не модно?
Мы подменили вам dns-запросы, и за это мы получим 100500 миллиардов денег на скрепный интернет и домик для утёнка. А вы нам ничё не сделаете *злобный смех*
Ну что вы, никто ничего не блокирует. Это просто деградация электронов в проводах и фотонов в оптике, из за этого иногда не доходят пакеты
О законности вопроса таких оснований позаботились заблаговременно, приняв пакет яровой и начав борцовую борьбу с якобы экстремизмом/терроризмом.
Разворачивают на московские серваки не только с 8.8.8.8 и 1.1.1.1, но и DoT от циско, квад9 и прочее. Смена публичных DoT серваков спасает, но буквально на пару суток, с каждым разом дедлайн будет меньше - при каждой смене айпишника, дальше видать провайдерских начинают подгонять и они под видом технических работ разворачивают на скрепные серваки запросы.
Я бы рекомендовал всем прекратить мусолить эту тему столь открыто, т.к. решение этой проблемы на поверхности лежит, а в случае нахождения и публикации последней, не хотелось бы искать новые способы подключения к доверенным серверам. Цензоры читают вас и латают свои дыры благодаря вашей коммуникации.
Гейткипинг никогда не был выигрышной стратегией, когда ваше решение с поверхности накроется медным тазом, рабочего решения вам никто не подскажет.
А оно 100% накроется медным тазом, как только я выкачу гайд, а следом они начнут блочить панически вообще всё, что только может отдалённо напоминать этот способ.
Ну я собственно о чем: если вы считаете себя умнее всех, в том числе людей, что пишут запреты и прочие костыли "для народа", то флаг вам в руки. Если сомневаетесь, то лучше присоединяться к сообществу и делиться решениями.
Если решение лежит на поверхности, то там о нем уже наверняка знают
Оно 100% накроется медным тазом, даже если вы не выкатите гайд. Может, на пару часов позже. Перестаньте думать за других.
Security through obscurity никогда не побеждал ни в чём.
Вы ведь сами писали:
решение этой проблемы на поверхности лежит
Значит, оно очевидно и врагу, верно? Или вы их совсем за валенков считаете? Соглашусь, это приятно, но приводит к недооценке преступлений, на которые они способны.
Ситуация давно перешла в режим "поиска дырок в заборе" - работает такое только потому что на все дыры у заборостроителей рук не хватает. Но каждая обозначенная указателем дыра будет срочно заколочена.
Тут надо решать саму проблему существования забора - но это не на уровне рядовых ползователей...
Но каждая обозначенная указателем дыра будет срочно заколочена.
Еще раз повторюсь, что первой версии запрета скоро 10 лет :)
Да не 10 лет ей, там было много обновлений за это время, многие стратегии обхода ркн успешно выводили из строя
Многие выводил, еще больше осталось.
в иране был момент когда у меня ни 1 моя стратегия не работала. так что если сильно захотят то заблочат
Это не когда они тупо рубанули физически трансграничный маршрутизатор на некоторое время?
Всегда можно было сделать так:
Интересно, какие для этого есть законные основания?
Наверняка есть какое-нить постановление правительства. А если и нет, то выпустить - дело на полчаса
Или уже даже изображать законность не модно?
Вас в каком году в криокамеру положили?
"Защита детей", "борьба с терроризмом", "для вашей безопасности", "по просьбам трудящихся" - выбирайте любую (пока есть выбор)
Защита безопасности детей от трудящихся террористов
Защита безопасности депутатских детей от террористически настроенных трудящихся...
Если быть объективным, то террор в данном случае устраивает само государство, поскольку "общественный договор" позволяет.
Тспу стоит после bras/pe, и до nat оператора. Называть сие днатом некорректно, это спуфинг.
В данном случае ТСПУ не занимается подделкой DNS ответа, он просто меняет dst адрес на НСДИ при выходе (только при условии, что в пакете содержится именно DNS запрос). У моего провайдера ТСПУ стоит после BRAS'a (PPPoE сервер фактически), у меня белый адрес, соответственно провайдерского CG-NAT в моём случае нет.
Я пробовал так же из интернета отправить самому себе DNS ответ заблокированного домена подделав src адрес на 8.8.8.8, подмены DNS ответа не произошло.
Уже около года использую собственный DNS (Unbound) поднятый на vps. Еще с момента блокировок DNS стало понятно, что это только начало. Поэтому любые отвалы, происходящие с тех пор узнаю только из новостей.
Некоторые провайдеры уже давно блочат трафик на 53UDP наружу, кроме как на свои DNS сервера... Так что не всегда можно обойти
Надеялся, что не пригодится, но:
Со всей силы хочется чтобы все эти ТСПУ заблокировали сами себя.
Рафик неуиноуат! Это же просто железяка. Надо людей "блокировать"
Ну в США камеры Flock так массово уничтожают силами трудового народа, что компания-подрядчик уже просит мира и переговоров, потому что финансово не вытягивает общественный гнев (осуждаю и не поддерживаю ужасные противоправные действия и тд и тп)
Рафик неуиноуат!
Трафик неуиноуат!
Проверил ещё несколько, аналогично тому, как показывал автор. 8.8.4.4, 1.0.0.1, 208.67.222.222 (OpenDNS) <- эти перехватываются тоже
со вчерашнего дня ростелеком заблокировал напрочь lichess.org, не пингуется без впн
cppreference.com блокируют. Он им чем не угодил?
cppreference.net пока работает, но поисковики всегда выдают .com.
Он им чем не угодил?
хостится на cloudflare же. у меня почти все домены на cf недоступны
Fastly же тоже давно блокируют?
Сегодня перестал работать dl-cdn.alpinelinux.com на нескольких провайдерах, возможно временно, до этого проблем не было.
p.s. Впрочем, сам дурак, пора уже собрать мегаобраз со всеми нужными зависимостями.
Периодически тоже, замечал по тому, что скачивания с kernel.org отваливались
Вдобавок, скачка с github releases работает 50/50, как раз решил обновить свои образы.
Reddit сначала только статика пропала, сейчас в целом не открывается. ~20 часов прошло, проблема пока только на Ростелекоме.
p.s. pypi.org, kernel.org работают и скачивание тоже
Статья 274 УК РФ — Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей.
Скоро выборы.
Сначала свой КВН, теперь свой DNS надо делать.
Такими темпами придется и свой Youtube с Tg поднимать.
Да тут скорее свой интернет надо делать. Тут даже между хостерами РФ пакеты не всегда проходят по банальному 80 порту.
Да уже, с чего начинали, к тому и вернемся, правда раньше это фидонетом называли.
Да, была мысль, что возможно сделать сервис vod с ютуба, ну что-то типа tubearchivist выкачивать, что кругу друзей нужно - тогда нет "лишнего" трафика "за кордон". Но все найденные решения работали... Да не работали. Забил.
На пикабу был чувак, еще на заре замедления ютуба, который сделал подобный сервис. В него кидаешь ссылку на ютуб, он выкачивает видос к себе и можно смотреть. Если совместить это с peertube, то, возможно, получится что-то годное.
Ютуб сильно порезал возможности так качать, в том числе после того, как православный Рутуб в промышленных масштабах пытался сосать видео на свои сервера.
дык и ютубу это невыгодно, просмотры/охваты падают, реклама не показывается. поэтому такие сервисы будут гасить со всех сторон
Скоро сами себе провайдерами станем!
Так им всего-то осталось в своём dns прописать адрес макса вместо тг и адрес рутуба вместо youtube.
Поднял приватный Invidious для некоторых знакомых. В целом работает, но нужна VPS мощнее, чем самая дешёвая.
О, спасибо большое за оперативный разбор! У меня вчера как раз многие сервисы поломались, и я грешил на DNS. Вот оно что. Даже на местечковом провайдере(
Так, а куда делась предыдущая статья про это же самое?
Честно говоря, ничего в этом не понимаю, но на днях перестал работать Ютуб через zapret, на windows 7 (в роутере ставил dns от google)
Логично. Насколько я знаю, byedpi и его форки типа запрета полагаются на системный DNS. Если системный DNS не может найти адрес для имени сайта, то запрет не поможет. Нужен полноценный туннель.
Не столько byedpi, сколько сама система Windows. По дефолту она резолвит домены сама, это не дается на усмотрение приложениям.
<душнила mode>В браузере есть опция "резолвить DNS через прокси". Но так как в случае byedpi прокси целиком на клиентской машине, то он может полагаться только на системный DNS. Как следствие, включение опции не меняет ничего. А вот туннели вроде VLESS могут попросить об этом свой сервер и получить правильный ответ.</душнила mode>
поставь 9.9.9.9 в роутере
Это только A и AAAA записи? Или всякие TXT тоже перенаправляют на национальный сервер?
Проверил резолвинг TXT записей, они не перехватываются (DNAT не происходит)
А попробуйте после отправки UDP с ttl 2 подождать N мс и только тогда отправить обычный с ttl 64. И покрутить N.
Потому что у вас в примере с реальным DNS был таймаут 3 секунды. А с рандомным пакетом - нет. Возможно, там надо подождать. А в случае с DNS интересно, какой максимальный N.
Получил NXDomain при отправке DNS запроса через 3 секунды после рандомного пакета:
~# tcpdump -n -i ppp0 host 8.8.8.8 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
14:45:49.622629 IP (tos 0x0, ttl 2, id 30900, offset 0, flags [none], proto UDP (17), length 922)
X.X.X.X.51228 > 8.8.8.8.53: 42463 updateA YXRRSet-$ [3055q], [|domain]
14:45:52.719270 IP (tos 0x0, ttl 64, id 3061, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.51228 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
14:45:52.730385 IP (tos 0x0, ttl 60, id 47761, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.51228: 35076 NXDomain* 0/0/1 (42)Интервала как такового нет, даже через 1 секунду такой же результат
С реальным DNS запросом при TTL 2 такая же ситуация, подождал целую минуту, а в ответ пришли настоящие IP-адреса:
~# tcpdump -n -i ppp0 host 8.8.8.8 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
14:51:29.036601 IP (tos 0x0, ttl 2, id 63092, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.40231 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
14:52:29.133634 IP (tos 0x0, ttl 64, id 37612, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.40231 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54)
14:52:29.300782 IP (tos 0x0, ttl 109, id 5868, offset 0, flags [none], proto UDP (17), length 102)
8.8.8.8.53 > X.X.X.X.40231: 35076 2/0/1 rutracker.org. A 104.21.32.39, rutracker.org. A 172.67.182.196 (74)Хмм... Подозрительно большой интервал. Советую продолжать увеличивать таймаут, одновременно меняя домены, чтобы исключить возможность кеширования. Какой-нибудь кеш может подпортить эксперимент.
И ещё придумал - как насчёт чередования A и AAAA запросов? Ну вдруг A с ttl 2 разблокирует AAAA на тот же домен и наоборот.
Ну и третье - попробуйте в один из запросов (ttl2 или ttl64) докинуть несущественных опций, чтобы побайтно пакеты стали отличаться.
Что-то разыгралось у меня воображение... Можно ещё и просто немного подкрутить DNS и посмотреть, будет ли DNAT (по icmp ответу). Например, рандомных байтов в конец пакета дописать. Один и тот же ID запроса подставлять. QCLASS поменять.
~# tcpdump -n -i ppp0 host 8.8.8.8 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
16:31:22.488412 IP (tos 0x0, ttl 2, id 42116, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.30233 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:31:23.586324 IP (tos 0x0, ttl 64, id 30743, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.30233 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:31:23.630545 IP (tos 0x0, ttl 108, id 39417, offset 0, flags [none], proto UDP (17), length 102)
8.8.8.8.53 > X.X.X.X.30233: 14557 2/0/1 rutracker.org. A 104.21.32.39, rutracker.org. A 172.67.182.196 (74)Вы можете и самостоятельно экспериментировать, если у вас нет перехвата DNS запросов, то вы можете найти хостинг с подобным явлением из этого списка - https://globalping.io/?measurement=2TnuCfL63NIYzgR1Y001211g2&display=table
Могу лишь предположить, что ТСПУ перестаёт делать DNAT после получения ICMP TTL Exceeded:
~# tcpdump -n -i ppp0 host 8.8.8.8 or icmp -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
16:44:44.926651 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:44.934296 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 195.208.5.1.53: [|domain]
16:44:45.928461 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:45.933575 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:46.929807 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:46.932393 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:47.931497 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:47.935700 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:48.933436 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:48.934812 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:49.935547 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:49.937371 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:50.937174 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:50.938080 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]
16:44:51.938533 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47)
16:44:51.939320 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56)
A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36
IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75)
X.X.X.X.25212 > 8.8.8.8.53: [|domain]Но при резолвинге по несколько раз с TTL 64 в рамках одного соединения отдаёт NXDomain стабильно (за исключением случая кратковременно большого pps/rps, как это описано в статье):
~# tcpdump -n -i ppp0 host 8.8.8.8 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
16:42:40.789678 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:40.800943 IP (tos 0x0, ttl 60, id 45883, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:41.790464 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:41.801422 IP (tos 0x0, ttl 60, id 45984, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:42.792903 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:42.803986 IP (tos 0x0, ttl 60, id 46022, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:43.794361 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:43.812382 IP (tos 0x0, ttl 60, id 37938, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:44.796254 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:44.807262 IP (tos 0x0, ttl 60, id 46353, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:45.797252 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:45.814865 IP (tos 0x0, ttl 60, id 38123, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:46.799729 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:46.818311 IP (tos 0x0, ttl 60, id 38189, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)
16:42:47.801971 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82)
X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54)
16:42:47.819693 IP (tos 0x0, ttl 60, id 38337, offset 0, flags [none], proto UDP (17), length 70)
8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)По пути у меня нет узлов, которые бы не отдавали ICMP TTL Exceeded.
ТСПУ + сертификат минцифры = потенциальная подмена сайтов с "нужным содержимым"
Если учитывать текущую техническую реализацию (а реализовано оно усечённым, легковесным и одновременно странным DNAT), то 443 порт должен уходить на какой-то сторонний прокси сервер в интернете, этот самый прокси должен по SNI отрезолвить домен, в результате чего исходный IP-адрес клиента просто потеряется (если его не добавлять отдельным заголовком конечно), это сломает веб-ресурсы, которые доступны только по белым спискам src адресов.
Если конечно, ТСПУ не научится в полноценный MITM в рамках TLS без потерь IP-адресов, или если провайдер не разместит прокси сервера у себя.
Я не спец, но разве через подмену 53/udp они не могут отдавать какой нужно IP? Контролируя CA, в теории могут подписать любой домен (могу ошибаться). Возможно, Chrome как-нибудь дополнительно проверяет гугл адреса.
Через DNS тоже можно отдавать A/AAAA записи самого прокси сервера, но в случае использования DoH провести MITM не получится.
Я имею в виду теоретический случай, когда DoH/DoT больше нет, остался только 53/udp с правильными записями.
Дома doh до единичек пока работает (правда у CF сервер в мск), а вот на работе столкнулся и с тем, что простые восьмерки не отвечают. Пришлось в срочном порядке инфру нескольких клиентов переключать на другие днс. Происходящее осуждаю.
Заблокированные домены для проверки: rutor.info, flibusta.is, clubtone.do.am, rezka.ag, shikimori.one
Незаблокированные домены для проверки: vk.ru, gosuslugi.ru
ВНИМАНИЕ: Это независимая проверка и она не использует ваши настроенные DNS!
Проверено серверов: 65/65
Итог
DNS доступность 28/33 DoH 32/32 UDP
Подмена резолвера Cloudflare, Google
Подмена ответов у 10/32 UDPfullscreen

в начале недели два дня adguard dns тоже плохо работали.
А в чём проблема сделать нормальный захардкоженный утверждённый атлас белых IP адресов и распространять через киоск "Союзпечать", создать Единый классификатор адресов, ГОСТ. Например резольвить aaa.bbb.ccc.ddd 001. - айпишники пожарных организаций, 002 - полиция, 003 - скорая, 004 - сайт Газпром итд
В ответ следует вставить соответствующую дежурную картинку красного цвета.
Имеют ли к этому какое-то отношение разговоры о том, что некие нехорошие люди ходят, сканируют роутеры, вставляют подменные DNS-сервера и получают всё, что им нужно напрямую?
Чегой-то со вчерашнего вечера (с 28.08) вааще всё отваливаться стало в этих ваших Интернатах...
До этого -"много чего", а вот со вчерашнего - вааще почти всё... :(((
Есть шанс что Gemini перестанет работать через DNS?


На ТСПУ начали перехватывать открытые DNS запросы к 1.1.1.1, 8.8.8.8