Русский
Русский
English
Статистика
Реклама

Блокировки

Пиринговые мессенджеры враг государства?

24.05.2021 12:21:25 | Автор: admin


В случае полного отключения интернета одна из главных проблем общение с товарищами и родственниками. Опыт Гонконга показывает, что для этого хорошо подходят децентрализованные P2P-мессенджеры, которые работают без интернета, используя mesh-сеть по протоколам Wi-Fi Direct, Bluetooth, Apple Multipeer Connectivity Framework, ANT+, LoRa и др.

Для эффективной коммуникации приложение нужно скачать максимальному количеству человек до начала блокады интернета. Иначе придётся искать файлы после блокады. Человек с нужными файлами станет настоящим авторитетом в офисе или в классе (как это было в Беларуси в августе 2020 года за файлами Psiphon люди реально приезжали из других микрорайонов города).

Вообще, вся история сетей wireless mesh намекает на то, что эта технология крайне не нравится правоохранительным органам.

Mesh-сети


Приложения типа FireChat создают mesh-сеть, используя Bluetooth и прямые подключения через Wi-Fi. Они обеспечивают обмен сообщениями и фотографиями в офлайне между устройствами, находящимися друг от друга на расстоянии примерно до 60 метров.

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

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

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

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

Особенно удобно, если каналы или комнаты в мессенджере создаются автоматически и объединяют людей, которые находятся рядом с друг другом (многоквартирный дом, стадион, концертный зал).

Для передачи текстовых сообщений можно приспособить практически любую mesh-сеть, даже сеть из геометок Apple AirTag, которые вообще-то предназначены не для общения людей, а для поиска утерянных вещей. В мае 2021 года хакерам удалось расшифровать трафик AirTag и передать по сети Apple Find My произвольный текст под видом оригинальных зашифрованных сообщений с GPS-координатами. Скорость передачи составила 3байта в секунду. Задержка в сети от 1 до 60 минут.



Подобные mesh-сети есть также у Samsung (Smart Things) и Amazon (Sidewalk) на протоколе LoRa. В принципе, можно использовать эту инфраструктуру для пирингового обмена сообщениями, а также для съёма данных с устройств вне зоны доступа в интернет.

Трагедия FireСhat


FireChat проприетарное приложение от американской компании Open Garden. Эта фирма прекратила дальнейшую разработку, не открыв исходники.

Последняя версия приложения: 9.0.14 (копия на 4pda) вышла полтора года назад (примечание: доступ к сайту 4pda затруднён с территории РФ).


FireChat

Первая версия FireChat появилась в марте 2014 года под iOS, в апреле под Android. Среди сооснователей Open Garden и разработчиков программы Станислав Шалунов и Грег Хазел из компании BitTorrent, где они делали торрент-клиент uTorrent (200 млн пользователей). Там и познакомились.

Вероятно, предприниматели рассчитывали, что FireСhat станет настолько же успешным, как файлоообменные P2P-приложения. Если представить себе эту картину, то весь мир может объединиться в mesh-сеть, а интернет становится практически не нужен! Даже хостинг сайтов теоретически можно размазать в распределённой сети. Такая фантазия.

Очень быстро FireСhat приобрёл популярность в Ираке после того, как местное правительство ввело ограничения на использование интернета, а затем то же самое произошло в Гонконге, во время массовых протестов 2014 года.


Главной проблемой FireСhat во время массовых протестов в Гонконге стала безопасность. Сама архитектура открытой mesh-сети предполагает, что все пользователи приложения светятся как радиомаячки на расстоянии 60 метров, а то и больше. Так что полиции отловить их было очень просто. Наличие программы на телефоне однозначно доказывало вину. Можно предположить, что сотни или тысячи пользователей были арестованы благодаря FireСhat. К тому же, в приложении не использовалось шифрование, так что никакие сообщения не были действительно приватными.

Возможно, критика от специалистов по ИБ повлияла на решение американской компании Open Garden прекратить разработку и не публиковать исходники. Ну или ребята увидели, что всемирная популярность торрентов им не светит, а развитие программы пошло совсем не по тому пути.

Когда появился FireСhat, это была единственная программа такого рода, которая позволяла пользователям создавать mеsh-сети в офлайновом режиме (без интернета) и обмениваться сообщениями1.

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


Фото из статьи FireChat мессенджер, на котором работают протесты в Гонконге, The Guardian

Тем более обидно, если FireСhat создавали специально для Гонконга, как разработку аналогичного приложения Commotion Wireless в 2011 году профинансировал госдепартамент США в преддверии Арабской весны. Хотели как лучше, а получилось как всегда

После FireСhat фирма Open Garden торговала электронными сим-картами (eSIM), продвигала свою криптовалюту, но в последние годы про неё ничего не слышно.

Вообще, приложение FireСhat было не очень качественным. Во-первых, закрытый код. Во-вторых, для регистрации обязательно (!) был нужен доступ в интернет, хотя потом оно работало в офлайне. Короче, странная программа. Может и хорошо, что разработчики её похоронили.

Рация Zello


Близкой по логике функционирования является интернет-рация Zello, которая заблокирована в Российской Федерации в апреле 2017 года.

Радио работает по принципу уоки-токи или push-to-talk. Основное преимущество возможность слушать голосовые сообщения по громкой связи в реал-тайме, вообще не притрагиваясь к смартфону и в то же время быть на связи с большим количеством пользователей.

Хотя здесь передаётся не текст/картинки, а звук, но принцип работы такой же через mesh-сеть, без интернета. Близкие друг к другу пользователи соединяются друг с другом напрямую и передают сообщения дальше, по цепочке. Что важно, здесь используется сквозное шифрование (E2E).

В России приложение получило особую популярность среди дальнобойщиков и других автомобилистов, поскольку очень удобно (и приятно) беседовать с попутчиками, которые едут по той же трассе. Они подскажут о радаре в кустах, о ДТП на дороге и т.д. Репрессии со стороны государства начались после массовых протестов дальнобойщиков в связи с введением обязательной платы миллиардеру Игорю Ротенбергу за проезд тяжёлых грузовиков по дорогам России (система Платон). Координация протестов осуществлялась через Zello, поэтому программу решили заблокировать.

Это был первый прецедент, когда власти попытались сломать мессенджер, работающий по VPN. Понадобился целый год, чтобы заблокировать свыше 4тыс. IP-адресов из облака AWS, что не принесло успеха. Тогда РКН пошёл на шантаж компании Amazon, угрожая заблокировать 26 подсетей AWS, в сумме 13,5млн адресов.

Компания Amazon оказалась не готова к войне и отказалась предоставлять услуги Zello. Лишившийся облачной инфраструктуры сервис было легко заблокировать.

После успеха с блокировкой облачной VPN-инфраструктуры Zello, в 2018 году власти решили, что смогут успешно заблокировать такую же облачную инфраструктуру мессенджера Telegram. Но здесь нашла коса на камень: Павел Дуров инвестировал миллионы долларов в покупку всё новых и новых инстансов AWS, его брат Николай с коллегами запрограммировал систему обхода блокировок через прокси, а компании Amazon и Google выдержали блокировку своих подсетей в РФ. В итоге властям пришлось заблокировать 18 миллионов IP-адресов AWS и Google Cloud, что нарушило работу крупных ритейл-компаний, банков из топ-20, частных клиник и тысяч бизнесов в России. После двух лет выматывающей борьбы государство сдалось: руководителя Роскомнадзора уволили, Telegram разблокировали, а IP-адреса облачных сервисов удалили из чёрного списка.

Криптомессенджер Briar


Четыре года назад, в июле 2017 года, вышла первая публичная бета-версия мессенджера Briar, который работает через Tor или в офлайне, через пиринг. Его разработка продолжалась аж три года. Но продукт вышел на редкость качественный.

Это уже честный опенсорс. Приложение можно собрать из исходников (пошаговая инструкция для Android Studio). Оно доступно в каталогах приложений (например, Google Play) и отлично поддерживается: последняя версия 1.2.20 от 2апреля 2021года. Реализована стойкая криптография, сквозное шифрование.


По умолчанию мессенджер работает через интернет по протоколу Tor (луковичная маршрутизация). В этом случае программа создаёт на устройстве пользователя скрытый сервис Tor и соединяется со скрытыми сервисами Tor других людей из списка контактов. В случае отсутствия интернета она переходит на peer-to-peer коммуникации через Wi-Fi Direct, локальную сеть или Bluetooth.

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

Поддерживает передачу сообщений (но не файлов), приватные группы, блоги/статусы и импорт RSS. Есть несколько полезных функций, таких как блокировка приложения (по PIN-коду).

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



Briar Project некоммерческий проект, который сейчас ведут шесть добровольцев. Код на 97,7% написан на Java (+немного Kotlin, Python и Ruby) и поставляется под GPLv3. Вскоре после первого релиза код прошёл независимый аудит безопасности от компании Cure53. Она известна своим аудитом проектов SecureDrop, Cryptocat и Dovecot. Так что Briar действительно надёжный вариант для пиринговых коммуникаций.

Единственный минус, что приложение выпущено только в версии под Android. Официальной версии для iOS нет и не будет, потому что эта платформа накладывает жёсткие ограничения на разработчиков, не позволяющие реализовать некоторые идеи P2P, и является закрытым проприетарным продуктом.

Но исходный код открыт, так что теоретически кто угодно может попробовать сделать стороннюю реализацию Briar под iOS, например.


Matrix, Riot, Element


Официальный клиент Element (бывший Riot) для относительно децентрализованной сети Matrix не поддерживает пиринговые коммуникации в офлайн-режиме и формирование mesh-сети.

В последнее время этот клиент получил некоторую известность. Сейчас количество пользователей Matrix/Element сравнимо с Briar или больше. У него есть сквозное шифрование, мосты в IRC, Slack, Telegram, Jitsi Meet и др. Но именно пиринга в офлайне нет.

См. также:


Secure Scuttlebutt p2p социальная сеть, работающая и в офлайне (есть клиент Manyverse для Android и iOS)

P. S. Кроме FireСhat, протестующие в Гонконге использовали малоизвестное мексиканское приложение Bridgefy, которое тоже умеет формировать mesh-сеть и передавать сообщения в офлайне. В октябре 2020 года приложение перешло на криптографический протокол Signal.

1 На самом деле ещё раньше были другие приложения, такие как Serval Mesh от проекта Serval Project или древний Commotion Wireless от Open Technology Initiative (с финансированием госдепа), но все эти разработки давно прекращены [вернуться]




На правах рекламы


Мощные виртуальные серверы на базе процессоров AMD EPYC для любых целей, в том числе для установки VPN.

Присоединяйтесь к нашему чату в Telegram.

Подробнее..

Как правильно блокировать T

25.08.2020 00:11:37 | Автор: admin

И заработать на этом...


Сунь-Цзы Искусство войны:
Пусть на улицах вражеской столицы шепчутся, что князь обворовывает народ, советники его предали, чиновники спились, а воины голодные и босые. Пусть жители калечат имя своего князя и произносят его неправильно Пусть им при сытой жизни кажется, что они голодают. Пусть состоятельные жители завидуют тем, кто в княжестве Вэй пасет скот. Разжигайте внутренний пожар не огнем, а словом, и глупые начнут жаловаться и проклинать свою родину. И тогда мы пройдем через открытые ворота
Китай, 5 ст. до н.э.

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

Объявление


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

Векторы воздействия


Прежде чем обсуждать контроль и противодействие, было бы неплохо определить объект контроля. Потому, мы начнем со способов воздействия, или, по другому, распространения (дез)информации.

