Как и все, я пользуюсь одним из простых способов обхода блокировок, коих сейчас море. Все сайты открываются без проблем и тормозов. Но с недавних пор (2 недели назад) у меня встал вопрос: а какие сайты на самом деле заблокированы из тех, что открываются, а какие нет? Каждый сайт проверять вручную на официальном сайте РКН — не вариант, хоть это и самый надёжный способ. Естественно, я пошёл гуглить подходящие инструменты, но к великому удивлению ничего не нашёл.
Так родилась идея сделать расширение (опенсорсное), которое будет проверять каждый сайт на соответствие записям в базе РКН. Сначала оно было простое, проверяло только домен. Сейчас оно даже показывает, был ли сайт заблокирован неправомерно (попал под раздачу). 
Правда, если в браузере настроен прокси, то расширение работает в пол силы, т.к. испытывает проблемы с определением текущего ip сайта. Кстати, для определения ip понадобились права webRequest (доступ к данным). Также ip не определяется из браузера Tor (к сожалению).Другая техническая трудность — это определение текущего ip, когда сайт недоступен (предположительно заблокирован, а обход блокировок не настроен). В этом случае браузер не предоставляет информацию. А нам нужен именно тот ip, по которому браузер пытается установить соединение — и его определить невозможно.
В качестве полумеры для решения подобных проблем расширение осуществляет DNS запрос и определяет все ip сайта, а также их статус нахождения в базе РКН. Для получения DNS записей приходится использовать внешний сервис через http(https), потому что сам браузер не позволяет резолвить адреса. Но это и хорошо, т.к. провайдеры не блокируют и не перенаправляют подобные запросы.
Если у провайдера блокировка на уровне DNS, то расширение будет получать ложный текущий ip сайта и не подозревать об этом. И наоборот, если вы пропишите нужные ip в файл hosts (или даже у вас свой DNS-сервер), то во всплывающем отчёте будут именно они. Но обычно сайт всё же блокируется по домену, а уж эта информация легко доступна из URL.
Зато функция проверки доступности сайта работает независимо от DNS и блокировок (пока соответствующий сервис работает без сюрпризов). Естественно, проверку доступности и http-dns можно отключить в настройках.И, конечно же, отдельный квест был поиск наиболее адекватной базы РКН. Дело в том, что сам РКН не держит базу в открытом доступе. Вместо этого он предлагает провайдерам использовать цифровую подпись для доступа к базе. У меня лишней ЭЦП под рукой не оказалось. Между тем, РКН рекомендует провайдерам обновлять базу раз в час. То есть ковровая блокировка может задеть ключевые (или ваши) ресурсы всего на пару часов, а потом исчезнуть, как ни в чём не бывало. Наиболее приемлемым оказался часто обновляемый файл на github. Спасибо добрым людям!
Ситуации, когда показывается заглушка провайдера, расширение распознаёт. Оно запоминает информацию о странице, с которой был редирект на заглушку, и показывает информацию о сайте, а не о заглушке. Сейчас поддерживаются: Ростелеком, МТС, Билайн, Йота, ТТК, Дом.ру. Если у вас особая заглушка у провайдера, её можно указать в настройках, и она будет распознаваться (не будет рассматриваться, как сайт).
Будущее RKN Alert вызывает смутные сомнения, потому что постоянное массовое скачивание тяжелых файлов может не понравится серверам, на которых они расположены. Это напоминает DDoS атаку. Конечно, рано об этом говорить, но всё же.
Всем добра!
P.S. Не смотрите код! Он ужасен! Всё же я не профессионал.
Krasnodar_etc
Ура! Наконец я смогу различать заблокированные и просто не работающие сайты. Надоело время тратить.
AntonyMcGreen
Решение
dollar Автор
Спасибо за идею.
Добавил это «решение», чтобы работало в 1 клик.
А какой не доступен:
А вот забавный момент: сам себя сервис отказывается проверять.
Отшучивается: If you can see this page and still think we're down, it's just you.
Расширение шуток не понимает.
Eagle_NN
Хорошая тема. Понять сайт идет штатным образом, или через черный ход. Хотя практической применимости этих сведений пока не придумал.
Popadanec
Я вовсе не устанавливаю VPN/Proxy на основной браузер. Чтобы в один день не оказалось что весь интернет доступен только через него.
Заметил что помимо сайтов с плашкой РКН или Ростелеком что сайт заблокирован, появились такие: «Не удается получить доступ к сайту Соединение сброшено.» При этом целевая аудитория сайта Россия, через VPN прекрасно работает(но в реестре нет). Не знаю с чем связано, но похоже не на прямую блокировку, а какого то важного сервиса, на который сайт опирается.
И таких все больше. Опять ковровые бомбардировки задели что то важное для инфраструктуры.
P.S. Сайт на https. Если последнюю букву удалить, тогда вылезает плашка РКП о блокировке.
Eagle_NN
Все верно. Смысла ставить VPN на браузер нет. (а если 2 браузера… а если мобильные клиенты… нудно) Надо организовывать более правильное решение — на уровне всей подсети. Заодно можно решить проблему DPI и перехвата DNS запросов.
Всем мира.
psycho-coder
Это те, которые попали под раздачу при блокировки подсети. Мой сервер на DO в такой-же ситуации.
DaemonGloom
Всё очень просто. Нельзя отобразить заглушку для https соединения без подмены сертификатов. У провайдеров есть два варианта — оборвать соединение (что вы и видите) или подменить сертификат и показать заглушку (привет красному предупреждению от браузера и пуганию людей).
Popadanec
Вопрос в том, почему сайт уже месяц в блокировке и даже более того убран из выдачи гугла. Имя его при этом ни в каком варианте на сайте РКН не ищется.
AEP
Это мелкие провайдеры делают, чтобы их не обвиняли в MITM-атаках с поддельными сертификатами (т.е. не пилили нервы техподдержке из-за предупреждений браузера). «Сайт не работает» — это одно, а «небезопасно» — это намного хуже с точки зрения пользователя.
Popadanec
Вы считаете Ростелеком мелкой компанией?
AEP
Это такой бегемот, который съел много мелких компаний и использует бывшее их оборудование. OK, «Это мелкие провайдеры (и не только они) делают, чтобы ...»
navion
Есть же плагин от Антизапрета, который показывает в блоке сайт или нет, а также позволяет узнать подробности через меню.
dollar Автор
Я пользуюсь GoodbyeDPI, работает на Ростелекоме и лучше, чем VPN
Pochemuk
Если пров
а) перехватывает DNS-запросы к чужим DNS-серверам и перенаправляет на свои;
б) резольвит IP заблоченных сайтов на 127.0.0.1,
то как будет работать эта система?
dollar Автор
Система будет показывать тот ip, который подсовывает dns или файл hosts. Это тот ip, по которому браузер обращается к сайту.
Чтобы резолвить каждый сайт, нужно, чтобы кто-то у себя поднял http-dns. Потому что тот сервис, которым пользуется расширение, имеет лимиты (200 запросов в час, потом бан). Поэтому резолвит только если ip заблокирован или если сайт недоступен.
В любом случае расширение не меняет ip. И если у вас провайдер шалит с dns, то поможет DNSCrypt. В этом случае, кстати, ip станет правильным, и расширение будет его показывать.
goiliago
А гугловый dns использовать не пробовали? Упоминаний каких-либо ограничений не, но и не проверял есть ли они на самом деле: https://developers.google.com/speed/public-dns/docs/dns-over-https
Pochemuk
Пробовал, разумеется. Тоже резольвит в 127.0.0.1, будто на Гугле их тоже блочат по DNS :D
Я ж говорил — пров перехватывает запросы к чужим DNS. Будь то Гугл или кто еще. Тупо по UDP#53.
goiliago
Так это через https, провайдер не может изменить запрос. Вот, например, linkedin.com: https://dns.google.com/resolve?name=linkedin.com
Pochemuk
Мы об одном и том же говорим?
Я говорю, что провайдер искажает информацию по DNS-протоколу.
Для этого он перехватывает весь трафик по UDP#53 к любому серверу и направляет на свои DNS-сервера. А те для заблоченных доменов выдают 127.0.0.1.
Весьма просто и эффективно для блокировки сайтов, использующих HTTPS. Конечно, пока что и это обходится, но все равно неприятно.
goiliago
Я предложил вместо одного сервиса использовать другой (Google DNS over https):
dollar Автор
Да, спасибо, добавлю в расширение.
Упустил этот сервис из виду.
Chupaka
У Cloudflare есть такой сервис: https://developers.cloudflare.com/1.1.1.1/dns-over-https/request-structure/
dollar Автор
Пытался. С гугл всё сразу завелось. А cloudflare выдаёт ошибку 400 (DNS query not specified or too small). Вроде всё по инструкции делаю:
cloudflare-dns.com/dns-query?name=yandex.ru&type=AAAA
x86corez
Видимо нужен заголовок в запросе:
Accept: application/dns-jsonEagle_NN
Надо добавить заглушки на всех провайдеров и будет счастье.
Логика: если адрес сайта поменялся на заглушку (или ip резолвится в заглушку) — значит в бане сайт.
А так это не система обхода блокировок. Это информация для тех у кого все хорошо и без нее :)
dollar Автор
Давайте начнём с вашей заглушки. Жду URL.
Уже добавлены Ростелеком, Beeline и МТС.
dollar Автор
Со следующей версии будет возможность указать свою заглушку в настройках.
AngReload
Для огнелиса будет?
dollar Автор
Конечно. Уже есть.
eps
Полезно, но не для моего браузера
jehy
Хорошая штука. Спасибо. Можете таки выложить ссылку на репозиторий с кодом? Не проблема, что кривой — вместе допилим.
UPD. Код посмотрел, код в целом понятный. Красота, модульность, тесты и прочее — дело наживное. Выкладывайте — буду пулл реки делать.
dollar Автор
Разобрался. Оказывается, веб-интерфейс на github совсем не сложный. :)
github.com/MarisKori/rknalert
dom1n1k
К сожалению, расширение бесполезно.
Я практически ежедневно сталкиваюсь с заблокированными сайтами, а то и по 2-3 раза на день. Но лишь малая часть из них (буквально единицы) дейстивтельно оказываются в реестре. Всем остальным, а это процентов 99 на глаз, просто не повезло отказаться в каком-то «плохом» диапазоне IP-адресов.
dollar Автор
Значит, у вас очень жёсткий провайдер, сочувствую.
В реестре есть, можно сказать, два типа ip:
1) Отдельные — когда блокировка идёт конкретно по ip или подсети. Расширение помечает такие ip красным цветом.
2) С привязкой к домену. То есть реально блокировка идёт по домену или URL, а ip в базе указывается в качестве дополнительной информации (для провайдеров, которые не умеют блокировать по домену). Расширение помечает такие ip оранжевым.
Расширение не в курсе, какой у вас провайдер, но может пробить ip по базе данных и определить, к какому типу относится этот ip. Полезность чисто информативная.
Pochemuk
Уточнение:
IP указывается не для тех, кто не умеет блокировать по URL, а ровно наоборот, для реализации DPI-IP-фильтрации.
Т.е. сначала засекается обращение к подозрительному IP и трафик направляется маршрутизатором через более скрупулезный фильтр, который проверяет используемый протокол, URL (если этот протокол HTTP) и т.д.
Таким образом основной канал разгружается от необходимости проверять весь трафик. А массовая блокировка по IP не будет применяться. Но только если это не HTTPS-протокол, а простой HTTP.
Но это в идеале.
На практике, конечно, и по площадям получается…
x86corez
Сайт операционной системы ReactOS уже давно страдает от блокировки всего диапазона 178.63.0.0/16 (это хостинг Hetzner), но плагин почему-то не смог определить блокировку.
dollar Автор
Эта проблема уже исправлена (версия 0.18). В магазине Chrome, FireFox и на github уже доступно обновление.
x86corez
Ого, быстрая реакция, спасибо! :)