Pull to refresh

Comments 158

Что-то мне подсказывает, что все закончится некоторым образом переделанным сквидом.
Не за такие деньги, тем более, бюджетные.
Ростелек же коммерческая компания, деньги сам зарабатывает, разве нет? Вот и пусть тратят свои заработанные, как того сами хотят.
Коммерческая то коммерческая, но почти 50% акций принадлежит государству, а это значит, что состояние бюджета данной организации имеет значение и для бюджета страны.
Ну я имею ввиду если брать нормальное государство))
Ростелеком — это государственный пылесос. Последние годы компания целенаправленно занималась консолидацией телекоммуникационных активов, делая покупки без оглядки на прибыльность, это не цель.

Чистый долг «Ростелекома» по состоянию на 31 декабря 2013г. увеличился на 6,6% и составил 217,3 млрд руб., говорится в сообщении компании.
Меня, впрочем, как их абонента (OnLime) радует, что меньше сайтов будет попадать под блокировку.
А меня совсем не радует тот факт, что блокировка вообще есть.
Они никого не радуют. Вернее радуют, но лишь небольшое количество пользователей.
И да, они есть. И убрать их полностью на данный момент не представляется возможным.
Так что относитесь к их наличию философски.

Более того, я подозреваю, что для вас (как и подавляющего большинства здесь присутствующих), обход блокировок представляется задачей тривиальной, осложненной в основном собственной ленью.
Скорее попытки навязать рабство — приведут к свободе. Запретный плод сладок. А vpn никто не отменял.
Вот тут CISCO отвечает про регулирование криптографии научнопопулярным языком. Из этого документа лично я сделал вывод, что любой предоставляющий услуги VPN формально должен получить лицензию, т.к. «предоставление услуг в области шифрования информации» является деятельность, лицензируемой у «Центра по лицензированию, сертификации и защите государственной тайны ФСБ России».
Нужно просто сделать как в Англии: по дефолту блокируем всё запрещенное, а потом клиенты приходят и пишут заявление на разблокировку взрослого интернета.

И все довольны.
VPN и всякие прокси в этом Вашем Лондоне отлично работают.

Детский сад, одним словом.
У этого факта есть и обратная сторона медали. Блокировки будут менее заметны, а значит будут меньше раздражать людей. А значит общественное мнение будет более лояльно к этим блокировкам.

Наше общество еще не достаточно гражданское, чтоб, например, студенты выходили отстаивать права пенсионеров. Поэтому нужно прямое непосредственное раздражение. Ничья хата не должна быть с краю.
То есть больно, но со смазкой лучше!
UFO just landed and posted this here
Разве это большие деньги для такого количества трафика и ответственности, меня наоборот удивило, что такая маленькая сумма — как-то не по российски.
Что-то мне подсказывает, что все закончится некоторым образом переделанным сквидом.

… который еще будет рекламу вставлять свою, а то с DPI они ж монетизации не видят
Работал в NSUNet'е, такой сквид реализовали менее, чем за полгода вялой работы(приоритет «когда нечем заняться») одного сисадмина.
Эх, знал бы он, что может за это получить $1.000.000…
Боюсь, что лям получили те, кто должен был получить.
Или есть сведения, что у нас открытые и прозрачные конкурсы?
Рискую быть не понятым :) Но всё же: трафик через сервера с данным прозрачным прокси будет значительным, а значит вероятнее всего это будет прозрачный прокси размазанный по нескольким серверам, а то и вовсе по кластеру, по крайней мере я бы так делал. Так что это не просто сквид, а отказоустойчивая конструкция с динамически распределяемой нагрузкой, которая будет стоять на магистрали(!), и трафик через эту систему фильтрации будет проходить громадный :)
Рискну выступить Капитаном, но у подавляющего большинства провайдеров и так стоят кеширующие прокси, ибо сильная экономия трафика, ведь большинство клиентов смотрят одних и тех же котиков. У онлайма (уже Ростелеком), например, Varnish раз в пару месяцев палится разными страшными ошибками.
Это понятно, видимо я не совсем точно всё расписал, ведь кэширующие прокси обычно стоят не на границе России, а несколько поближе к абонентам, и распределены по территории, и наверняка находятся в точках обмена трафиком. В тоже время данные устройства должны обрабатывать трафик исключительно на входе в РФ, ибо на территории РФ ничего блокировать не надо поскольку проще и быстрее на хостера надавить, чем адрес в реестр вносить.