Официальные СМИ


Все уважающие себя СМИ сейчас имеют свои новостные порталы, странички в соцсетях и, часто, мессенджерах, и, активно участвуют в распространении информации в сети.
Под термином официальные не обязательно подразумеваются государственные. Официальные это зарегистрированные, реально существующие длительное время организации, которые действуют в соответствии с законами той юрисдикции, где зарегистрированы. Их отличительная особенность необходимость действовать в правовом поле и нести ответственность за свои действия перед законом в их юрисдикции.
Примеры:
Частные и государственные новостные агентства любых стран.
Необходимость нести ответственность перед законом ограничивает распространение прямой дезинформации через данные каналы. Распространение прямой дезинформации через подобные каналы сродни применению ядерного оружия. Имеет огромный эффект, однако приводит к самоликвидации инструмента.
Пример прямой дезинформации:
Президент <такой-то страны> сложил свои полномочия по итогам государственного переворота, при условии, что это на самом деле не так.
После таких новостей практически в любой юрисдикции данное СМИ перестанет существовать.
Однако, непрямая дезинформация возможна. Примеры:
В Т****** канале заместителя председателя правительства <такой-то страны> появилась информация о том, что президент сложил свои полномочия по итогам государственного переворота. В данном сообщении не будет ни одного слова неправды, при условии, что сообщение канеле действительно было. Каким образом оно там появилось, и, настоящий ли канал, не имеет особого значения. По законам большинства юрисдикций никакой ответственности для данного СМИ за распространение данного сообщения не наступит.
Варианты:

  1. По сообщениям в канале какого-то мессенджера.
  2. По сообщениям в социальных сетях.
  3. Из всплывшего в сети видеоролика.
  4. По сообщению из другого СМИ не являющегося по-факту официальным.
  5. Согласно докладу организации
  6. Согласно мнению эксперта

Прямое указание на источник непосредственно перед самой информацией всегда означает мы не уверены в достоверности сведений и оставлем суждение на вас. По законам большинства юрисдикций это значит мы снимаем с себя всю ответственность за достоверность сведений.
Первые три категории проще всего в использовании, однако имеют ограниченный эффект, т.к. большая часть аудитории скептически относится к подобным сообщеиям.
Следующие две категории требуют содержания определенного количества организаций однодневок с целью распространения дезинформации и взятия ответственности на себя. Часто для таких организаций выбирают удобные юрисдикции.
С экспертами удобнее всего. Они высказывают только свое личное мнение, и за сказаное ими непосредственной ответственности СМИ не несет вообще, или эта ответственность ограничена. Требования к СМИ непосредственно на эксперта не распространяются. Любое уважающее себя СМИ имеет на быстром наборе экспертов на все случаи жизни.
Прошу не надо делать заключение, что все эксперты и организации врут и распространяют дезинформацию, а все сообщения в мессенджерах и соцсетях фэйки. Это далеко не так. Однако, следует всегда иметь ввиду, что непрямое распространение дезинформации с помощью этих инструментов через официальные СМИ возможно и используется.
Все мы уже наверно слышали про Fake News.

Агрегаторы


Давно уже прошли те времена, когда пользователи преимущественно получали информацию из единственного источника. Давно уже наступила эра различных агрегаторов, начиная с RSS, заканчивая сервисами вроде Гугл/Яндекс новости.
Крупные агрегаторы имеют широкую аудиторию и, при этом, исключительно цитируют чужие сообщения, неся ограниченную ответственность перед законом.
В следствии этого они являются лакомым куском для распрострнителей (дез)информации.
Т.к. агрегаторы практически всегда цитируют сообщения официальных СМИ, то, все методы применимые там, применимы и тут. Однако, существует дополнительное средство, которое гораздо более эффективно и применимо только к агрегаторам.
По аналогии с Fake News на официальных СМИ тут используются Fake Agencies.
Fake Agencies представляют собой стихийно созданные и, не обязательно, зарегистрированные СМИ-однодневки, которые во время проведения атаки стихийно или заранее регистрируются в агрегаторах и распространяют дезинформацию.
В свободное от распространения дезинформации время подобные Поддельные СМИ занимаются перепечатыванием (практически всегда автоматизированным) новостей с официальных каналов для создания видимости активной деятельности, и, своего штата сотрудников в принципе не имеют.
Часто, подобные СМИ делаются тематическими для придания большего веса в глазах читателя.

Рецепту блинов из журнала Мир кулинарии абстрактная домохозяйка будет доверять больше чем аналогичному из газеты Владивосток сегодня (названия изданий выдуманы, а совпадения случайны).

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

Социальные сети


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

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

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

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

Фэйковые аккаунты нет, это не просто единичные боты. Это миллионы и миллионы аккаунтов в социальных сетях которые выглядят совершенно живыми. Они ведут активную социальную жизнь. Благодаря автоматизированному копированию данных реально существующих аккаунтов в других/этих-же социальных сетях с небольшими изменениями, биографических данных. Имеют множество друзей из таких-же фэйков и реальных пользователей.
Многие хоть раз сталкивались с добавившимися к вам в друзья незнакомыми людьми, с которыми вы пообщались всего несколько раз в начале и забыли. Практически никто не удаляет таких друзей, т.к. чем больше у тебя друзей, тем лучше. Однако, владелец такого аккаунта записавшись к вам в друзья в ВФэйсбуке может используя вашу, немного измененную информацию содержать фэйковый аккаунт в Контакте (названия выдуманы, а совпадения случайны).

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

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

Ни в коем случае не стоит считать, что все это зло. Это лишь инструменты, которые могут использоваться как во зло, так и во благо. В том числе, для роспространения дезинформации, а потому попадают в сферу интересов государств.

Новомодные приложения


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

Способы контроля и противодействия


Профилактика


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

Другим способом профилактики является прямое распространение очевидной дезинформации не несущей непосредственного вреда государству. Используя те-же каналы, что могут использоваться для распространения (дез)информации противником, можно распространять не вредящую государству ложную информацию с последующим опровержением через официальные СМИ.
Регулярная работа с населением кардинально снижает доверие населения к подобным источникам информации и увеличивает доверие к официальным СМИ в собственной юрисдикции.
Кто не хочет учиться на чужих ошибках, будет учиться на своих.


Контр-воздействие


К этой категории относятся:
  • Распространение прямого опровержения (дез)информации.
  • Распространение информации о сомнительности источкка сообщения-(дез)информации.
  • Распространение множества сообщений снижающих (уничтожающих) репутацию источника.
  • Переключение внимания создание новой темы/потока сообщений с целью переключения внимание аудитории на более насущную проблему.
  • Создание информационного шума/тумана множетва (в том числе ложных) сообщений на смежные темы и распространение их через каналы используемые противником, таким образом, что созданная противником (дез)информация теряется на этом фоне, а доверие к каналам окончательно утрачивается.

Часто меры используются в комплексе.

Ограничительные меры


Это та самая категория, которую мне хотелось бы сегодня обсудить. Сюда попадают как всевозможные технические блокировки, так и законодательные / судебные запреты и последствия.

Виды ограничительных мер


Хотелось бы разделить ограничительные меры на две категории:
  1. Активные ограничительные меры цензура, блокировки каналов распространения сайтов, мессенджеров, приложений, обязательное лицензирование СМИ.
  2. Пассивные ограничительные меры вам никто не мешает распространять информацию и даже специальные службы бережно сохранят все что вы распространяете как вещдоки, но, если что не так, ждите визита компетентных органов, судебные иски или счета на тысячи долларов. В эту категорию я отношу и ловушки (honeypot), позволяющие намерено провоцировать пользователей на распространение запрещенной/ложной информации (Правообладатели самостоятельно выкладывающие на торренты произведения с целью поиска тех кто скачал. Поддельные оппозиционные/экстремистские/тематические группы в социальных сетях.) с обязательным наступлением правовых последствий.


Ограничения и свободы


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

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

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

Так как же правильно блокировать T*******?


Следующие ниже предложения видятся автором как хороший баланс активных и пассивных мер.
Вводится административная статья:
Незаконное использование технических средств противодействия контролю за распространением (дез)информации
С мизерным штрафом (пусть будет примерно как цена одного мороженого в ближайшем магазине) с наложением ограничительной меры лишения права на предоставление доступа к сети Интернет до уплаты штрафа. Ограничительная мера должна исполняться провайдером и накладываться только на тот терминал с которого осуществлялся доступ.
Дополнительное ограничение не более 2х штрафов в месяц с одного терминала. После второго штрафа доступ должен блокироваться до покупки соответствующей лицензии (См. ниже) сроком минимум на месяц. Нельзя выписывать одновременно более одного штрафа на терминал. Нельзя выписывать штрафы за периоды до разблокировки терминала после уплаты последнего штрафа (хронологически). Принцип, заплатил, получил амнистию.

Штрафовать надо того, на кого оформлен договор на доступ в интернет. К штрафу надо прилагать время, место, и логи на которых четко видно, когда и чем пользовались с его терминала доступа. Необходимо ввести технические средства предотвращения автоматизации оплаты данного штрафа, запретить провайдерам оплачивать штрафы за пользователей, а оплату принимать на государственных порталах вроде Российских Госуслуг с обязательной проверкой и вводом паспортных данных владельца терминала и КАПЧИ. При этом, данные должны совпадать с данными у провадера. Это не должно быть дорого. Это должно быть неудобно, и особенно неудобно для тех, кто пользуется чужим доступом в интернет.

К техническим средствам подлежащим ограничению необходимо отнести все запрещенные мессенджеры/приложения и все VPN сервисы/протоколы.

А как же публичные точки доступа и корпоративный VPN?


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

Это значит, что любой человек или организация должна быть способна такую лицензию себе позволить купить/оформить, и пользоваться мессенджерами и VPN свободно, без ограничений. Однако, необходимо делать это лично, а не через провайдера.

Экстренные меры противодействия


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

В качестве территориальной экстренной меры должна быть возможность блокировки всех терминалов имеющих подобную лицензию, работающих через любых провайдеров интернета, и, расположенных на определенной территории, с учетом типа терминала и заявленной цели его использования (частное лицо/организация, открытый/закрытый). Это рассматривается как более мягкая мера по сравнению с полной блокировкой доступа в сеть для всех, используемой сейчас.

Куда пойдут деньги?


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

Как это будет работать?


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

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

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

Будут частично решены проблемы финансирования ведомства и оборудования провайдеров соответствующими техническими средствами.

P.S.


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

Все это, исключительно мое субъективное мнение.

P.P.S.


Цитата в начале статьи часто встречается в сети совместно с указанием источника, однако, источник не подтвержден. Прошу воспринимать ее лишь как пример воздействия на аудиторию.

P.P.P.S.


К сожалению, благодаря резкой негативной реакции аудитории я потерял возможность отвечать на ваши коментарии, однако, спасибо пользователям вроде Wyrd за то, что хоть у кого-то есть чувство юмора :-).
Подробнее..

Recovery mode Как правильно блокировать T

25.08.2020 02:16:19 | Автор: admin

И заработать на этом...


Сунь-Цзы Искусство войны:
Пусть на улицах вражеской столицы шепчутся, что князь обворовывает народ, советники его предали, чиновники спились, а воины голодные и босые. Пусть жители калечат имя своего князя и произносят его неправильно Пусть им при сытой жизни кажется, что они голодают. Пусть состоятельные жители завидуют тем, кто в княжестве Вэй пасет скот. Разжигайте внутренний пожар не огнем, а словом, и глупые начнут жаловаться и проклинать свою родину. И тогда мы пройдем через открытые ворота
Китай, 5 ст. до н.э.

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

