Comments 33
Может я не въезжаю, сорри. Но не понимаю логику работы. Service worker подключен к заблокированному сайту example.com. Пользователь открыл у себя новое окно браузера, набрал example.com, ТСПУ перехватило запрос в DNS и HTTP-реквест и заблокировало их, а в клиента плюнула HTTP 302 на картинку блокировки. Откуда у клиента в его браузере возьмется service worker, чтобы определить, что блокировка произошла, и переадресовать клиента на новый сайт?
Или все клиенты сначала должны зайти на сайт до блокировки и закэшировать у себя воркер?
Да, клиенты должны посетить хотя бы раз сайт до блокировки.
Все-таки можно поподробнее?
Вот я посетил сайт, закрыл браузер со всеми вкладками, открыл заново, набрал руками адрес...
Вместо, чтобы полезть на запрошенный сайт с заглушкой, браузер запустит скрипт из кеша?
Посетили сайт
В кэш подгружается воркер, который при каждом последующем посещении будет проверять есть ли на странице текст "Х" и если его нет - перенаправлять на другой домен, которого нет в РКН
Если при следующем посещении сайта ваш провайдер будет пытаться вас перенаправить или показать заглушку о том, что сайт заблокирован - сработает сценарий из предыдущего пункта
"на другой домен, которого нет в РКН" - на какой такой другой домен?
Что вообще в данном контексте подразумевается под словом "домен"?
Если вообще не использовать в браузере доменные имена, а набирать IP-адрес цифрами, то... ?
...например, когда я набираю адрес своего сайта, то там открывается сайт
...а когда набираю адрес сайта одной организации, не так давно признанной самизнаетечем, то там выскакивает заглушка, видимо, хостера - "direct IP access not allowed"
Допустим у вас есть site1.com, который пока доступен в РФ.
Рассмотрим несколько вариантов блокировки и пути их решения с помощью редиректа воркером:
РКН может заблокировать отдельную страницу на сайте https://site1.com/index.html (редиректим посетителя на https://site1.com/index_not_blocked.html)
Домен/поддомен без блокировки по маске site1.com или sub.site1.com (редиректим на любое другое "зеркало", подойдёт и поддомен notblocked.site1.com)
Домен и все поддомены заблокированы *.site1.com (редиректим на site2.com, поддомены site1.com не подойдут)
Я вот чего не понимаю. Блокировка, если я правильно понимаю, происходит на этапе запроса к DNS. Если скрипт, анализируя возвращаемый ответ, обнаруживает блокировку, то он подменяет доменное имя в запросе, так? Однако заблокированным может оказаться любой из доменов перечисленной в Вашем ответе структуры, и даже все домены - ведь они статически прописываются как переменные в скрипте при его первоначальной загрузке с незаблокированного сайта.
Блокировка, если я правильно понимаю, происходит на этапе запроса к DNS.
Вы неправильно понимаете.
Подмена DNS на сервере DNS провайдера — это только один из многих, причём устаревший, метод блокировки, который обходится тривиально, использованием публичного или своего собственного сервера DNS. (Да, я знаю про DNS spoofing, это выявляется стандартным образом, браузеры уже умеют с ним бороться.)
Все без исключения крупные операторы интернета используют DPI для выявления запросов к запрещённым цензурой ресурсам.
А зачем проверять наличие текста? Сервис воркеры ж работают только на https, так что в случае перенаправления/заглушки – сайт будет просто недоступен.
Осталось от отладки на localhost или готовитесь к MiTM-сертификату от РКН?
Воркер «подселяется» в кэш только с HTTPS, но содержание может проверять с любой, подконтрольно ему, страницы.
Использовал этот метод для своей сети сайтов со спорным содержанием. Фича спасла мне много нервов и времени, поэтому решил поделиться. :)
Ему разве подконтрольны не только страницы с того же хоста и протокола? Хотите сказать, что если подселился с https://example.com, то и для http://example.com будет работать?
Извиняюсь, да, вы правы. При запросе HTTP воркер не работает. Только вот провайдеру переадресацию в случае блокировки нужно будет делать именно с HTTPS, а значит переадресация произойдёт.
А что если сделать расширение для браузера? Вести базу с заблокированными + альтернативными доменами:
перехватываем запрос
ищем альтернативный адрес
перенаправляем
профит
У меня эта идея давно в голове вертелась. У нее есть минус, это будет работать только для тех, кто уже посещал сайт до блокировки.
Думаю, что при блокировке хоть раз да проверят, сработала ли она. А тут прямо на тестовом оборудовании сразу редирект и произойдет. +1 адрес в список и смысл этого воркера теряется
Это уже нюансы, с которыми нужно работать отдельно.
Как показывает практика - боты РКН при посещении сайта не подгружают ничего, кроме исходного кода страницы. Соответственно о посещениях таких сайтов с полноценным WebDriver'ом, который ещё и с сервис-воркерами полноценно работает не может идти и речи.
web он такой web...
Редирект провайдера происходит с заблокированного сайта. Поэтому прежде чем провайдер отправит клиента на свою страницу - на вашей заблокированной будет 307 редирект с пустым ответом. А это значит, что воркер и в этом случае не сможет найти искомый текст и отправит клиента не на страницу с ошибкой и не на страницу с заглушкой, а на тот домен, который будет указан в settings.
Таким образом вместо заглушки провайдера о том, что сайт заблокирован пользователь переходит на незаблокированный домен.Зачастую вместо заглушки пользователь получает тупо PR CONNECT RESET ERROR.
Обход блокировки РКН с помощью магии Service Worker'ов