Как блокируют доступ к сайтам? telnet vs. браузер

#http #dns #маршрутизация

При попытке открыть Кинозал.тв в любом браузере перебрасывает на заглушку РосКомНадзора.

Москва, провайдер ОнЛайм, OS X 10.11.2 El Capitan. DNS у меня стоят гугловские. Запрос
браузера идёт по правильному адресу, к CloudFlare – на этот же ip ресолвится имя сайта
и с зарубежных vps'ов. В ответ в браузеры приходит просто редирект на заглушку:



Если же проделать соединение не браузером, а telnet на порт 80, то всё работает как
положено – возвращается html страницы:



Это так же работает, если в telnet отправить все те же HTTP заголовки, что и шлёт
браузер:

GET / HTTP/1.1
Host: kinozal.tv
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101
Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: uid=1234567; pass=XXXXXXXX; __cfduid=abcdefe0171f2defb37070b1428009916; stylet=0
Connection: keep-alive


Хотя заголовок про gzip лучше убрать, а то в терминал валится нечитаемый бинарный
мусор компрессированного контента.

Пока единственная разница, которую нашёл – во времени: в telnet от момента соединения
до отправки заголовков проходит пара секунд, пока я вручную сделаю paste. В браузере
это происходит за миллисекунды. Надо попробовать с curl..

Вопросы: как и где происходит подмена ответа заблокированных серверов; Почему запросы
из telnet обходят этот механизм?

Нашёлся ответ habrahabr.ru/post/249433 в конце ответа после UPD. Вкратце:


  Стоило вам присмотреться к трафику, который приходит на интерфейс от Ростелекома.
Вероятно, DPI подключен параллельно, а не последовательно, и туда приходит только клиентский
трафик. Т.к. DPI стоит явно ближе, чем вебсайт, пакет с Location от DPI приходит быстрее,
чем реальный первый пакет от сайта, а пакет от сайта уже отбрасывается ядром ОС как
ретрансмиссия, поэтому, если вы используете Linux, достаточно одной строки в iptables,
чтобы обойти блокировку:

iptables -A INPUT -p tcp --sport 80 -m string --algo bm --string "http://95.167.13.50/?st"
-j DROP


    

Ответы

Ответ 1

запустил такую команду на двух компьютерах, один из которых находится в рф (провайдер
highlink), другой — в фрг:

$ echo -ne 'GET / HTTP/1.1\r\nHost: kinozal.tv\r\n\r\n' | nc -i 1 kinozal.tv 80


сравнение вывода этих команд (оставлены лишь существенные фрагменты):

$ diff -ruaN kinozal.frg kinozal.rf
--- kinozal.frg 2016-01-22 11:51:53.000000000 +0000
+++ kinozal.rf  2016-01-22 11:51:01.000000000 +0000
@@ -1,13 +1,21 @@
-HTTP/1.1 200 OK
-Date: Fri, 22 Jan 2016 11:51:18 GMT
-Content-Type: text/html; charset=windows-1251
-Transfer-Encoding: chunked
-Connection: keep-alive
-Set-Cookie: __cfduid=df6ffc8c31e9a6f6f2e233c7f44bf81761453463478; expires=Sat, 21-Jan-17
11:51:18 GMT; pa
th=/; domain=.kinozal.tv; HttpOnly
-Server: cloudflare-nginx
-CF-RAY: 268b0bd3e28e2690-FRA
+HTTP/1.1 302 Moved Temporarily
+Server: nginx/1.0.15
+Content-Type: text/html
+Content-Length: 173
+Connection: close
+Location: http://blocking.hl.ru:88

-505
+
+
+
+
302 Found
+
nginx/1.0.15
+
+
+
+------------0b0ac4bb16a6-ARN
+
+f77
 
 
 


дальше в обоих файлах идёт содержимое страницы, отдаваемой сайтом kinozal.tv.



как видно из вывода программы diff:


изменены заголовки ответа сервера, благодаря чему браузер должен повторить запрос,
но уже по адресу http://blocking.hl.ru:88 (доменное имя hl.ru принадлежит тому самому
провайдеру highlink);
после заголовка вставлен ещё один блок html с текстом-заглушкой.




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