Объявление


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

Векторы воздействия


Прежде чем обсуждать контроль и противодействие, было бы неплохо определить объект контроля. Потому, мы начнем со способов воздействия, или, по другому, распространения (дез)информации.

Официальные СМИ


Все уважающие себя СМИ сейчас имеют свои новостные порталы, странички в соцсетях и, часто, мессенджерах, и, активно участвуют в распространении информации в сети.
Под термином официальные не обязательно подразумеваются государственные. Официальные это зарегистрированные, реально существующие длительное время организации, которые действуют в соответствии с законами той юрисдикции, где зарегистрированы. Их отличительная особенность необходимость действовать в правовом поле и нести ответственность за свои действия перед законом в их юрисдикции.
Примеры:
Частные и государственные новостные агентства любых стран.
Необходимость нести ответственность перед законом ограничивает распространение прямой дезинформации через данные каналы. Распространение прямой дезинформации через подобные каналы сродни применению ядерного оружия. Имеет огромный эффект, однако приводит к самоликвидации инструмента.
Пример прямой дезинформации:
Президент <такой-то страны> сложил свои полномочия по итогам государственного переворота, при условии, что это на самом деле не так.
После таких новостей практически в любой юрисдикции данное СМИ перестанет существовать.
Однако, непрямая дезинформация возможна. Примеры:
В Т****** канале заместителя председателя правительства <такой-то страны> появилась информация о том, что президент сложил свои полномочия по итогам государственного переворота. В данном сообщении не будет ни одного слова неправды, при условии, что сообщение канеле действительно было. Каким образом оно там появилось, и, настоящий ли канал, не имеет особого значения. По законам большинства юрисдикций никакой ответственности для данного СМИ за распространение данного сообщения не наступит.
Варианты:

  1. По сообщениям в канале какого-то мессенджера.
  2. По сообщениям в социальных сетях.
  3. Из всплывшего в сети видеоролика.
  4. По сообщению из другого СМИ не являющегося по-факту официальным.
  5. Согласно докладу организации
  6. Согласно мнению эксперта

Прямое указание на источник непосредственно перед самой информацией всегда означает мы не уверены в достоверности сведений и оставлем суждение на вас. По законам большинства юрисдикций это значит мы снимаем с себя всю ответственность за достоверность сведений.
Первые три категории проще всего в использовании, однако имеют ограниченный эффект, т.к. большая часть аудитории скептически относится к подобным сообщеиям.
Следующие две категории требуют содержания определенного количества организаций однодневок с целью распространения дезинформации и взятия ответственности на себя. Часто для таких организаций выбирают удобные юрисдикции.
С экспертами удобнее всего. Они высказывают только свое личное мнение, и за сказаное ими непосредственной ответственности СМИ не несет вообще, или эта ответственность ограничена. Требования к СМИ непосредственно на эксперта не распространяются. Любое уважающее себя СМИ имеет на быстром наборе экспертов на все случаи жизни.
Прошу не надо делать заключение, что все эксперты и организации врут и распространяют дезинформацию, а все сообщения в мессенджерах и соцсетях фэйки. Это далеко не так. Однако, следует всегда иметь ввиду, что непрямое распространение дезинформации с помощью этих инструментов через официальные СМИ возможно и используется.
Все мы уже наверно слышали про Fake News.

Агрегаторы


Давно уже прошли те времена, когда пользователи преимущественно получали информацию из единственного источника. Давно уже наступила эра различных агрегаторов, начиная с RSS, заканчивая сервисами вроде Гугл/Яндекс новости.
Крупные агрегаторы имеют широкую аудиторию и, при этом, исключительно цитируют чужие сообщения, неся ограниченную ответственность перед законом.
В следствии этого они являются лакомым куском для распрострнителей (дез)информации.
Т.к. агрегаторы практически всегда цитируют сообщения официальных СМИ, то, все методы применимые там, применимы и тут. Однако, существует дополнительное средство, которое гораздо более эффективно и применимо только к агрегаторам.
По аналогии с Fake News на официальных СМИ тут используются Fake Agencies.
Fake Agencies представляют собой стихийно созданные и, не обязательно, зарегистрированные СМИ-однодневки, которые во время проведения атаки стихийно или заранее регистрируются в агрегаторах и распространяют дезинформацию.
В свободное от распространения дезинформации время подобные Поддельные СМИ занимаются перепечатыванием (практически всегда автоматизированным) новостей с официальных каналов для создания видимости активной деятельности, и, своего штата сотрудников в принципе не имеют.
Часто, подобные СМИ делаются тематическими для придания большего веса в глазах читателя.

Рецепту блинов из журнала Мир кулинарии абстрактная домохозяйка будет доверять больше чем аналогичному из газеты Владивосток сегодня (названия изданий выдуманы, а совпадения случайны).

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

Социальные сети


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

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

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

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

Фэйковые аккаунты нет, это не просто единичные боты. Это миллионы и миллионы аккаунтов в социальных сетях которые выглядят совершенно живыми. Они ведут активную социальную жизнь. Благодаря автоматизированному копированию данных реально существующих аккаунтов в других/этих-же социальных сетях с небольшими изменениями, биографических данных. Имеют множество друзей из таких-же фэйков и реальных пользователей.
Многие хоть раз сталкивались с добавившимися к вам в друзья незнакомыми людьми, с которыми вы пообщались всего несколько раз в начале и забыли. Практически никто не удаляет таких друзей, т.к. чем больше у тебя друзей, тем лучше. Однако, владелец такого аккаунта записавшись к вам в друзья в ВФэйсбуке может используя вашу, немного измененную информацию содержать фэйковый аккаунт в Контакте (названия выдуманы, а совпадения случайны).

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

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

Ни в коем случае не стоит считать, что все это зло. Это лишь инструменты, которые могут использоваться как во зло, так и во благо. В том числе, для роспространения дезинформации, а потому попадают в сферу интересов государств.

Новомодные приложения


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

Способы контроля и противодействия


Профилактика


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

Другим способом профилактики является прямое распространение очевидной дезинформации не несущей непосредственного вреда государству. Используя те-же каналы, что могут использоваться для распространения (дез)информации противником, можно распространять не вредящую государству ложную информацию с последующим опровержением через официальные СМИ.
Регулярная работа с населением кардинально снижает доверие населения к подобным источникам информации и увеличивает доверие к официальным СМИ в собственной юрисдикции.
Кто не хочет учиться на чужих ошибках, будет учиться на своих.


Контр-воздействие


К этой категории относятся:
  • Распространение прямого опровержения (дез)информации.
  • Распространение информации о сомнительности источкка сообщения-(дез)информации.
  • Распространение множества сообщений снижающих (уничтожающих) репутацию источника.
  • Переключение внимания создание новой темы/потока сообщений с целью переключения внимание аудитории на более насущную проблему.
  • Создание информационного шума/тумана множества (в том числе ложных) сообщений на смежные темы и распространение их через каналы используемые противником, таким образом, что созданная противником (дез)информация теряется на этом фоне, а доверие к каналам окончательно утрачивается.

Часто меры используются в комплексе.

Ограничительные меры


Это та самая категория, которую мне хотелось бы сегодня обсудить. Сюда попадают как всевозможные технические блокировки, так и законодательные / судебные запреты и последствия.

Виды ограничительных мер


Хотелось бы разделить ограничительные меры на две категории:
  1. Активные ограничительные меры цензура, блокировки каналов распространения сайтов, мессенджеров, приложений, обязательное лицензирование СМИ.
  2. Пассивные ограничительные меры вам никто не мешает распространять информацию и даже специальные службы бережно сохранят все что вы распространяете как вещдоки, но, если что не так, ждите визита компетентных органов, судебные иски или счета на тысячи долларов. В эту категорию я отношу и ловушки (honeypot), позволяющие намерено провоцировать пользователей на распространение запрещенной/ложной информации (Правообладатели самостоятельно выкладывающие на торренты произведения с целью поиска тех кто скачал. Поддельные оппозиционные/экстремистские/тематические группы в социальных сетях.) с обязательным наступлением правовых последствий.


Ограничения и свободы


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

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

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

Так как же правильно блокировать T*******?


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

Итого, максимальная сумма штрафов/сборов, два-три мороженых в месяц с терминала.

Штрафовать надо того, на кого оформлен договор на доступ в интернет. К штрафу надо прилагать время, место, и логи на которых четко видно, когда и чем пользовались с его терминала доступа. Необходимо ввести технические средства предотвращения автоматизации оплаты данного штрафа, запретить провайдерам оплачивать штрафы за пользователей, а оплату принимать на государственных порталах вроде Российских Госуслуг с обязательной проверкой и вводом паспортных данных владельца терминала и КАПЧИ. При этом, данные должны совпадать с данными у провадера. Это не должно быть дорого. Это должно быть неудобно, и особенно неудобно для тех, кто пользуется чужим доступом в интернет.

К техническим средствам подлежащим ограничению необходимо отнести все запрещенные мессенджеры/приложения и все VPN сервисы/протоколы.

А как же публичные точки доступа и корпоративный VPN?


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

Это значит, что любой человек или организация должна быть способна такую лицензию себе позволить купить/оформить, и пользоваться мессенджерами и VPN свободно, без ограничений. Однако, необходимо делать это лично, а не через провайдера.

Экстренные меры противодействия


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

В качестве территориальной экстренной меры должна быть возможность блокировки всех терминалов имеющих подобную лицензию, работающих через любых провайдеров интернета, и, расположенных на определенной территории, с учетом типа терминала и заявленной цели его использования (частное лицо/организация, открытый/закрытый). Это рассматривается как более мягкая мера по сравнению с полной блокировкой доступа в сеть для всех, используемой сейчас.

Куда пойдут деньги?


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

Как это будет работать?


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

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

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

Будут частично решены проблемы финансирования ведомства и оборудования провайдеров соответствующими техническими средствами.

P.S.


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

Все это, исключительно мое субъективное мнение.

P.P.S.


Цитата в начале статьи часто встречается в сети совместно с указанием источника, однако, источник не подтвержден. Прошу воспринимать ее лишь как пример воздействия на аудиторию.

P.P.P.S.


К сожалению, благодаря резкой негативной реакции аудитории я потерял возможность отвечать на ваши коментарии, однако, спасибо пользователям вроде Wyrd за то, что хоть у кого-то есть чувство юмора :-).
По совету пользователя AngelNet перенес статью из хаба Законодательство в ИТ в хаб читальный зал, т.к. аудитория из первого явно воспринимает написанное слишком серьезно и лично :-)
Подробнее..

О твиттере бедном замолвите слово

10.03.2021 20:17:40 | Автор: admin

Попытка РКН замедлить связь с Twitter вылилась в локальные интернет-катаклизмы.

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

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

При этом, в это же время, даже через Ростелеком (по проводу) твиттер и сам открывается быстро, и видео с его CDN - тоже.

Однако, некоторые проведённые нами испытания показывают, что у некоторых провайдеров и вправду наблюдается картина резкого ограничения скорости скачивания, если в SNI был указан домен, в котором содержится (sic!) текстt.co. Именно содержится. Т.е. в выборку попадают и microsoft.com, и githubusercontent.com (домен, где эта соцсеть держит аватарки пользователей и всякую мелочь) и так далее. И воспроизводится это даже если отправлять запросы на IP собственного сервера (т.е. вовсе не обязательно - самого Twitterа).