p.s: прошу прощения, но отвечать больше не буду :) ибо комменты раз в час это не для меня. Не жалуюсь, просто прошу — не обращайте внимания если отвечу через неделю :)
Раньше стояли, а потом, когда трафик стал намного дешевле отказались. По крайней мере в Кировской области (Ростелеком, бывший Волгателеком). Были заметны соответствующие глюки при серфинге интернета, например при заходе на сайт по определению ip выводило ip прокси сервера.
например при заходе на сайт по определению ip выводило ip прокси сервера.

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

У онлайма оно нормально работает, подобных проблем не бывает. Ну опять же когда не падает, но чинят быстро.
угу. А следующим шагом будет фильтрация по контенту, на базе Dansguardian.
Они там что squid разрабатывают за такие деньги? А как будет отделяться трафик на этапе 1? С помощью чего они будет определять что трафик должен идти на proxy? DPI =) или пять таки IP адреса подозрительных ресурсов…
Вот я смотрю на все это и чувствую где-то подвох…
скорее всего ipшники. а уже прокси будет решать отдаьт пользователю контент или нет.
Таки что они сделают с HTTPS? Больной вопрос же…
Они делают SSL-MITM, если у вас в браузере установлен корневой сертификат ростелека — вы ничего не заметите даже.
Ключевое слово если. Зобанят этот сертификат моментально, прогнуться может только майкрософт и все такое, а вот гугл, мозила — в блэклист и все.
COMODO прогнулась.
Заглушки на https РТ показывает со своим сертификатом, но оригинальным доменом, а следовательно браузер ругается на подмену сертификата. Техподдержка COMODO на тикеты не отвечает.
Ну так все правильно. Сертификат выдан для другого домена, поэтому браузер и ругается. COMODO тут не виноват. Вот если бы заглушки показывали под сертификатом для оригинального домена…
РТ отдает левый сертификат в ответ на запрос другого домена.

COMODO не хочет даже давать ответ на вопрос, допустимо ли подменять реальный сертификат сайта на заведомо не валидный с подменой контента. Технически, ситуация ничем от MitM не отличается, так как если это по их мнению допустимо, то следующим логичным шагом может быть такая подмена для какого-нибудь банка, и, да здравствует потенциальный фишинг.
А если не установлен?
Цифра1 уже на этом засветилась.
а что с https? будет проксироваться также как и http.
да. будет идти подмена сертификатов, что на мой взгляд крайне возмутительно, но это работает.
Кстати, вопрос. Сертификаты МТС, Ростелекома и прочие уже загружены по умолчанию в браузеры как доверенные? Может выкинуть их, чтобы не было вариантов простых для MitM?
У каждого сертификата есть неприметное поле Basic Constraints, которое определяет, принадлежит ли он центру сертификации или нет. Что удивительно, далеко не все центры ранее выставляли ему значение CA=FALSE[S1]. Более того, большинство браузеров даже не утруждались проверкой значения этого поля. Получается, имея на руках действительный сертификат, можно было создать и подписать сертификат для любого другого домена – и браузеры бы даже не заподозрили неладное!
Для этого есть даже софтина sslsniff
и другой подход без подмены сертификата. Смысл в том что насильно переводи клиента на http, а сами (прокси сервер) общается с сайтом по https

Программка тоже есть: sslstrip
есть некоторые подводные камни:
куки
сжатие
сессии
но это тоже решаемо. В кукисах убираем security bit в поле в Set-Cookie. От сжатия контента отказываемся, удалив в хедерах HTML параметр content encodings. Ну и с сессиями танцуем с бубном.
Еще подводный камень: есть список ресурсов, с которыми распространенные браузеры не хотят общаться не по SSL. Впрочем, ничто не мешает сделать белый список. Главное — вовремя актуализировать его.
и тут тоже есть вариант обхода. Отправляем клиента по другому адресу. Например вместо https_gmail.com/ на http_gmail.opsos.ru/ а запросы от прокси уже отправляем на gmail.com/ — это заметно, но для целей блокировок «согласно закону» можно использовать.
Это действительно будет весьма заметно в браузере, настолько заметно, что от такого провайдера побегут табунами. Например, с gmail.com могут работать и приложения помимо браузера.
На данный момент знаю, что во многих провайдерах с кем я общался трафик https до заблокированных ресурсов игнорируется, но думаю это дело времени. Как начнут штрафовать и приглашать в суд все перекроют и в этом случае бежать будет некуда.
ребята, вы сейчас столько советов для Ростелекома дали… может таки зря?)
Это уже можно назвать будет внедрение в личную переписку.
Не знаю, готов ли будет оператор пойти на такой радикальный шаг.
Я думаю тут не столь вопросы к оператору, сколь к роскомнадзору о включении в реестр ссылок (URL адресов) с https. Ибо сам факт присутствия третьих лиц в обмене трафика по https вызывает негодование. А ведь по https многие и с банками общаются, и почта (частная переписка, деловые дела и т.д.)
Включение в реестр — как бэ не означает подмену трафика.
а как тогда еще блокировать конкретный урл? например: https:// www. youtube.com/watch?v=pja-6CIo19s если пакеты в зашифрованном виде? Либо блокировать по ip или весь домен или стать посредником расшифровывая трафик и тем самым определять куда идет клиент и является ли этот URL запрещенным.
Насколько я понимаю, как происходит сама блокировка на данный момент мало волнует Роскомнадзор, для них важнее, чтобы каждый оператор 2 раза в сутки заходил на их ресурс, авторизовывался там и забирал выгрузки из реестров. Они по этому показателю определяют — блокирует что-то тот или иной оператор или нет.
Выгружать реестр необходимо не реже одного раза в сутки. При изменении значение lastDumpDateUrgently незамедлительно выгружаем. Проверки проводят, за не заблокированный контент наказывают, но пока это проходит избирательно, но все же проверки имеют место быть.
Опять же насколько я знаю, проверки они начинают проводить именно против тех операторов, которые не выгружают данные в течении какого-то времени.
Если вы имеете прецеденты отличные от этого, прошу дать пруфы, было бы интересно ознакомится с такими материалами.
Кстати, раз вы в теме — такой вопрос: а как происходит отмашка на немедленное блокирование по закону о полит.цензуре по решению Генпрокуратуры? РКН же дает отчет, что такие сайты блокируются операторами в течении часа где-то.
По идеи вы должны делать запрос getLastDumpDateEx каждые 10 минут и в случае изменения lastDumpDateUrgently приступить к незамедлительной выгрузки дампа и последующему применению его. По поводу проверок, были несколько случаев. Один из них: оператор некоторое время (полтора месяца) не выгружал дамп, но в арбитраже отделался предупреждением. Суть предоставили дампы и сказали, что выгружали. Последующие проверки были именно на наличие блокировок.
Ну собственно о чем я и говорил.
Так все-таки оператор должен мониторить целый день выгрузки из реестра, а не раз в сутки — выгрузил и забыл?
именно так. Данная ситуация появилась с начала года когда в реестре появились записи от генпрокуратуры и дополнительные поля связанные с незамедлительной блокировкой.
точно так же, как и отсутствие в реестре не будет означать, что трафик не может быть подменен? Где гарантия, что этим функционалом не будут пользоваться «злоумышленники»?
… только стоить это будет всё уже не миллион долларов
Доменное имя можно вытащить из полей Subject или SAN передаваемого сервером сертификата.

А еще у TLS может работать SNI — доменное имя вообще передается без шифрования.
Те, кто предусматривает пользователей с IE версии <= 7, либо на операционке ниже Vista обычно SNI не включают.
А это ничего не меняет, потому что если без SNI, тогда соответствие хост-домен уникально.
Согласен. В любом случае, MiTM.
Сперва организуют MitM, а затем поймут, что он позволяет банковские данные сп████ть и приторговывать ими.
Собственно тут встает вопрос черных списков сертификатов, которые могут быть использованы заинтересованными компаниями-провайдерами.
Тогда остается вариант с заглядыванием в сертификат. Там доменное имя по-любому должно иметься.

соответствие хост-домен уникально.

Не факт. Если SAN (вариант — wildcard сертификат), то доменов на хосте может быть хоть сколько. Другой вопрос, что они скорее всего под одним владельцем, потому что сертификат будет один.
Каждый ssl-сайт должен иметь свой ip, разве не так? Будут просто блокировать по ip.
SNI. Не поддерживается динозаврами вроде IE6, им будет отдаваться дефолтный сертификат, но в целом вполне рабочая технология.

Странно это: придумывать всю эту схему и внедрять ее только для того, чтобы снова блокировать по IP из-за https. Тут либо прикрывать весь 443 порт (но оставлять остальные), либо перенаправлять на свой прокси с невалидным сертификатом, посылая к черту всю безопасность и приучая пользователей, что жать «все равно продолжить открытие» — это нормально. В общем и так и этак плохо.
Снова: в отправляемом сервером сертификате прекрасно виден список доменов, к одному из которых обратился клиент. Это, конечно, не избирательность на уровне URL, но и не блокировка по IP адресу.
Ок, про сертификат не подумал, можно и вокруг него накрутить логику. Но я могу внезапно сделать сайту самоподписанный сертификат на левый домен и тут случается казус: добрый провайдер скорее всего начинает слегка нарушать закон (каюсь, читал давно и по диагонали, поэтому возможно все хитрее): сайт все еще доступен, причем по тому же IP и домену, что был ранее, хоть браузеры и начнут всячески предупреждать, что туда лучше не ходить. С любым «живым» сайтом вряд ли такое сотворят, но чисто провокации ради — почему бы и нет. Хотя это наверное уже придирки.
На этот случай можно периодически пробегаться циклом по всем доменам из списка роскомнадзора, проверять валидность сертификата, и если сертификат некорректен — заносить в отдельный список «забанить по айпи». Я такой скрипт на баше за пару минут напишу (при условии, что какой-нибудь curl умеет вытягивать сертификат в текстовом виде). Собственно, какие-то скрипты уже бегают по DNS в поисках IP адресов, которых в списке нет.

Меня вдруг другое заинтересовало. Допустим, записи badsite.com нет в глобальном DNS. Есть адрес 1.2.3.4, на котором вебсервер ждет GET на badsite.com, иначе выдает заглушку. Есть рекомендация владельцев сайта записывать адрес в hosts или пользоваться особым DNS сервером. Что тогда произойдет с блокировками? По идее, даже РТ имеет полное право развести руками и сказать «не резолвится, ничем не могу помочь».
SNI. Не поддерживается динозаврами вроде IE6, им будет отдаваться дефолтный сертификат, но в целом вполне рабочая технология.

Если технология придумана, это не значит, что все сразу побежали её внедрять. SNI не поддерживается достаточно большим числом ПО, чтобы все стали размещать несколько сайтов на одном IP в ближайшие годы.
Блокировка ssl-сайтов по ip будет работать достаточно хорошо и ничего лишнего блокироваться не будет. Ну может кроме wildcard-сертификатов.
Есть распоряжение «Роскомнадзора» от 23/07/2013 №18 «О рекомендациях по организации и техническим решениям по ограничению операторами связи доступа к сайтам в сети Интернет, содержащим информацию, распространение которой в Российской Федерации запрещено». Там как раз разъясняется как ограничивать доступ.
Вот схема работы подобной блокировки.
image
На прокси заворачивается трафик по IP адресам запрещенных ресурсов, в этом и есть основной недостаток метода, есть шанс завернуть на прокси весь трафик vk.com, и она сразу умрет, ну и соответственно с крупными SDN поставщиками такой фокус не пройдет, слишком много трафика, их проще по старинке, по IP банить, соответственно, именно поэтому РКН рекомендовал не раздавать с них свой контент.
UFO just landed and posted this here
Что примерно это будет собой представлять

Действительно, новый ти фильтрации.
«Отныне вас будут лупить по выходным на главной площади не куском витой пары, а специально сделанной для вас индивидуальной плетью».

Правильной дорогой идёте, товарищи. Зачем избавляться от фильтрации, надо всего-то сделать её изощрённее!
Оно работает так: если адрес страницы, которую вводит пользователь, фигурирует в черном списке, то его запрос направляется в маршрутизатор.

А иначе оно куда направляется?
НАТится по старинке, без лишних узлов в подключении.
Тогда оно что, минует маршрутизатор? Тега irony на хабре явно не хватает.
Ух ничего себе у них цены. Я уже даже статью написал как это сделать. Даже если сделать кластер из Squid то оно явно меньше причем на порядки меньше по стоимости.
Миллион долларов — это копейки под такой проект. Мы говорим о решении, которое:
1) Хотя бы иногда не будет падать, а при падении отдельных узлов окажет минимальное влияние на сервис (вы про свой кластер такое скажете?).
2) Переварит десятки/сотни гигабит трафика. Т.е. само железо будет стоить приличных денег.
1) Да, в HA стоит 3 штуки (ноды) даже просто вырубив питание все работает (даже ролик с youtube грузится дальше)
2) Последние нагрузочные тесты показали что один 4 ядерный проц уровня i5 вполне может переварить 3Gb/s (небыло под рукой еще сетевух). Загрузка всего 40%.

PS Мы конечно сильно меньше Ростелекома от сюда и более скромные требования.
1) Это на бумаге. Вы допускаете, что кластер например возьмет и разъедется по каким-то причинам?
2) Ок. Это — одно лезвие в корзине, скажем — начиная с $10k. Есть еще сама корзина, есть сетевое оборудование, есть еще одна корзина, и третья (ведь мы же не один кластер будем делать), есть массивы под них. В случае с отдельными серверами все равно получаем сотни килодолларов только на серверную часть.
1) Я говорю о реальном тестировании, а не «на бумаге». В теории да он может развалиться, от этого никто не застрахован.
2) Это обычные компьютеры за 19 тысяч рублей (1проц 8GB Ram 2 HDD + сетевые карты нормальные). Винты нужны только для загрузки. БД сейчас отдельная.
1) «Реальное тестирование» — оксюморон. В лабе у всех всё работает. Смотреть надо на опыт боевой эксплуатации длиной хотя бы в год — за этот период изучать статистику отказов.
2) Т.е. колхоз, который ни один приличный ЦОД не примет. Не стоечный, без ECC памяти, без сдвоенных БП, без легко меняемых винтов (а ведь отдавать такой контент из кеша может быть хорошей идеей) и так далее. Т.е. отметаем сходу и не рассматривая.
Гуглу про колхоз расскажите, они других серверов не держат. Просто нужно больше нодов.
Никогда не смотрите на гугл, амазон и так далее, планируя собственную инфраструктуру. Вообще не смотрите, забудьте об их существовании. То, что у них работает хорошо, у других либо вообще работать не будет, либо поднимет TCO до небес за счет сложности сопровождения (если некая инфраструктура отлично масштабируется до сотен тысяч узлов, то это не значит, что она будет сравнительно хорошо работать на нескольких десятках узлов).

И нет, гугл держит самые разные сервера, включая вполне традиционные и блейдовые, а не только «самые дешевые». И сетевое оборудование у них тоже бывает покупным, вплоть до самых обычных цискиных каталистов, а не только собственной разработки. Вы, кажется, забыли, что Google — это не только Search, Mail и так далее (данные задачи не имеют никакого отношения к задачам прокси-сервера).
А у меня в смб виртуалки на hyper-v + starwind прекрасно работают на гуглоподобных нодах. И прекрасно переносят и падение и выход ноды из строя. Брендовые сервера нынче нужны только для приложений, которые не вмещаются на обычный комп и не параллелятся.
«Гуглоподобная нода» — это не «хлам, собранный из того, что было», а «десятки или сотни тысяч идентичных конфигураций с определенным ПО и легкой переносимостью смерти и замены даже стоек целиком». С вашими SMB задачами в полном объеме наверняка справится мой домашний компьютер, кластеры не нужны. И даже минутный простой сервиса будет не катастрофой и даже «ну пошли пить чай», в SMB RTO составляет часы.

Приложение «проксирование сотен гигабит трафика» не очень хорошо масштабируется из-за аппаратных особенностей сетевого оборудования (даже WCCP не даст более 32-х нод на группу), потому ему желательны мощные ноды, а также запас прочности при перекосах трафика. Репликация сессий между нодами нереалистична (слишком большие штрафы), переназначение сессии на другую ноду означает сброс соединения, что особенно плохо для магистрала.

Еще немного, и я услышу бред вроде «у меня в SMB отлично работают микротики — пусть Ростелеком заменит маршрутизаторы линеек ASR9k и CRS либо аналоги других вендоров (каждый стоимостью в сотни тысяч долларов в полной набивке) на микротики, экономия будет в десятки раз». Нет, ребята, это не будет экономией, это будет выбрасывание денег сначала на заведомо непригодное железо, потом убытки от простоев, потом закупка нормального оборудования.
«Гуглоподобная нода» — это не «хлам, собранный из того, что было», а как раз идентичные компьютеры из хороших, но декстопных компонентов. А смб разные бывают, после внедрения этого кластера, 3-й год аптайм 100% (при включенном электричестве, генераторов у нас к сожалению нет), ноду одну уже чинили.
Про Ростелеком не знаю, я отвечал на ваш пассаж про невозможность использования архитектуры, рассчитанной на большое количество узлов, на малом количестве.
я отвечал на ваш пассаж про невозможность использования архитектуры, рассчитанной на большое количество узлов, на малом количестве.

То есть в вашем понимании «архитектура» ограничивается выбором конкретного вида железок из списка похожих? Софт, работающий на этом железе и определяющий выбор железа, не рассматриваем? У гугла ведь на тех «дешевых серверах» (напоминаю, у него полно и дорогих брендовых серверов) крутится нечто Hadoop'образное. Оно масштабируется почти линейно. А у вас что? В SMB нет и не может быть ничего связанного с big data.
Правильно, я и сказал «Брендовые сервера нынче нужны только для приложений, которые не вмещаются на обычный комп и не параллелятся».

У обычного бизнеса вообще задачи плохо параллелятся. А вот аптайм и удобство манипулирования виртуалками всем нужно. И все это можно получить на дешевом железе.
А вот аптайм и удобство манипулирования виртуалками всем нужно. И все это можно получить на дешевом железе.

Но причем тут архитектура?

Все задачи SMB вообще поместятся на один физический сервер, даже NAS не потребуется…

А задача подобного проксирования уже требует распараллеливания, и при этом не очень хорошо параллелится. Да и аргумент «вон там мелкие конторы решают совершенно другого рода задачи на копеечном железе» не прокатит по понятным причинам.
Сказки это про гуглоколхоз. То что можно делать и что в реале используется разница просто колосальная. При таком числе дешевого железа — физически успевать менять выгоревшее железо уже проблема.
Не столько проблема, сколько задача — от кого и куда поставлять железо, сколько людей нужно для контроля работоспособности, приёма новых запчастей и замены, куда вывозить мусор на утилизацию. Логистика плюс набор и организация работы коллектива местных специалистов.
ЭЭЭ а при чем тут 3 Gb/s? Три это конечно хорошо, да еще и с нескольких линков. Но с 10Gb/s с одного линка уже значительней хуже, это просто с сетевухи до хоста передать уже не тривиально. Не говоря уже про 40GB/s. А десятки GBs это провинциальный узел ростелека, не говоря про моську.

А в реальной жизни одни только опитические байпасы на случай отказа денег стоят. Так что 1 лям долларов, даже без железа, это вообще ни очем.
Во первых: Я отвечал сколько реально может прогнать через себя фильтр.
Во вторых: При трафике 3Gb/s всего 50 запросов (~1Mb/c) в секунду приходится на squid (это при том что youtube.com висит в списка фильтрации). В сухом остатке имеем соотношение 3:0,001 или общий трафик должен составлять ~3Tb/s
В третьих: фильтровать нужно не весь поток и не в одном месте, а только часть, 80 порт и только нужные IP. При этом squid используется только для фильтрации конкретных URL отсюда и такие смешные цифры.
Ждем открытия дополнительных портов, кроме 80-го.
Скоро каждый уважающий себя трекер будет биндить сотню нестандартных портов для приема запросов :).
И раздавать UUE-кодированные .torrent-файлы в эхоконференциях Фидонета.
вы верите в верность вашего примера?
достаточно некоторые сайты начать открывать на порту 25 и эта система фильтрации окажется негодной.
Вы, кажется, сочли мой комментарий ироническим, тогда как я рассуждал совершенно серьёзно.
Тогда практический вопрос: как вы организуете поиск?
Пишешь в конференцию: «люди, есть у кого торрент на баттлфилд4?»
Теперь понятно, отчего жж тормозит при открытии.
Первая картинка в посте напоминает схему продвижения войск при атаке

image

image
Мне кажется я такую аналогию уже приводил, но не могу не повториться:
это больше напоминает распределение наркотрафика из Афганистана по миру.
Только некоторые стрелочки в обратную сторону направить))
Верно ли я понял:
Теперь можно сайтам заблокированным писать, что надо лишь указать в hosts адрес например роскомнадзора с айпишником сайта.
Хотя рано или поздно они привяжут этот адрес в блок лист к этому айпи. Но ведь можно нагенерить адреса.
Можно даже сделать так, чтобы пользователь мог сам ввести адрес, а он уже добавится в конфиг например nginx. Можно даже придумать форк nginx динамическими адресами.
Форк nginx для этого не нужен. Необходимо, только грамотно его настроить в свзяке с named. Другое дело, что борьба брони и снаряда не имеет ни конца ни победителя — такой «хитрый» сайт просто-напросто начнут снова блокировать по IP.
У меня провайдер — дочка Ростелекома.
Месяц назад они пытались внедрить блокировку ютуба по url — в результате по http ролики загружались по 30-60 секунд, по https загружалось мгновенно.
Короче, сделано было криво до почти полной невозможности работы.
Дня через 3 отменили.

Вполне возможно, что тестировали именно то, о чем написано в посте.
Такое с некоторой периодичностью наблюдаю уже 3й месяц. http думает на открытии. Если страничку открыть, то обновляется она уже моментально до изменения контента на ней. Как раз провайдер РТ.
Лечится запуском быстрого тоннеля.
У ростелека будет реализовано это следующим образом:
1) На маршрутизаторах/ядре сети будет выставлена политика маршрутизации для запрещенных IP адресов
2) Если IP адрес из черного списка — он направляется на прокси/dpi для определение урла и дальнейшего блокирования

Данная схема уже используется у многих провайдеров.

Минус для Телекома в следующем — если в бан попадает IP адрес крупного ресурса — то он весь пойдет через прокси, а это означает рост трафика, что скорее всего приведет к падению прокси.

К плюсам для нас — Телекомы не нашли Библа для внедрения DPI тк у нас слишком жирные аплинки в мир, и на установку DPI потребовалось бы потратить огромное количество денег.

Ну и конечно — раз это не DPI — значит у нас не может быть (в ближайшее время) ничего другого кроме черных/белых списков
Сделают кластер проксей. Пока одни ноды в отвале, другие подымаются, третьи работают. И так по кругу :)
А DPI… Дорого, медленно. Но в любом случае, персонал нужен ещё толковый.
UFO just landed and posted this here
Какой там, обходится через anchor navigation, сайты так к этому идут, к повальному ajax и # в ссылках
вы так говорите, как будто там внутри ajax не HTTP.
Алло, народ! Я на ресурсе IT-подкованных, или где?

Поднимет твиттер и фейсбук полностью anchor-навигацию, и что будет банить ростелеком, если ссылки будут иметь вид twitter.com/#killyourself
Специалисты ростелекома будут каждый день реверсить протоколы связи с блокируемыми серверами, чтобы выделить, в каком формате браузер общается с ним? Для всех 100500 ресурсов? Они ведь потому от DPI отказались, потому как дорого! Это задача того же уровня.
UFO just landed and posted this here
Потому и было написано выше про «реверсить протокол».
ajax-обработчик для подгрузки контента всё равно делает запрос на URL, связанный с запросом.
например, для твиттера, на twitter.com/hashtag/killyourself

Другое дело, если сайт захочет активно противодействовать. Например, добавит к запросу случайную соль и зашифрует публичным ключом сервера. А сервер расшифрует своим приватным ключом и обработает запрос. Тут блокировать можно либо сайт целиком, либо искать в response ключевые слова/тексты.
UFO just landed and posted this here
Поверх HTTP тоже можно построить API собственного изготовления, чем не протокол.

Заблокировать невидимый URL для внутреннего ajax-запроса — легко, почему нет. Если это будет массовая, а не одноразовая потребность (те же разнообразные хеш-теги твиттера) и сервис не будет противодействовать блокировкам, меняя структуру URL для поиска по тегу.
UFO just landed and posted this here
Спасибо родному Ростелекому за дополнительную мотивацию не возвращаться на Родину в ближайшие лет десять.
UFO just landed and posted this here
Боюсь, что если я сделаю патч — Родина мне не «спасибо» скажет, а по башке настучит. Да и делать мне на Родине в любом случае особо нечего — юридически у меня девять классов и коридор.
UFO just landed and posted this here
Заканчиваю заграничные тринадцать.
Ну внесут какой-нибудь ролик с https ютуба, и как будут развиваться события?
Анализировать тяжелый трафик с сотен айпи путем подмены сертификатов? Так на это им явно не хватит миллиона + все будет тормозить по минуте, не говоря уже о моральной стороне вопроса.
Заблокируют ютуб по айпи и введут тарифы «диссидентский» и «порнографический».
YouTube — это (по букве закона, подписанного Путиным и вступающего в силу 1 августа) незарегистрированный блог с более чем 3000 посещений.

Следовательно, через восемьдесят дней его тупо закроют, никакого DPI не понадобится.
в Туречине уже закрыли, но у них фильтрация основана на NS-проксях.
>Ну внесут какой-нибудь ролик с https ютуба

«Video Not Available In Your Country» — и всё.
Принцип у него односторонний. Кучу роликов удалили о событиях в одессе, выставляющих патриотов единой украины в неприглядном свете.
Не уверен, что будет следующим шагом — DPI или белые списки. Но думаю, что одними прокси не обойдется. В 2007 в Китае был такой же легко обходимый прокси, а сейчас — уже полноценный DPI с запретом даже сайтов со списками free open proxy. А если заодно накроется возможность платить зарубежному хостингу картами Visa и MasterCard, то даже свой сервер в Hetzner'e будет не поднять :( В Китае хотя бы международные платежи не запретили. Впрочем, автор статьи по ссылке в моем комментарии надеется, что и у нас не запретят.
В МТС уже больше года блокируют на уровне BGP, а вместо DPI для выявления торрентоидов давно все используют бесплатное средство — retracker.local, а в логах список всех IP клиентов-торрентоидов, только вот бороться с ними смысла особого нет
Крым уже Россия, отредактируйте мап)
Сорри, но это актуальная карта с сайта Ростелекома))
Оказывается то у нас Ростелеком оппозициониер и непатриот!
Это спорная территория. Как перестанет быть таковой — отредактируют.
А ещё, по мнению Ростелекома, Латвия получает трафик из Пскова? Ну да, ну да.
Какой веселый PR и дистанцирование от владельцев DPI, дескать они не такие )
DPI — это в первую очередь принцип анализа пакетов глубже чем L4. То что они гонят трафик через прокси — всего лишь один из возможных вариантов реализации DPI. На самом деле даже прокси не нужен, есть решения которые снимают пассивный оптический TAP, рвут сессию между клиентом и сервером подставными TCP пакетами и прикидываются сервером. Получается очень дешево, на это же штуке элементарно поднимается родительский контроль. И еще куча решений есть. И все они попадают под определение DPI.

Стоимость — тоже вопрос интересный. Надо смотреть на TCO, там сервисов может быть огого, которые отлично покроют капзатраты.

Ну и чуть-чуть занудства.

Открываем нашумевшую рекомендацию ITU-T Y.2770.

deep packet inspection (DPI): Analysis, according to the layered protocol architecture
OSI-BRM [ITU-T X.200], of:
• payload and/or packet properties (see list of potential properties in clause 3.2.11) deeper
than protocol layer 2, 3 or 4 (L2/L3/L4) header information, and
• other packet properties in order to identify the application unambiguously.
NOTE – The output of the DPI function, along with some extra information such as the flow information is typically used in subsequent functions such as reporting or actions on the packet.


Заголовок прозвучал как «Не гербалайф». Причем завернуть при помощи BGP трафик на «прозрачный» сквид — это делается сравнительно легко, и миллионы для этого не нужны. Разве что вопрос в производительности: прожевать трафик РТ действительно непросто. Но пафос, с которым DPI называется плохим, требующим монетизации, подходом, как бы противопоставляя «не догнавших фишку» внедривших DPI операторов самому РТ & Ko, придумавшим что-то более быстрое, умное, адресное… И меньше умеющее, посему более подходящее операторам, как бы…

Упоминание про монетизацию меня порадовало — неужели повесят на «заглушках» баннеры?

Правда, никто не обещал, что сия мегаразработка выдюжит весь трафик. Зарубят немногое — а там еще попросят финансирования, я так полагаю, на баннерах-то сыт не будешь, если учесть аппетиты РТ.
Есть куча способов монетизации traffic engineering помимо баннеров, как то: платные QoS в зависимости от типа трафика, шейпинг «безлимитных» тарифов, родительский контроль, всякие решения по безопасности итд итп.
Кстати, были у некоторых операторов вставлять в трафик свою рекламу и «панель управления».
«Главный провайдер» «Великой Ымперии» не может осилить DPI и начинает корячить «своего собственного кальмара с блекджеком и жабрами».

Е[redacted]ный стыд.
если адрес страницы, которую вводит пользователь, фигурирует в черном списке, то его запрос направляется в маршрутизатор. Это устройство распознает URL, который нужно блокировать, и запрещает к нему доступ. А к разрешенным страницам на том же IP-адресе доступ остается открытым
А это точно не DPI?
не видит способов монетизации
т.е. можно будет подключиться к тарифу «Диссидентский» и нормально всё будет открываться?
Какой же это DPI? Ежу понятно, что это 8-ball.
Чувствую грядут легкие деньги — «а сделай мне пожалуйста, чтобы все ролики на ютюбе открывались!»
Sign up to leave a comment.

Articles