Лично я ничего не имею против того, что МарсГлавНадзор чего-то там блокирует. Мне дела нет до всяких одиозных сайтцов. Но - меня сугубо напрягает, когда блокируется половина сервисов Гугла, которые лично я использую в работе каждый день. Транслятор, драйв, глобальный портал Гугла.

Кроме того, есть еще один либеральный принципиальный вопрос.
 

Я взрослый человек и я желаю САМ решать, что мне вредно а что - полезно. И если я, как админ прокси, что-то разрешаю своей пастве - я не желаю, чтобы это мое подмножество разрешенного кастрировали. И остальные взрослые за моей инфраструктурой также имеют это право.

 

Давайте посмотрим, как можно отправить "господ" из МарсГлавНадзора в пешее эротическое путешествие. То есть сюда.

 

 

Опыт последних лет показал, что для блокирования интернет-ресурсов используется, как правило, три подхода (по отдельности или в различных комбинациях): транспарентный перехват DNS-запросов, транспарентное проксирование HTTP/HTTPS и блокировка по URL и DPI.

 

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

 

Это базовая техника блокирования, в прошлом - единственная. Вначале достаточно элементарно обходилась клиентами путем добавления нужных записей в локальные файлы hosts. 

 

Ныне данное решение практически неработоспособно.

 

Провайдеры используют перехват всего трафика UDP/53 как по порту, так и прямые обращения к корневым серверам (root-hints) и к широко известным публичным DNS (Google DNS, OpenDNS итп.).

 

Данный трафик прозрачно заворачивается на провайдерский DNS с авторитарными зонами для блокированных доменов.

 

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

 

Прямое задание DNS-серверов, угодных лично вам, а не провайдеру - помогает плохо. Вы используете общеизвестные сервера, а Мордору они тоже известны.

 

Некоторые провайдеры (например, пчелайн) тупо энфорсят использование своего DNS для установления клиентского соединения. Так - и баста. С учетом того, что они в принципе лижут ж.пы правительствам стран, в которых работают - обойти это довольно сложно без промежуточного хоста и некоторых ухищрений (однако, это возможно).

 

Как обнаружить подмену DNS?

 

С определенными оговорками по части вероятности обнаружения - вот детектор.

 

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

 

Следует учитывать, также, тот факт, что наличие собственного DNS в вашей компании не спасает от подмены DNS. Кэширующие сервера отравляются недостоверными записями из провайдерских практически молниеносно (вы же не задаете для них максимальный TTL, верно?)

 

Да, мои маленькие мохнатые друзья. Такая вот атака Каминского в промышленных масштабах (строго говоря, это не совсем Каминский, однако для простоты примем это утверждение). Обычно провайдер, блокирующий домен подобным образом, отправляет вопросившего в никуда. Например, на широковещательный адрес его собственной внешней сети либо на отсутствующий IP, смахивающий на настоящий - т.е. фактически в никуда.

 

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

 

В предыдущих публикациях я наглядно показал, как легко можно построить практически невидимый транспарентный HTTP/HTTPS-прокси общедоступными средствами. 

 

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

 

Оставив в покое коллег-крыс, реализующих подобное с любыми корыстными целями, хочу заметить, что существует масса проприетарных высокопроизводительных решений от вендоров (например, IBM - что совершенно не странно. Ничего личного - это лишь бизнес, ребята), которые массово закупаются мордорскими правительствами.

 

Обход подобных методов требует наличия как минимум простецких средств типа Hidemyass, FriGate (практически бесполезен в 2014м году), ZenMate (легко блокируется ввиду конечного количества и статичности выходных серверов) и тому подобных браузерок.

 

Почему я считаю подобные методы бесполезными?

 

Первое. Легко блокируются сами сайты производителя.

Второе. Элементарно вычисляются и блокируются входные точки сервисов.

Третье. Подобные решения обычно используются для защиты лишь HTTP/HTTPS и 

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

 

Что действительно эффективно в подобном случае?

 

Tor, только Tor и пока ничего кроме Torа.

 

Достоинства Тора:

 

Первое. Он имеет распределенную плавающую структуру, которую дьявольски трудно заблокировать целиком. Даже Китай не сумел забанить _все_  узлы сети. Выходные ноды банятся легко. Входной нодой может являться любой узел сети.

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

Третье. Он часто использует нестандартные порты для роутеров, что позволяет проделывать разные трюки, затрудняющие блокировку.

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

Пятое. Доступ посредством бриджей практически невозможно заблокировать никаким образом.

Шестое. Тор позволяет обойти блокировку не только HTTP/HTTPS, но практически любых сервисов, которые можно затолкать либо в туннель, либо проксировать, либо используя SOCKS.

 

Безусловно, Тор не волшебная пуля - но очень мощное средство, решающее задачу чуть более, чем полностью.

 

 

Для клиентов с минимальными навыками существуют сборки, полностью готовые к употреблению.

 

Хотя мы рассматриваем инфраструктурное (сиречь серверное) решение, упомянуть о конечном клиентском решении все же стоит.

 

К недостаткам Tor следует отнести провал в скорости в большинстве случаев практического применения, что решается единственным способом - каскадированием с кэширующими прокси-серверами. Малоэффективно в случае одной клиентской машины, достаточно эффективно в случае инфраструктурного решения.

 

Глубокая инспекция пакетов является наиболее мощным средством блокирования почти всего, чего пожелает обладатель рубильника.

 

К счастью - банить все и вся невозможно ввиду наличия в реальном мире инфраструктур, нуждающихся в защите и неспособных эффективно функционировать в условиях полной открытости каналов. Например, банкинг. Или обработка персональных данных, которая при любых обстоятельствах и режимах нуждается в защите. В противном случае происходит коллапс основополагающих функций.

 

Как и в предыдущем случае, Tor, благодаря своему дизайну, позволяет с различной степенью затратности обойти и проигнорировать блокирование.

 

Учтите следующее. У клиентов Tor (равно как и у серверов) есть характерная сигнатура при входе в сеть. Которую легко заблокировать. 

 

Однако (см. второй абзац данного раздела) режим бриджа спасет гигантов мысли.