Почему реализация такая топорная - огромный вопрос:

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

Другим кандидатом на эту роль является СОРМ-3, но если используется именно этот комплекс встаёт закономерный вопрос о том, почему средства оперативно-розыскных мероприятий вдруг используются для шейпинга трафика соцсетей.

Ну и третьим кандидатом является теория о локальных договорённостях с конкретными провайдерами (благо, крупных федеральных по сути, всего двое: Ростелеком и Эр-Телеком. Остальные или куплены одним из них, или слишком мелкие.

Ещё, забавным совпадением выглядит то, что совсем скоро после заявления РКН, внезапно упало большое количество сайтов государственных ведомств.

Скорее всего, это просто совпадение, но если взглянуть с теоретической точки зрения могли ли накосячить так, чтобы получился такой эффект, мой ответ как технического специалиста да, могли (тем более, что все, как обычно, всё отрицают). Правда, для этого нужно быть совсем уж двоечниками. Впрочем, смотря на то, что SNI-детектор цепляет сайты типа microsoft.com, сомнений остаётся всё меньше.

Но, как я сказал уже несколько раз, не имея никакой фактической информации, остаётся только фантазировать и спекулировать. Ну и, если хочется приплетать теории заговоров.

Например, тут вот, как раз где-то в это же время загорелся один из дата-центров OVH. Совпадение? :)

К слову, на самом деле, озвученное выше предложение - не настолько шутка, как может показаться с первого взгляда.

Масштабы поражения у OVH довольно большие: один дата-центр сгорел, часть второго повреждена, третий - в процессе борьбы между пожарными и огнём, и только четвёртый блок не тронут.

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

Подробнее..

Паттерн сага как способ обеспечения консистентности данных

18.09.2020 14:13:41 | Автор: admin
Всем привет. Уже сейчас в OTUS открывает набор в новую группу курса Highload Architect. В связи с этим я продолжаю серию своих публикаций, написанных специально для этого курса, а также приглашаю вас на свой бесплатный демо урок по теме: Индексы в MySQL: best practices и подводные камни. Записаться на вебинар можно тут.



Введение


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

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

Паттерн Сага


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

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

Типов транзакций в саге несколько, целых четыре:

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

Организовывать сагу можно с помощью хореографии или оркестрации.

В случае с хореографической саги выделенный оркестратор отсутствует. На примере сервиса заказов и пользователей она может выглядеть так: сервис заказов получает запрос и создает заказ в состоянии PENDING, а затем публикует событие Заказ создан. Обработчик событий в сервисе пользователей обрабатывает данное событие, пытается зарезервировать товар и публикует результат в виде события. Сервис заказов обрабывает данное событие, подтверждая или отменяя заказ в зависимости от прочитанного результата.

Сага с оркестрацией выглядит чуть более интересно. На примере указанных выше сервисов может получиться так: сервис заказов получает запрос, создает сагу, которая создает заказ в состоянии PENDING, а затем отправляет команду резервирования товара для сервиса пользователей. Сервис пользователей пытается зарезервировать товар и отправляет ответное сообщение с указанием результата. Сага одобряет или отменяет заказ.

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

Сага позволяет добиться ACD-модели (Atomicity + Consistency + Durability в терминах ACID), но одну букву мы потеряли. Недостаток буквы I приводит к известным проблемам недостатка изолированности. К ним относятся: потерянные обновления (lost updates) одна сага перезаписывает изменения, внесенные другой, не читая их при этом, грязное чтение (dirty reads) транзакция или сага читают незавершенные обновления другой саги, нечеткое/неповторяемое чтение (fuzzy/nonrepeatable reads) два разных этапа саги читают одни и те же данные, но получают разные результаты, потому что другая сага внесла изменения. Существует ряд паттернов, позволяющих пофиксить те или иные аномалии: семантическая блокировка, коммутативные обновления, пессимистическое представление, повторное чтение значения, файл изменений и по значению. Вопрос обеспечения изоляции остается открытым.

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

Заключение


Мы поговорили о способах организации саги с применением хореографии и оркестрации, а также о проблемах, которые влечет применения данного паттерна. Далее мы поговорим о способах исправления некоторых аномалий и транзакционной отправки сообщений в брокер сообщений.

Подробнее..

Redis на практических примерах

18.06.2020 10:17:09 | Автор: admin
Redis достаточно популярный инструмент, который из коробки поддерживает большое количество различных типов данных и методов работы с ними. Во многих проектах он используется в качестве кэшируещего слоя, но его возможности намного шире. Мы в ManyChat очень любим Redis и активно используем его в нашем продукте для решения огромного количества задач. Про некоторые интересные кейсы использования этой in-memory key-value базы данных я расскажу на примерах. Надеюсь, вам они будут полезны, и вы сможете применить что-то в своих проектах.

Рассмотрим следующие кейсы:
  • Кэширование данных (да, банально и скучно, но это классный инструмент для кэширования и обойти стороной этот кейс, кажется будет не правильно)
  • Работа с очередями на базе redis
  • Организация блокировок (mutex)
  • Делаем систему rate-limit
  • Pubsub делаем рассылки сообщений на клиенты

Буду работать с сырыми redis командами, чтобы не завязываться на какую-либо конкретную библиотеку, предоставляющую обертку над этими командами. Код буду писать на PHP с использованием ext-redis, но он здесь для наглядности, использовать представленные подходы можно в связке с любым другим языком программирования.



Кэширование данных


Давайте начнем с самого простого, один из самых популярных кейсов использования Redis кэширование данных. Будет полезно для тех, кто не работал с Redis. Для тех, кто уже давно пользуется этим инструментом можно смело переходить к следующему кейсу. Для того, чтобы снизить нагрузку на БД, иметь возможность запрашивать часто используемые данные максимально быстро, используется кэш. Redis это in-memory хранилище, то есть данные хранятся в оперативной памяти. Ещё это key-value хранилище, где доступ к данным по их ключу имеет сложность O(1) поэтому данные мы получаем очень быстро.

Получение данных из хранилища выглядит следующим образом:

public function getValueFromCache(string $key){    return $this->getRedis()->rawCommand('GET', $key);}

Но для того, чтобы данные из кэша получить, их нужно сначала туда положить. Простой пример записи:

public function setValueToCache(string $key, $value){    $this->getRedis()->rawCommand('SET', $key, $value);} 

Таким образом, мы запишем данные в Redis и сможем их считать по тому же самому ключу в любой нужный нам момент. Но если мы будем все время писать в Redis, данные в нем будут занимать все больше и больше места в оперативной памяти. Нам нужно удалять нерелевантные данные, контролировать это вручную достаточно проблематично, поэтому пускай redis занимается этим самостоятельно. Добавим к нашему ключу TTL (время жизни ключа):

public function setValueToCache(string $key, $value, int $ttl = 3600){    $this->getRedis()->rawCommand('SET', $key, $value, 'EX', $ttl);}

По истечении времени ttl (в секундах) данные по этому ключу будут автоматически удалены.

Как говорят, в программировании существует две самых сложных вещи: придумывание названий переменных и инвалидация кэша. Для того, чтобы принудительно удалить значение из Redis по ключу, достаточно выполнить следующую команду:

public function dropValueFromCache(string $key){    $this->getRedis()->rawCommand('DEL', $key);}


Также редис позволяет получить массив значений по списку ключей:

public function getValuesFromCache(array $keys){    return $this->getRedis()->rawCommand('MGET', ...$keys);}

И соответственно массовое удаление данных по массиву ключей:

public function dropValuesFromCache(array $keys){    $this->getRedis()->rawCommand('MDEL', ...$keys);}


Очереди


Используя имеющиеся в Redis структуры данных, мы можем запросто реализовать стандартные очереди FIFO или LIFO. Для этого используем структуру List и методы по работе с ней. Работа с очередями состоит из двух основных действий: отправить задачу в очередь, и взять задачу из очереди. Отправлять задачи в очередь мы можем из любой части системы. Получением задачи из очереди и ее обработкой обычно занимается выделенный процесс, который называется консьюмером (consumer).

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

public function pushToQueue(string $queueName, $payload){    $this->getRedis()->rawCommand('RPUSH', $queueName, serialize($payload));}

Тем самым мы добавим в конец листа с названием $queueName некий $payload, который может представлять из себя JSON для инициализации нужной нам бизнес логики (например данные по денежной транзакции, данные для инициализации отправки письма пользователю, etc.). Если же в нашем хранилище не существует листа с именем $queueName, он будет автоматически создан, и туда попадет первый элемент $payload.

Со стороны консьюмера нам необходимо обеспечить получение задач из очереди, это реализуется простой командой чтения из листа. Для реализации FIFO очереди мы используем чтение с обратной записи стороны (в нашем случае мы писали через RPUSH), то есть читать будем через LPOP:

public function popFromQueue(string $queueName){    return $this->getRedis()->rawCommand('LPOP', $queueName);}

Для реализации LIFO очереди, нам нужно будет читать лист с той же стороны, с которой мы в него пишем, то есть через RPOP.



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

class Consumer {    private string $queueName;    public function __construct(string $queueName)    {        $this->queueName = $queueName;    }    public function run()    {        while (true) { //Вычитываем в бесконечном цикле нашу очередь            $payload = $this->popFromQueue();            if ($payload === null) { //Если мы получили NULL, значит очередь пустая, сделаем небольшую паузу в ожидании новых сообщений                sleep(1);                continue;            }            //Если очередь не пустая и мы получили $payload, то запускаем обработку этого $payload            $this->process($payload);        }    }    private function popFromQueue()    {        return $this->getRedis()->rawCommand('LPOP', $this->queueName);    }}

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

public function getQueueLength(string $queueName){    return $this->getRedis()->rawCommand('LLEN', $queueName);}

Мы рассмотрели базовую реализацию простых очередей, но Redis позволяет строить более сложные очереди. Например, мы хотим знать о времени последней активности наших пользователей на сайте. Нам не важно знать это с точностью вплоть до секунды, приемлемая погрешность 3 минуты. Мы можем обновлять поле last_visit пользователя при каждом запросе на наш бэкенд от этого пользователя. Но если этих пользователей большое количество в онлайне 10,000 или 100,000? А если у нас еще и SPA, которое отправляет много асинхронных запросов? Если на каждый такой запрос обновлять поле в бд, мы получим большое количество тупых запросов к нашей БД. Эту задачу можно решать разными способами, один из вариантов это сделать некую отложенную очередь, в рамках которой мы будем схлопывать одинаковые задачи в одну в определенном промежутке времени. Здесь на помощь нам придет такая структура, как Sorted SET. Это взвешенное множество, каждый элемент которого имеет свой вес (score). А что если в качестве score мы будем использовать timestamp добавления элемента в этот sorted set? Тогда мы сможем организовать очередь, в которой можно будет откладывать некоторые события на определенное время. Для этого используем следующую функцию:

public function pushToDelayedQueue(string $queueName, $payload, int $delay = 180){    $this->getRedis()->rawCommand('ZADD', $queueName, 'NX', time() + $delay, serialize($payload))}

В такой схеме идентификатор пользователя, зашедшего на сайт, попадет в очередь $queueName и будет висеть там в течение 180 секунд. Все другие запросы в рамках этого времени будут также отправляться в эту очередь, но они не будут туда добавлены, так как идентификатор этого пользователя уже существует в этой очереди и продублирован он не будет (за это отвечает параметр 'NX'). Так мы отсекаем всю лишнюю нагрузку и каждый пользователь будет генерить не более одного запроса в 3 минуты на обновление поля last_visit.

Теперь возникает вопрос о том, как читать эту очередь. Если методы LPOP и RPOP для листа читают значение и удаляют его из листа атомарно (это значит, что одно и тоже значение не может быть взято несколькими консьюмерами), то sorted set такого метода из коробки не имеет. Мы можем сделать чтение и удаление элемента только двумя последовательными командами. Но мы можем выполнить эти команды атомарно, используя простой LUA скрипт!

public function popFromDelayedQueue(string $queueName){    $command = 'eval "        local val = redis.call(\'ZRANGEBYSCORE\', KEYS[1], 0, ARGV[1], \'LIMIT\', 0, 1)[1]        if val then            redis.call(\'ZREM\', KEYS[1], val)        end        return val"';    return $this->getRedis()->rawCommand($command, 1, $queueName, time());}

В этом LUA скрипте мы пытаемся получить первое значение с весом в диапазоне от 0 до текущего timestamp в переменную val с помощью команды ZRANGEBYSCORE, если нам удалось получить это значение, то удаляем его из sorted set командой ZREM и возвращаем само значение val. Все эти операции выполняются атомарно. Таким образом мы можем вычитывать нашу очередь в консьюмере, аналогично с примером очереди построенной на структуре LIST.

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

Блокировки (Mutex)


Mutex (блокировка) это механизм синхронизации доступа к shared ресурсу нескольких процессов, тем самым гарантируя, что только один процесс будет взаимодействовать с этим ресурсом в единицу времени. Этот механизм часто применяется в биллинге и других системах, где важно соблюдать потоковую безопасность (thread safety).

Для реализации mutex на базе Redis прекрасно подойдет стандартный метод SET с дополнительными параметрами:

public function lock(string $key, string $hash, int $ttl = 10): bool{    return (bool)$this->getRedis()->rawCommand('SET', $key, $hash, 'NX', 'EX', $ttl);}

где параметрами для установки mutex являются:
  • $key ключ идентифицирующий mutex;
  • $hash генерируем некую подпись, которая идентифицирует того, кто поставил mutex. Мы же не хотим, чтобы кто-то в другом месте случайно снял блокировку и вся наша логика рассыпалась.
  • $ttl время в секундах, которое мы отводим на блокировку (на тот случай, если что-то пойдет не так, например процесс, поставивший блокировку, по какой-то причине умер и не снял ее, чтобы это блокировка не висела бесконечно).


Основное отличие от метода SET, используемого в механизме кэширования это параметр NX, который говорит Redis о том, что значение, которое уже хранится в Redis по ключу $key, не будет записано повторно. В результате, если в Redis нет значения по ключу $key, туда произведется запись и в ответе мы получим 'OK', если значение по ключу уже есть в Redis, оно не будет туда добавлено (обновлено) и в ответе мы получим NULL. Результат метода lock(): bool, где true блокировка поставлена, false уже есть активная блокировка, создать новую невозможно.

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

public function tryLock(string $key, string $hash, int $timeout, int $ttl = 10): bool{    $startTime = microtime(true);    while (!this->lock($key, $hash, $ttl)) {        if ((microtime(true) - $startTime) > $timeout) {            return false; // не удалось взять shared ресурс под блокировку за указанный $timeout}usleep(500 * 1000) //ждем 500 миллисекунд до следующей попытки поставить блокировку    }    return true; //блокировка успешно поставлена}

Мы разобрались как ставить блокировку, теперь нам нужно научиться ее снимать. Для того, чтобы гарантировать снятие блокировки тем процессом, который ее установил, нам понадобится перед удалением значения из хранилища Redis, сверить хранимый хэш по этому ключу. Для того, чтобы сделать это атомарно, воспользуемся LUA скриптом:

public function releaseLock(string $key, string $hash): bool{    $command = 'eval "        if redis.call("GET",KEYS[1])==ARGV[1] then            return redis.call("DEL",KEYS[1])        else            return 0        end"';    return (bool) $this->getRedis()->rawCommand($command, 1, $key, $hash);}

Здесь мы пытаемся найти с помощью команды GET значение по ключу $key, если оно равно значению $hash, то удаляем его при помощи команды DEL, которая вернет нам количество удаленных ключей, если же значения по ключу $key не существует, или оно не равно значению $hash, то мы возвращаем 0, что значит блокировку снять не удалось. Базовый пример использования mutex:

class Billing {    public function charge(int $userId, int $amount){        $mutexName = sprintf('billing_%d', $userId);        $hash = sha1(sprintf('billing_%d_%d'), $userId, mt_rand()); //генерим некий хэш запущенного потока        if (!$this->tryLock($mutexName, $hash, 10)) { //пытаемся поставить блокировку в течение 10 секунд            throw new Exception('Не получилось поставить lock, shared ресурс занят');}        //lock получен, процессим бизнес-логику        $this->doSomeLogick();        //освобождаем shared ресурс, снимаем блокировку        $this->releaseLock($mutexName, $hash);}}


Rate limiter


Достаточно частая задача, когда мы хотим ограничить количество запросов к нашему апи. Например на один API endpoint от одного аккаунта мы хотим принимать не более 100 запросов в минуту. Эта задача легко решается с помощью нашего любимого Redis:

public function isLimitReached(string $method, int $userId, int $limit): bool{    $currentTime = time();    $timeWindow = $currentTime - ($currentTime % 60); //Так как наш rate limit имеет ограничение 100 запросов в минуту, //то округляем текущий timestamp до начала минуты  это будет частью нашего ключа,//по которому мы будем считать количество запросов    $key = sprintf('api_%s_%d_%d', $method, $userId, $timeWindow); //генерируем ключ для счетчика, соответственно каждую минуту он будет меняться исходя из $timeWindow    $count = $this->getRedis()->rawCommand('INCR', $key); //метод INCR увеличивает значение по указанному ключу, и возвращает новое значение. //Если ключа не существует, он будут инициализирован со значением 0 и после этого увеличен    if ($count > $limit) { //limit достигнут        return true;    }    return false;} 

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

class FooController {    public function actionBar()    {        if ($this->isLimitReached(__METHOD__, $this->getUserId(), 100)) {            throw new Exception('API method max limit reached');        }        $this->doSomeLogick();    }}


Pub/sub


Pub/sub интересный механизм, который позволяет, с одной стороны, подписаться на канал и получать сообщения из него, с другой стороны отправлять в этот канал сообщение, которое будет получено всеми подписчиками. Наверное у многих, кто работал с вебсокетами, возникла аналогия с этим механизмом, они действительно очень похожи. Механизм pub/sub не гарантирует доставки сообщений, он не гарантирует консистентности, поэтому не стоит его использовать в системах, для которых важны эти критерии. Однако рассмотрим этот механизм на практическом примере. Предположим, что у нас есть большое количество демонизированных команд, которыми мы хотим централизованно управлять. При инициализации нашей команды мы подписываемся на канал, через который будем получать сообщения с инструкциями. С другой стороны у нас есть управляющий скрипт, который отправляет сообщения с инструкциям в указанный канал. К сожалению, стандартный PHP работает в одном блокирующем потоке; для того, чтобы реализовать задуманное, используем ReactPHP и реализованный под него клиент Redis.

Подписка на канал:
class FooDaemon {    private $throttleParam = 10;    public function run()    {        $loop = React\EventLoop\Factory::create(); //инициализируем event-loop ReactPHP        $redisClient = $this->getRedis($loop); //инициализируем клиента Redis для ReactPHP        $redisClient->subscribe(__CLASS__); // подписываемся на нужный нам канал в Redis, в нашем примере название канала соответствует названию класса        $redisClient->on('message', static function($channel, $payload) { //слушаем события message, при возникновении такого события, получаем channel и payload            switch (true) { // Здесь может быть любая логика обработки сообщений, в качестве примера пускай будет так:                case \is_int($payload): //Если к нам пришло число  обновим параметр $throttleParam на полученное значение                    $this->throttleParam = $payload;                    break;                case $payload === 'exit': //Если к нам пришла команда 'exit'  завершим выполнение скрипта                    exit;                default: //Если пришло что-то другое, то просто залогируем это                    $this->log($payload);                    break;            }        });        $loop->addPeriodicTimer(0, function() {            $this->doSomeLogick(); // Здесь в бесконечном цикле может выполняться какая-то логика, например чтение задач из очереди и их процессинг        });        $loop->run(); //Запускаем наш event-loop    }}

Отправка сообщения в канал более простое действие, мы можем сделать это абсолютно из любого места системы одной командой:

public function publishMessage($channel, $message){    $this->getRedis()->publish($channel, $message);}

В результате такой отправки сообщения в канал, все клиенты, которые подписаны на данный канал, получат это сообщение.



Итог


Мы рассмотрели 5 примеров использования Redis на практике, надеюсь что каждый найдет для себя что-то интересное. В нашем стэке технологий Redis занимает важное место, мы любим этот инструмент за его скорость и гибкость. Мы используем Redis в продакшене уже много лет, и он зарекомендовал себя как очень крутой и надежный инструмент, который лежит в основе многих частей нашего продукта. Наш небольшой кластер Redis серверов обрабатывает около 1 миллиона запросов в секунду. А как вы используете Redis в своем проекте? Делитесь опытом в комментариях!
Подробнее..

Проблематика распределенных транзакций в контексте микросервисной архитектуры

27.08.2020 10:09:54 | Автор: admin
Всем привет. Уже в сентябре OTUS открывает набор в новую группу курса Highload Architect. В связи с этим я продолжаю серию своих публикаций, написанных специально для этого курса, а также приглашаю вас на свой бесплатный вебинар, в рамках которого я подробно расскажу о программе курса и формате обучения в OTUS. Записаться на вебинар можно тут.



Введение


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

Согласованность


Достаточно тонким моментом является то, что согласованность в контексте распределенных систем отличается от согласованности в контексте баз данных. Далее под согласованностью мы будем понимать именно первое: незавершенная (ошибочная) операция не вносит никаких эффектов и не меняет данные, при конкурентном доступе к данным все операции рассматриваются как атомарные (нельзя увидеть промежуточный результат операции), если у данных имеется несколько копий (репликация), то последовательность применения операций на всех копиях одна и та же. То есть на самом деле мы хотим получить ACID транзакцию, но только распределенную.

Причина проблемы


Почему обеспечение согласованности затруднено именно в микросервисной архитектуре? Дело в том, что данный архитектурный стиль зачастую предполагает применение паттерна database per service. Позволю себе напомнить, что этот паттерн заключается в том, что у каждого микросервиса своя независимая база или базы (базы, потому что помимо первичного источника данных может использоваться, например, кеш). Такой подход позволяет с одной стороны не добавлять неявные связи по формату данных между микросервисами (микросервисы взаимодействуют только явно через API), с другой стороны по максимуму использовать такое преимущество микросервисной архитектуры как technology agnostic (мы можем выбирать подходящую под особую нагрузку на микросервис технологию хранения данных). Но при всем при этом мы потеряли гарантию согласованности данных. Посудите сами, монолит общался с одной большой базой, которая предоставляла возможности по обеспечению ACID транзакций. Теперь баз данных стало много, а вместо одной большой ACID транзакции у нас много небольших ACID транзакций. Нашей задачей будет объединение всех этих транзакций в одну распределенную.

Оптимистичная согласованность


Первое что может прийти в голову это концепция оптимистичной согласованности: мы совершаем столько транзакций сколько хотим на столько механизмов хранения сколько нужно. При этом мы ждем, что все будет хорошо, а если все плохо, то говорим, что все будет хорошо в итоге. Если все плохо в итоге, то говорим: Да, такое случается, но с крайне низкой вероятностью.

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

Варианты обеспечения консистентности


Если для бизнеса все-таки согласованность является критичной, можно попытаться ее обеспечить несколькими способами. Если мы говорим о ситуации, когда данные обновляются одним сервисом (например имеет место репликация базы данных), то можно применить стандартные алгоритмы обеспечения консистентности такие как Paxos или Raft. Такие транзакции называются гомогенными. Если данные обновляются несколькими сервисами (то есть имеет место гетерогенная транзакция), то как тут как раз и начинаются сложности, о которых мы говорили выше.

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

Двухфазный коммит


Механизм предельно прост: есть некоторый transaction manager, который собственно оркестрирует транзакцию. На первом этапе (prepare) transaction manager подает соответствующую команду для resource manager'ов, по которой они в свои журналы записывают данные, которые будут закоммичены. Получив подтверждение ото всех resource manager'ов об успешном завершении первого этапа, transaction manager начинает второй этап и подает следующую команду (commit), по которой resource manager'ы применяют принятые ранее изменения.

Несмотря на кажущуюся простоту, такой подход обладает рядом недостатков. Во-первых, если хотя бы один resource manager даст сбой на втором этапе, вся транзакция должна быть отменена. Таким образом, нарушается один из принципов микросервисной архитектуры устойчивость к отказам (когда мы приходили к распределенной системе, мы сразу закладывались на то, что отказ в ней является нормой а не исключительной ситуацией). Более того, если отказов будет много (а их будет много), то процесс отмены транзакций необходимо будет автоматизировать (в том числе и писать транзакции, откатывающие транзакции). Во-вторых, сам transaction manager является единой точкой отказа. Он должен уметь транзакционно выдавать id-шники транзакциям. В-третьих, поскольку хранилищу подаются специальные команды, логично предположить, что хранилище должно уметь это делать, то есть соответствовать стандарту XA, а не все современные технологии ему соответствуют (такие брокеры как Kafka, RabbitMQ и NoSQL решения как MongoDB и Cassandra не поддерживают двухфазные коммиты).

Вывод, напрашивающийся из всех этих факторов, был отлично сформулирован Крисом Ричардсоном: 2PC not an option (двухфазный коммит не вариант).

Вывод


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



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




Читать ещё:


Подробнее..

DBA кто скрывается за блокировкой

15.06.2020 20:17:21 | Автор: admin
В предыдущей статье мы научились снимать состояние блокировок на сервере PostgreSQL ровно в тот момент, когда они происходят. В этой научимся трактовать собранное и узнавать, кто именно может скрываться за конкретной матрицей конфликтов, и почему результат выглядит именно так.



Сначала немного доработаем запрос из исходной статьи, чтобы он стал чуть удобнее и нагляднее, а вся самая важная для восприятия информация оказывалась в одном месте:

мегазапрос
WITH lm(ld, lr) AS (  VALUES    ('AccessShareLock', '{AccessExclusiveLock}'::text[])  , ('RowShareLock', '{ExclusiveLock,AccessExclusiveLock}'::text[])  , ('RowExclusiveLock', '{ShareLock,ShareRowExclusiveLock,ExclusiveLock,AccessExclusiveLock}'::text[])  , ('ShareUpdateExclusiveLock', '{ShareUpdateExclusiveLock,ShareLock,ShareRowExclusiveLock,ExclusiveLock,AccessExclusiveLock}'::text[])  , ('ShareLock', '{RowExclusiveLock,ShareUpdateExclusiveLock,ShareRowExclusiveLock,ExclusiveLock,AccessExclusiveLock}'::text[])  , ('ShareRowExclusiveLock', '{RowExclusiveLock,ShareUpdateExclusiveLock,ShareLock,ShareRowExclusiveLock,ExclusiveLock,AccessExclusiveLock}'::text[])  , ('ExclusiveLock', '{RowShareLock,RowExclusiveLock,ShareUpdateExclusiveLock,ShareLock,ShareRowExclusiveLock,ExclusiveLock,AccessExclusiveLock}'::text[])  , ('AccessExclusiveLock', '{AccessShareLock,RowShareLock,RowExclusiveLock,ShareUpdateExclusiveLock,ShareLock,ShareRowExclusiveLock,ExclusiveLock,AccessExclusiveLock}'::text[])), locks AS (  SELECT    (      locktype    , database    , relation    , page    , tuple    , virtualxid    , transactionid::text::bigint    , classid    , objid    , objsubid    ) target  , *  FROM    pg_locks), ld AS (  SELECT    *  FROM    locks  WHERE    NOT granted), lr AS (  SELECT    *  FROM    locks  WHERE    target::text = ANY(ARRAY(      SELECT DISTINCT        target::text      FROM        ld    )) AND    granted), lcx AS (  SELECT    lr.target  , ld.pid ldp  , ld.mode ldm  , lr.pid lrp  , lr.mode lrm  FROM    ld  JOIN    lr      ON lr.pid <> ld.pid AND        lr.target IS NOT DISTINCT FROM ld.target), cfl AS (SELECT  lc.locktype "type", CASE lc.locktype    WHEN 'relation' THEN      ARRAY[relation]    WHEN 'extend' THEN      ARRAY[relation]    WHEN 'page' THEN      ARRAY[relation, page]    WHEN 'tuple' THEN      ARRAY[relation, page, tuple]    WHEN 'transactionid' THEN      ARRAY[transactionid::text::oid]    WHEN 'virtualxid' THEN      string_to_array(virtualxid::text, '/')::oid[]    WHEN 'object' THEN      ARRAY[classid, objid, objsubid]    WHEN 'userlock' THEN      ARRAY[classid]    WHEN 'advisory' THEN      ARRAY[classid, objid, objsubid]  END target, nullif(lc.pid = lcx.ldp, FALSE) as locked, lc.pid, regexp_replace(lc.mode, 'Lock$', '') "mode", nullif(lc.granted, TRUE) "granted", nullif(lc.target IS NOT DISTINCT FROM lcx.target, FALSE) "conflict"FROM  lcxJOIN  locks lc    ON lc.pid IN (lcx.ldp, lcx.lrp))SELECT  cfl.*, CASE    WHEN "type" NOT IN ('virtualxid', 'transactionid') THEN target[1]::regclass  END relname, cl.relkindFROM  cflLEFT JOIN LATERAL(    SELECT      *    FROM      pg_class    WHERE      cfl.type = 'relation' AND      oid = target[1]    LIMIT 1  ) cl    ON TRUEORDER BY                                            -- сортируем ...  locked                                            -- сначала кого блокируют, pid                                               -- по принадлежности процессу (1 процесс = 1 транзакция), CASE "type"                                       -- по приоритету типов блокировок    WHEN 'virtualxid'    THEN 0    WHEN 'transactionid' THEN 1    WHEN 'relation'      THEN 2    WHEN 'tuple'         THEN 3    WHEN 'object'        THEN 4    WHEN 'advisory'      THEN 5  END, CASE relkind                                       -- по принадлежности объекта таблице    WHEN 'r' THEN cl.oid    WHEN 't' THEN regexp_replace(cl.relname, E'^.*\\D(\\d+)$', E'\\1', '')::oid    WHEN 'i' THEN (      SELECT        indrelid      FROM        pg_index      WHERE        indexrelid = cl.oid      LIMIT 1    )    WHEN 'S' THEN (      SELECT        (          SELECT            adrelid          FROM            pg_attrdef          WHERE            oid = dp.objid        )      FROM        pg_depend dp      WHERE        (refclassid, refobjid) = ('pg_class'::regclass, cl.oid) AND        (deptype, classid) = ('n', 'pg_attrdef'::regclass)      LIMIT 1    )  END  -- https://postgrespro.ru/docs/postgresql/12/catalog-pg-class, CASE relkind                                       -- по типу объекта БД    WHEN 'r' THEN 0 -- relation    WHEN 'm' THEN 1 -- materialized view    WHEN 'p' THEN 2 -- partitioned table    WHEN 'f' THEN 3 -- foreign table    WHEN 't' THEN 4 -- TOAST    WHEN 'i' THEN 5 -- index    WHEN 'I' THEN 6 -- partitioned index    WHEN 'S' THEN 7 -- sequence    WHEN 'c' THEN 8 -- composite type    WHEN 'v' THEN 9 -- view  END, CASE                                               -- по типу индекса  PK вперед    WHEN relkind = 'i' THEN      NOT (        SELECT          indisprimary        FROM          pg_index        WHERE          indexrelid = cl.oid        LIMIT 1      )  END, cl.relname                                         -- по имени объекта, CASE mode                                          -- по приоритету режима блокировки    WHEN 'AccessExclusive'      THEN 0    WHEN 'Exclusive'            THEN 1    WHEN 'ShareRowExclusive'    THEN 2    WHEN 'Share'                THEN 3    WHEN 'ShareUpdateExclusive' THEN 4    WHEN 'RowExclusive'         THEN 5    WHEN 'RowShare'             THEN 6    WHEN 'AccessShare'          THEN 7  END;


С помощью него мы рассмотрим некоторые примеры ситуаций, которые могут вам встретиться в реальной работе:

  1. создание одноименных таблиц
  2. создание одноименных индексов
  3. самоблокировка (CONCURRENTLY vs транзакция)
  4. блокировка по UNIQUE-индексу
  5. одновременное изменение записи
  6. обслуживание таблицы

Но сначала посмотрим, какие вообще ресурсы могут вызывать конфликт, и чем они идентифицируются в pg_locks:
locktype описание ID ресурса
relation отношение (таблица) (relation)
extend расширение отношения (TOAST) (relation)
page страница (блок данных таблицы/индекса) (relation, page)
tuple кортеж (запись таблицы/индекса) (relation, page, tuple)
transactionid идентификатор транзакции (transactionid)
virtualxid виртуальный идентификатор (virtualxid)
object некоторый объект (classid, objid, objsubid)
userlock пользовательская блокировка (classid)
advisory рекомендательная блокировка (classid, objid, objsubid)
В большинстве случаев в быту блокировки возникают, конечно же, на таблицах и их записях. Давайте посмотрим на конфликты режимов блокировок как на матрицу мешающих друг другу запросов:



А теперь посмотрим на реальных примерах.

Создание одноименных таблиц


-- tx1BEGIN;CREATE TABLE tbl(pk integer, val integer);    -- tx2    CREATE TABLE tbl(pk integer, val integer);

Профиль блокировок:
type mode relname relkind
ожидающий PID
relation RowExclusive pg_type r
relation RowExclusive pg_class r
object AccessShare pg_namespace
блокирующий PID
relation AccessExclusive oid таблицы (число)
object AccessShare pg_namespace
Таблица, как и любой именованный объект в PostgreSQL представлена как запись в таблице pg_class. Отличаются друг от друга записи объектов разных типов значением поля pg_class.relkind:
  • r = обычная таблица (Relation)
  • i = индекс (Index)
  • S = последовательность (Sequence)
  • t = таблица TOAST
  • v = представление (View)
  • m = материализованное представление (Materialized view)
  • c = составной тип (Composite type)
  • f = сторонняя таблица (Foreign table)
  • p = секционированная таблица (Partitioned table)
  • I = секционированный индекс (partitioned Index)

Но, поскольку запись с точки зрения нашей транзакции мониторинга еще не существует, раскастовка ее oid в regclass не может пройти, и мы видим вместо имени только лишь число.

Также помимо записи о самой таблице в метаданные (в pg_type) добавляется табличный тип, благодаря которому мы можем кастовать что-то прямо в формат записи таблицы:

SELECT NULL::tbl;

Пример состояния:



Создание одноименных индексов


-- tx1BEGIN;CREATE UNIQUE INDEX idx ON tbl(pk);    -- tx2    CREATE UNIQUE INDEX idx ON tbl(pk);

Профиль блокировок:
type mode relname relkind
ожидающий PID
relation RowExclusive pg_class r
relation Share tbl r
relation AccessExclusive oid индекса (число)
блокирующий PID
relation Share tbl r
relation AccessExclusive oid индекса (число)
Тут мы снова видим точно такую же RowExclusive-блокировку на pg_class, которая не дает создать одноименные объекты. Но уже никаких pg_type поскольку создание индекса не порождает никаких спецтипов. Вместо этого мы видим Share-блокировки, наложенные на обе таблицы (в нашем случае, она одна и та же).

Заметим, что Share между собой не конфликтуют, поэтому попробуем создать сразу два разных индекса на одной таблице:

-- tx1BEGIN;CREATE UNIQUE INDEX idx1 ON tbl(pk);    -- tx2    CREATE UNIQUE INDEX idx2 ON tbl(pk); -- работает, и никаких блокировок!

Пример состояния:



Самоблокировка (CONCURRENTLY vs транзакция)


Теперь давайте попробуем создать еще один индекс но не просто так, а CONCURRENTLY, чтобы никому не блокировать доступ к таблице.

Ну а если мы хотим сделать это из PL-кода, где CONCURRENTLY-запросы запускать нельзя, как и в любой транзакции?.. Конечно же, воспользуемся модулем dblink для подключения к этой же БД!

DO $$BEGIN  SELECT dblink_exec('dbname=' || current_database() || ' user=' || current_user, 'CREATE INDEX CONCURRENTLY idx_cic ON tbl(pk);');END$$;

Профиль блокировок:
type mode relname relkind
ожидающий PID
virtualxid Share ---
блокирующий PID
virtualxid Exclusive ---
Вот вам маленькая демонстрация, почему с dblink надо обращаться очень аккуратно. Здесь мы видим классическую ситуацию транзакция ждет транзакцию просто ее окончания. И не дождется никогда в нашем случае, поскольку сам DO-блок является транзакцией.

Пример состояния:



Блокировка по UNIQUE-индексу


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

-- tx1BEGIN;INSERT INTO tbl(pk, val)VALUES(1, 1);    -- tx2    INSERT INTO tbl(pk, val)VALUES(1, 1);

Профиль блокировок:
type mode relname relkind
ожидающий PID
relation RowExclusive tbl r
блокирующий PID
relation RowExclusive tbl r
relation RowExclusive idx i
Тут мы уже видим RowExclusive не на одной из системных таблиц, а на нашей. А в пару к ней и на том индексе, который вызвал проблемы [не]уникальности.

Пример состояния:



Одновременное изменение записи


Попробуем теперь одну и ту же запись в нашей таблице UPDATE'нуть:

-- tx1BEGIN;UPDATE tbl SET val = val + 1 WHERE pk = 1;    -- tx2    UPDATE tbl SET val = val + 1 WHERE pk = 1;

Профиль блокировок:
type mode relname relkind
ожидающий PID
tuple Exclusive tbl r
relation RowExclusive tbl r
блокирующий PID
relation RowExclusive tbl r
Понятно, что оба запроса наложили RowExclusive на таблицу, раз хотят туда что-то записать. Но важнее, что что заблокированный запрос ждет tuple-блокировку на этой же таблице. Причем последние два числа в ID объекта блокировки (или поля page, tuple в исходной pg_locks) позволяют нам узнать, что именно за запись мы тут ждем:

SELECT * FROM <relation> WHERE ctid = '(<page>,<tuple>)';

Пример состояния:



Обслуживание таблицы


Мы тут очень много чего в таблице уже намусорили давайте ее зачистим. Но запись-то пока в нее идет:

-- tx1BEGIN;INSERT INTO tbl(pk, val)VALUES(2, 2);    -- tx2    TRUNCATE TABLE tbl;

Профиль блокировок:
type mode relname relkind
ожидающий PID
relation AccessExclusive tbl r
блокирующий PID
relation RowExclusive tbl r
Собственно, мы видим, что заблокированный хочет AccessExclusive самый тяжелый режим, но не может получить из-за RowExclusive. Смотрим на картинку с таблицей конфликтов и понимаем, что это кто-то из {TRUNCATE, VACUUM FULL, ...} пересекся c {INSERT, UPDATE, DELETE}, даже не заглядывая в pg_stat_activity.

Пример состояния:



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

Картирование цифровых прав, часть IV. Право на доступ к Интернету

06.09.2020 12:06:19 | Автор: admin

TL;DR: Эксперты делятся видением проблем в России, связанными с цифровым правом на доступ к Интернету.

12 и 13 сентября Теплица социальных технологий и РосКомСвобода проводят хакатон по цифровому гражданству и цифровым правам demhack.ru. В преддверии мероприятия организаторы публикуют четвертую статью, посвященную картированию проблемного поля для того, чтобы программисты и активисты смогли найти для себя интересный вызов. Предыдущие статьи: по праву на публикацию цифровых произведений можно найти здесь (часть 1), на доступ к информации здесь (часть 2), на анонимность (часть 3) здесь.

Право на доступ к Интернету

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

В 2016-м году Совет по правам человека ООН принял резолюцию A/HRC/32/L.20, которая, к сожалению, не приравняла доступ к Интернету к базовым правам человека, как об этом писали некоторые СМИ, но зафиксировала ряд важных деклараций:

  1. те же самые права, которые человек имеет в офлайновой среде, должны также защищаться в онлайновой среде, в частности свобода выражения мнений, которая применима независимо от границ [].

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

Несмотря на то, что глобально право на интернет-доступ (пока) не включено в универсальную декларацию прав человека, часть стран (Коста-Рика, Эстония, Франция и др.) признает доступ в Интернет как право человека.

В России право на доступ к интернету следует из прав и свобод, описанных в статье 29 (даже несмотря на апдейт 2020).

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

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

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

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

Некоторые из обсуждавшихся сюжетов:

  1. Блокировки сайтов, протоколов, приложений;

  2. Локальные шатдауны;

  3. Неполитические вопросы доступа к Интернету (удаленность, экономические, демографические ограничения).

Сюжет 1. Блокировки сайтов, протоколов, приложений

Censor Tracker программное решение по обеспечению права на доступ к Интернету. Источник: http://personeltest.ru/aways/habr.com/ru/company/roskomsvoboda/blog/515132/ Censor Tracker программное решение по обеспечению права на доступ к Интернету. Источник: http://personeltest.ru/aways/habr.com/ru/company/roskomsvoboda/blog/515132/

В рамках круглых столов к праву на доступ к Интернету мы отнесли и доступность отдельных сайтов, как элементов Интернета, хотя доступ к сайтам, сервисам и порталам также относится и к целому ряду других цифровых прав.

Проблема 1.1.: Сложно определить, заблокирован ли сайт или просто не работает. Следовательно, сложно доказать, что сайт заблокировали, а не то, что у админа лапки.

Вариант решения на хакатоне: инструмент, который подтверждал или каким-то образом предполагал бы гипотезу о причине неработоспособности того или иного сайта. Частично, информацию о блокировках в России, предоставляет отличнейший плагин РосКомСвободы. Но на данный момент плагин обращается только к списку заблокированных сайтов, в то время как блокировки могут происходить не только официально. А еще могут быть DDOSы и другие неприятные истории. Достаточно взглянуть на то, что происходит в одной соседней стране.

Проблема 1.2.: проблема доведения до сведения общественности факта блокировки. Нет инструкции действий при блокировке.

Варианты решения на хакатоне:

  1. сайт, который позволяет промониторить и дать инструкции, с шаблонами жалоб на блокировку.

  2. маркетплейс для юридических фирм, которые бы обжаловали блокировки и фандрейзинг на поддержку юристов.

Проблема 1.3.: Проблема восстановления доступности. Ок, заблокировали и что дальше? Часто админы не знают, что делать после блокировки.

Проблема 1.4.: Проблема возможного скрытия объема блокировок. В какой-то момент блокировки могут попытаться законодательно скрыть. Другими словами, может произойти снижение государственной транспарентности в области ограничения информации.

Варианты решений на хакатоне:

  1. найти способы визуализировать проблему с блокировками.

  2. сделать реестр запрещенных сайтов распределенным.

Проблема 1.5.: неоднородность блокировок у разных провайдеров. У разных провайдеров разные технологии. Сюда же относится и т.н. проблема переблокировок когда сайт недоступен, но уже должен быть доступен.

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

Сюжет 2. Локальные шатдауны

Подпись к твиту: Минск плавно исчезает с радаров. Источник: NetBlocks.

Шатдаун (англ. отключение) временное отключение Интернета на ограниченной территории. Шатдауны незаконны и приносят прямые экономические убытки, а также напрямую нарушают гражданские права и свободы.

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

Варианты решений на хакатоне:

  1. разработка методики мониторинга и фиксации шатдаунов;

  2. использование ИИ в маршрутизации пакетов (адаптивные протоколы по передаче данных);

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

Проблема 2.2.: отсутствия информации о том, что делать во время шатдауна пользователям.

Варианты решения на хакатоне:

  1. Использование Mesh-сетей (интернет-коммуны)

  2. Использование альтернативных методов подъема сетей.

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

Сюжет 3. Неполитические вопросы доступа к Интернету (удаленность, экономические, демографические ограничения)

Поколенческий цифровой разрыв. Источник: опрос ФОМ, май 2020. Ссылка: https://fom.ru/SMI-i-internet/14402Поколенческий цифровой разрыв. Источник: опрос ФОМ, май 2020. Ссылка: https://fom.ru/SMI-i-internet/14402

Проблема 3.1.: Высокая дифференциация по уровню доступа к Интернету в России.

Проблема 3.2.: Люди не представляют, что качество доступа в интернет может влиять на их другие права. Низкий уровень грамотности.

Варианты решений для 3.1. и 3.2.: просветительские проекты, онлайн-оффлайн кампании по просвещению о том, что доступ в интернет гражданское право.

Проблема 3.3.: Не хватает исследований, как именно люди пользуются интернетом, как интернет влияет на экономику, как качество интернета влияет на экономический рост, как шатдауны влияют на экономику. Нет изучения условий доступа к интернету в России.

Вариант решения на перспективу: создать исследование о российских пользователях интернета.

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

Теплица социальных технологий и РосКомСвобода благодарят всех экспертов, принявших участие в круглом столе. Зарегистрироваться на хакатон цифрового гражданства и цифровых прав demhack.ru можно до 8-го сентября 2020 г.

Подробнее..

Настройка BGP для обхода блокировок, версия 3.1. И немного QampA

05.04.2021 22:14:08 | Автор: admin

Близится кожаная свадьба Роскомнадзора с Телеграмом, 16 апреля 2018 года начался крестовый поход, ставший фактически символом уничтожения интернета в России, хотя в глобальной войне, начавшейся в 2012 году, он был всего лишь ярким эпизодом.

Ковровые блокировки в исполнении РКН стали причиной появления на свет множества различных сервисов, помогающих пользователям сети выживать под бомбежками. Одним из них стал antifilter.download, позволяющий получать списки находящихся под блокировками IP-адресов. Далее пользователи сервиса могли использовать полученную информацию по своему усмотрению. Вариант усмотрений был описан в статье Настройка BGP для обхода блокировок, версия 3, без VPS, которая стала достаточно популярной в сети и породила несколько сотен пользователей сервиса.

Однако "Tempora mutantur et nos mutamur in illis". За прошедшие три года сервис пережил Alpharacks-gate, похоронивший вместе с собой практически все донаты, упирание в технические ограничения как следствие роста количества пользователей, упирание в те же ограничения как следствие взрывного роста количества ip-адресов в списке РКН... Да что только не пережил. Каждое из этих изменений приводило к небольшому устареванию предыдущей статьи и когда неделю назад один из хабраюзеров предложил мне поправить ее под текущие реалии, я понял, что проще родить нового, чем отмыть этого написать новую версию, заодно и ответив на часто задаваемые вопросы. Результат - ниже.


Зачем это всё

Выполнив описанные ниже действия на своем маршрутизаторе Mikrotik, вы сможете автоматически получать через уже имеющийся у вас VPN доступ к ресурсам, ip-адреса которых занесены в "Единый реестр доменных имен, указателей страниц сайтов в сети Интернет и сетевых адресов, позволяющих идентифицировать сайты в сети Интернет, содержащие информацию, распространение которой в Российской Федерации запрещено".

Мы используем протокол BGP для доставки списка IP-префиксов из "Единого реестра" на ваш маршрутизатор и дальнейшего перенаправления трафика к этим префиксам в VPN-туннель. Здесь и далее под общим термином IP подразумевается IPv4, IPv6-адреса сервисом не обрабатываются.

Если ваш маршрутизатор не Mikrotik, но умеет протокол BGP, вы, скорее всего, сможете использовать этот сервис, адаптировав настройки под своё оборудование. Вариант для Keenetic, например, приведен в полезных ссылках в конце статьи.

Что нужно для использования

  1. Маршрутизатор Mikrotik

  2. подключенный к интернету

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

Как настроить

Команды, приведенные в цитатах, необходимо выполнять в окне терминала Mikrotik. В целом никто не запрещает настраивать это всё и в Winbox, но разбирать, какие параметры в какое поле Winbox вводить, вам придется самостоятельно.

Предварительные ласки

Проверяем наш VPN. Крайне важно, чтобы он работал еще до внедрения сервиса.
Наиболее простым способом проверки будет посещение любого сайта, который показывает ваш внешний IP-адрес (например, 2ip.ru), с включенным и выключенным VPN и фиксированием факта, что отображаемый ip-адрес меняется.

Тут у нас лежит первая и частая засада. Очень часто люди с неэкспертной квалификацией настраивают подключение к VPN по шаблону из интернета с использованием routing mark, особенно когда параллельно используют multiWAN схему. В принципе, ничто не запрещает использовать BGP-префиксы и в такой конфигурации, но ее нужно тщательно продумывать и подстраивать под текущие настройки, что в статье "в общем" не описать. Так что в дальнейшем подразумевается, что вы используете только классическую маршрутизацию по префиксам.

Если у вас сильно зажаты правила файрвола, возможно вам потребуется создать отдельное правило для выпуска трафика BGP с маршрутизатора.

/ip firewall filter add action=accept chain=output protocol=tcp dst-address=163.172.210.8 dst-port=179 out-interface=gre-tunnel1

На место gre-tunnel1 нужно подставить имя вашего интерфейса VPN-туннеля.

Укрепи и направь

Прописываем маршрут до сервиса antifilter.download через ваш VPN. Это действие нам поможет от случая, когда где-то на пути какой-то из провайдеров фильтрует BGP (на удивление, таких в России достаточно много).

/ip route add dst-address=163.172.210.8/32 gateway=gre-tunnel1

На место gre-tunnel1 нужно подставить имя вашего интерфейса VPN-туннеля.

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

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

Глубокое проникновение

Настраиваем пиринг с сервисом.

/routing bgp instance set default as=64512 ignore-as-path-len=yes router-id=81.117.103.94 /routing bgp peer add hold-time=4m in-filter=bgp_in keepalive-time=1m multihop=yes name=antifilter remote-address=163.172.210.8 remote-as=65432 ttl=default
/routing filter add action=accept chain=bgp_in comment="Set nexthop to VPN" set-in-nexthop-direct=gre-tunnel1

Первой командой мы создаем процесс BGP на вашем устройстве. В ней:

  • 64512 - 16-битный номер автономной системы. Заменяем на любой по вашему желанию, кроме ASN сервиса (65432). В нашем конкретном случае нам не важно, какой там будет указан номер в диапазоне от 1 до 65534, но если делать все правильно - RFC6996 говорит нам, что для частного использования выделен диапазон 64512-65543.

  • 81.117.103.94 - router ID (32 бита) в формате IPv4-адреса. В общем случае нам, опять же, не важно, какой там будет указан ID, но чтобы уменьшить вероятность пересечения с другим пользователем - лучше использовать ваш текущий внешний IP-адрес (посмотрев его на том же 2ip.ru). При его изменении менять router ID совершенно не обязательно.

Второй командой мы создаем BGP соединение с сервисом antifilter.download. В ней ничего менять не надо.

Третьей командой мы указываем, что для всех маршрутов, полученных от сервиса, нужно установить в качестве next-hop интерфейс нашего VPN. В ней на место gre-tunnel1 нужно подставить имя вашего интерфейса VPN-туннеля.

... и обоюдный оргазм

Если всё настроено правильно - через несколько десятков секунд, в течение которых процессор маршрутизатора будет на 100% загружен обработкой списка полученных префиксов, все заработает и трафик до полученных IP-адресов будет отправляться в VPN.

То, что пиринг поднялся, можно посмотреть по пути Routing - BGP - Peers в Winbox:

State должен быть Established, а в поле Count - отличное от нуля количество полученных префиксов.

Также характерным признаком того, что префиксы получены, является следующая картинка по пути IP - Routes в Winbox:

По клику где указано можно раскрыть весь список полученных префиксов и увидеть что-то вроде:

Важно, чтобы в поле Gateway было указано имя вашего интерфейса VPN и слово reachable (Distance при этом у вас будет другим, это нормально).

Если что-то не работает - проверьте прежде всего доступность сервиса. Сервер откликается на пинг, так что команда ping antifilter.download вполне себе покажет, все ли хорошо со связностью. Если пинг проходит - проверьте соответствие IP-адреса в пинге 163.172.210.8, потому что вы вполне можете читать эту статью в момент, когда сервис уже куда-то мигрировал.

Далее перепроверьте настройки и прочитайте Q&A ниже. А потом спросите в комментариях здесь или на канале MikrotikRus, там я тоже иногда поддерживаю решение, да и кроме меня там очень много грамотных людей.

А поговорить? (Q&A)

  • Решение перекрывает не все проблемы с блокировками

    • Конечно нет. Нужно понимать, что поскольку действие (блокировка) лежит фактически на 7 уровне модели ISO/OSI, то и противодействие (обход блокировки) наиболее эффективно работает на том же уровне модели. Сервис же предоставляет возможность борьбы на 3 уровне модели, что автоматически означает неидеальное совпадение. Если хочется более точного варианта - плагин для браузера, автоматически отправляющий некоторые сайты через прокси-сервер (например, SwitchyOmega для Chrome), будет работать гораздо лучше.

  • Я всё настроил, а мой любимый ресурс все равно блокируется. При этом подходящего префикса для его адреса в списке нет

    • Вероятно, РКН внес другой IP-адрес ресурса в реестр. Список IP-адресов генерируется полностью автоматически и не может редактироваться со стороны сервиса под каждый отдельный кейс вручную. Самое простое решение - прописать до любимого ресурса статический маршрут в VPN на маршрутизаторе.

  • Я всё настроил, а мой любимый ресурс все равно блокируется. При этом подходящий префикс для его адреса в списке есть, но nslookup выдает другой адрес из сети моего провайдера

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

  • После включения сервиса в VPN отправляется трафик на IP-адреса, отсутствующие в реестре. Дефолт в VPN я отключить не забыл

    • Вероятно, в реестре есть IP-адрес из той же IP-подсети /24. По BGP сервис отдает только суммаризованные вверх префиксы /24 (т.е. даже если в реестре есть только адрес 1.2.3.4 - вы получите префикс 1.2.3.0/24, перекрывающий весь диапазон от 1.2.3.0 до 1.2.3.255).
      Вы всегда можете исправить эту ситуацию для себя и конкретных адресов, прописав маршрут на них через провайдера в вашем роутере статически (статика по умолчанию побеждает динамику).

  • Раньше сервис можно было настроить для получения отдельных IP-адресов (по /32). Как получать их сейчас?

    • К сожалению, сервис банально уперся в проблему масштабирования. После появления нескольких сотен пользователей и заполнения реестра в отдельные моменты более чем 2 миллионами префиксов схождение BGP-процесса сервиса могло занимать десятки минут, со всеми вытекающими в виде разрыва сессий по таймауту. Many Bothans died to... Многие оптимизации были сделаны в попытках решить эту проблему, включая миграцию с VPS на выделенный сервер, разделения на фронт- и бэкенды и т.п., но кардинально проблема была решена только отказом от раздачи по BGP списка отдельных IP-адресов.

      Если вам необходим список отдельных адресов, вы можете получать их с сайта по HTTPS и далее внедрять в свое решение, например, как описано в статье Настройка BGP для обхода блокировок, или Как я перестал бояться и полюбил РКН. Мало того, с сайта доступно гораздо больше разных списков, в том числе и в формате Mikrotik Address List, что позволяет более гибко использовать решение.

  • РКН замедляет Twitter, решение может помочь?

    • По сути - нет, потому что все эти замедления не отражаются в реестре (хотя законность такого действия спорна, но who cares). Для замедления используются ресурсы расставленных у операторов связи ТСПУ (DPI от компании RDP.RU), управление которыми идет централизованно и закрыто от постороннего взгляда. И высока вероятность, что в недалеком будущем вся фильтрация уйдет в эту сторону и реестр перестанет быть источником данных для нас.

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

  • У меня есть вопрос, ответа на который нет в Q&A

    • Задайте его в комментариях к статье. Постараюсь ответить на все там же, а если вопрос будет интересен большому числу читателей - добавлю в Q&A.

Заключение

Предполагаю, что реестр как источник IP-префиксов для обхода блокировок исчерпает себя в начале-середине 2022 года, поэтому вряд ли эта статья потребует новой версии, скорее просто уйдет в архив как неработающее решение.

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

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

Полезные ссылки

  • Прежде всего статья Настройка BGP для обхода блокировок, или Как я перестал бояться и полюбил РКН - она была наиболее полной и подробно описывающей логику решения. Если вам хочется более глубоко погрузиться в концепцию - эта статья практически идеальна (разве что сейчас уже имеет смысл внедрять это на bird v2, с соответствующей коррекцией конфигураций решения). И еще более полезны комментарии к ней.

  • Если вам интересно более глубоко понять, что такое и с чем едят BGP в частности и сетевые технологии вообще - не могу не порекомендовать "Сети для самых маленьких" от проекта LinkMeUp

  • Если вам хочется решение на Address List - NeoBeZопубликовал короткий скрипт для выгрузки нужного с сервиса. Не забудьте, что потом по этому листу нужно реализовать набор правил для перенаправления трафика.

  • Для роутеров Keenetic есть решение от Александра Рыжова. Оно, конечно, базируется на старой версии сервиса, но легко корректируется под новую.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru