Аэродинамика из блендера

Зачем (затем, что нужно кормить баллистическую модель)

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

Есть несколько способов получить эти цифры:

  1. CFD. Всякие ANSYS, floEFD, solidWorks flow simulation и так далее. Большие и серьезные программные пакеты с серьезным ценником. И для стартапа, пилящего свой шаттл в гараже, такой софт обойдется приблизительно во столько же, во сколько и сам гараж.

  2. Приближенные графоаналитические методы. Потому что люди уже давно запускают в воздух и вакуум самые разные девайсы. Данные по их обтеканию в трубах и свободном потоке занесены в справочники, табулированы и параметризованы по удлинениям, углам стреловидности, толщинам профилей и так далее и тому подобное. Проблема таких подходов — в необходимости «на глаз» работать с различными книгами и атласами характеристик, переносить цифры с бумаги в электронный вид и страдать, страдать, страдать, когда геометрия приобретает формы, отличные от «цилиндроконический корпус с тонким крылом»

  3. Приближенные методы на базе локальных параметров обтекания. Занимают промежуточное положение между первыми двумя и основаны на разбиении геометрии исследуемого ЛА на фрагменты, взаимодействием между которыми можно пренебречь. Поскольку возмущения в потоке не могут распространяться быстрее скорости звука и за пределы скачков уплотнения, то подобные методы лучше всего работают на больших скоростях (M ~ 8-10 и выше). Ими мы и займемся

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

Н.Ф. Краснов. Аэродинамика. том 1. Тэта - угол отклонения скачка, бэта - угол наклона поверхности, создающей скачок, дельта - параметр, зависящий от показателя адиабаты. Решив это уравнение методом Ньютона, получим необходимый нам угол скачка и параметры преобразования потока.
Н.Ф. Краснов. Аэродинамика. том 1. Тэта — угол отклонения скачка, бэта — угол наклона поверхности, создающей скачок, дельта — параметр, зависящий от показателя адиабаты. Решив это уравнение методом Ньютона, получим необходимый нам угол скачка и параметры преобразования потока.

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

Основы метода Ньютона. Н.С. Аржаников, Г.С. Садекова. "Аэродинамика летательных аппаратов"
Основы метода Ньютона. Н.С. Аржаников, Г.С. Садекова. «Аэродинамика летательных аппаратов»

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

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

Оценка трения эквивалентной пластины по критерию Рейнольдса
Оценка трения эквивалентной пластины по критерию Рейнольдса

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

Все превратится в треугольники

Теперь нужно получить данные о геометрии ЛА. Есть множество форматов, но самым удобным кажется STL. Каждая запись исчерпывающе описывает элементарную площадку на поверхности тела через три точки, которые ее формируют, и ориентированный вектор нормали. А еще Blender, которым я достаточно сносно владею, умеет экспортировать в него модели. Однако есть нюанс — STL, создаваемый Blender-ом — это бинарный файл, чтение которого немного отличается от работы с привычными текстовыми файлами (csv, json и так далее). Но для таких оказий в NodeJS есть класс Buffer. А сам бинарный STL снабжен подробной документацией.

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

Это код работы с STL
Ничего особенного, просто каждый раз сползаем еще на 50 байтов вправо
Ничего особенного, просто каждый раз сползаем еще на 50 байтов вправо

Дальнейшие действия определяются спецификацией бинарного STL. Первые 80 байтов — это заголовок со сведениями о программе, в которой был создан бинарник. Их можно пропустить. Следующие 4 байта критичны — это 32-разрядный Unsigned Int, хранящий количество треугольников в составе модели. Как только мы узнали количество треугольников — начнем их считывать.

Каждый треугольник состоит из идущий подряд 32-разрядных Float Little Endian. Первые три числа — приведенная к единичному вектору нормаль. Затем тройки точек (X, Y, Z), задающих плоскость. После 48 значащих байтов идет еще 2 байта с 16-разрядным Unsigned Int, который некоторые редакторы используют для сохранения цвета поверхности. Но для расчета обтекания цвет нам явно не потребуется.

Тест 1. Притупленное тело

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

Это модель
Это - тестовая модель. Направление потока - справа налево
Это — тестовая модель. Направление потока — справа налево

На качественном уровне поведение коэффициентов нормальной и продольной силы совпадает с теоретическим расчетом. На количественном уровне есть расхождение в 5-10% относительно теории:

Теория и модель
Сплошные линии - расчетные значения, точки - теоретический расчет
Сплошные линии — расчетные значения, точки — теоретический расчет
Исходные данные для запуска расчета. Все еще "Аэродинамика..." Аржаникова и Садековой
Исходные данные для запуска расчета. Все еще «Аэродинамика…» Аржаникова и Садековой

Тест 2. Аполлон

Следующий шаг — «Аполлон». Сравним аэродинамическое качество из статьи DSMC Simulations of Apollo Capsule Aerodynamics… (которой я пользовался в посте про капсульные корабли) с модельным.

Аэродинамика «Аполлона»
Линия - модельный расчет, сквозные точки - данные из статьи AIAA
Линия — модельный расчет, сквозные точки — данные из статьи AIAA
Интересующий нас график - черный, для сплошной среды. Точки взяты с него
Интересующий нас график — черный, для сплошной среды. Точки взяты с него

График качества с высоты 85 км (где в полной мере применимы методы сплошной среды) с модельным расчетом. Как и в предыдущем случае, видна уверенная сходимость со средней погрешностью в ~5%. Кстати, обратим внимание на красный и синий графики качества из статьи AIAA — аэродинамическое качество для разреженных потоков быстро уменьшается.

Тест 3. Крыло с тонким профилем

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

Расчет в диапазоне скоростей M = 2 — 6 (коэффициент подъемной силы от угла атаки)
Красный график - теория тонкого профиля, синий - модельный расчет
Красный график — теория тонкого профиля, синий — модельный расчет

Первый график — Мах 2, второй — Мах 4, третий — Мах 6. Угол атаки — в градусах

По предварительным оценкам, полученная модель лучше всего подходит для определения характеристик КА при скоростях M > 3,5 — 4 и для высот до ~ 90 км. Однако расчет показывает хорошую сходимость начиная с M=4, а полученные цифры аэродинамического качества хорошо коррелируют с «барьером Кюхемана» .

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

А теперь — немного хулиганства (и спойлер к циклу следующих статей). Кажется, я начинаю понимать, как нам одолеть Илона Маска. И это — нулевой шаг к захвату мира.

Девайс для захвата мира, если что - то аэродинамическое качество пепелаца порядка 2,7 - 3,5. Ну и мне нравится "Скайлон" как прототип, но мы обойдемся без теплообменников
Девайс для захвата мира, если что — то аэродинамическое качество пепелаца порядка 2,7 — 3,5. Ну и мне нравится «Скайлон» как прототип, но мы обойдемся без теплообменников

А пока у меня появился инструмент, позволяющий оценивать характеристики самых разных пепелацев, причем в наиболее интересном с точки зрения атмосферного полета космических аппаратов коридоре высот и скоростей — с достаточно хорошей (~5%) точностью.

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

ссылка на оригинал статьи https://habr.com/ru/post/552980/

Архитектура архитектуры. Шаг 5: один за всех и все на одного

Продолжение. К предыдущим постам и карте цикла.

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

Unus pro omnibus, omnes pro uno
Unus pro omnibus, omnes pro uno

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

Agile development concept
Agile development concept

Если бы архитектору дома сказали, что клиенту хватит палатки или может в крайнем случае бытовки, а через год попросили добавить 3 этажа, то он бы, наверное, удивился. Еще сильней он бы удивился, когда еще через год ему добавили требование лифта, еще 5-ти этажей и бассейна на крыше. А чтобы он думал и делал, когда за пару месяцев до сдачи проекта ему сказали, что там еще подземная парковка на 100 машин должна быть – я уж и не знаю. А вот в программной разработке – это всё обычное дело. У нас ведь все такие гибкие и топят за адаптивность, а не выстрелы на опережение (особенно если они уже дорогие, но еще не обоснованные). И если вы просто будете апеллировать к методологии, которая подразумевает не только инкрементальность разработки, но и постоянное корректирование уже созданного, то ваша карьера будет яркой, но не долгой.

Да, сюрприза не получилось. Если не планировать вещи заранее, то всё выходит криво и надо постоянно перестраивать. С одной стороны, никто не хочет тратить год на документацию и детальный план разработки продукта, ведь все мы живём в реальном мире и достаточно хорошо понимаем, что изменения неизбежны и нельзя предусмотреть всё. С другой, очевидно, что если просто бежать, не зная дороги и цели, то шанс в конечном счете оказаться там, где нужно и когда ожидают – ничтожно мал. Так что для начала нужно точно определить, где мы (точку А), и куда должны попасть (точку Б). Слава богу на этапе начала разработки вы уже прошли несколько шагов в нужном направлении и примерно представляем цель и длину маршрута.

Architecture on feature map
Architecture on feature map

Возвращаясь к первой статье цикла, ещё раз озвучу своё мнение о назначении архитектуры. Это оптимальный путь решения задач бизнеса. При выборе паттернов проектирования, методологии работы, технологий и фреймворков, мы всегда получаем набор функций и решений, которые работают из коробки и набор ограничений из табакерки. Ещё до финальной подписи в контракте на души разработчиков, вы должны были перепроверить всё, что заявлено. Значит основная парадигма у нас есть. Что-то типа: микросервисы в облаке с разбивкой по DDD с локальным клиентом на Java. Полезность правила измеряется количеством исключений. Так что чем меньше перекосов в сторону монолита на клиенте или костылей вокруг облака – тем лучше. Тут никакого откровения нет. Но, всё же не хочется быть автором ещё одной пустой статьи из серии «мы в компании Х решили всё сделать по У и у нас всё получилось». Ведь я-то как раз и хотел в статьях показать путь, которым приходят к выбору У и как даётся тот самый success story.

Как вы, возможно, читали ранее – выбор часто делают за вас. Технологии — из того, что знает команда, методология тоже какая уж есть в вашей корпорации, провайдеры и стандарты обычно определяются заказчиком как одно из требований тендера. Вам же достаётся игра в Counter Strike. Пытаетесь обезвредить бомбы, которые уже заложены. Особенности работы с большими предприятиями я уже описывал. Так что сам по себе пазл не сложится. Облако и микросервисы – стандарт де-факто и, почти наверняка, вас не миновала чаша сия. Такие системы всегда обладают атрибутами AP. Значит стоит определить какие узлы требуют CA.

Энтерпрайз системы в основном рассчитаны на использование сотрудниками компании для автоматизации процессов. Зачастую процессы критические и производственные. Значит нужно чётко понимать, что должно работать вне облака. Почтовое отделение, заводик или магазин должны продолжать обслуживать даже, когда облако не доступно (это не облако упало, а ваш клиент потерял соединение). И данные на месте нужны актуальные (тот самый СА вариант). Если мы возьмём за пример систему управления логистикой, где у нас есть куча грузовиков развозящих товары по дорогам страны, то понятно, что никакие изменения данных в облачном диспетчере не изменят содержимое кузова. Ну и совсем не хочется, чтоб этот грузовик простаивал, если у него нет связи с сетью. Значит его локальная система должна иметь возможность учёта товара, просмотра маршрута и управления исключениями, без которых в реальной жизни никак. Глаз в облаке будет довольствоваться данными последней синхронизации и предполагаемым прогрессом (эвристикой текущего состояния). Заявленные микросервисы на планшет водителя устанавливать видимо тоже не стоит. Они уместны в центре управления, высоко в облаках, там, где вершина корпоративной пирамиды. Но процессы и данные у центра и аппликации водителя будут перекликаться процентов на 70. Это как раз и создаёт предпосылки к путаницам с распределёнными и модульными монолитами. Нежелание повторяться приводит к сильно связанным громоздким сервисам и полурабочему зоопарку клиентов.

Иногда всё же стоит дублировать логику и учесть, что она может отличаться (центральная система должна уметь обрабатывать данные с оффлайновых приложений, даже если они не соответствуют её ожиданиям). Центр знает, что в машине 3 ящика молока и в каждом пункте доставки должны выгрузить один – в конечной синхронизации может оказаться, что 3 места посетили, а доставили только 2 ящика. Водитель забыл. Или разбил. Или на одной из точек выгрузил 2. Если вы всё время в онлайне, то постоянный поток данных позволяет следить и корректировать поведение. Допустим через нотификации и подтверждениях о выгрузки товара со стороны получателя. Без этого – физический мир просто сообщает вам фактическое состояние и живите с этим как хотите.

Если вам повезло и логику можно инкапсулировать в модуль, который легко впишется и в сервис, и в аппликацию на планшете (reuse over duplication), то данные всё равно будут жить своей жизнью. Но чем меньше кода, тем лучше. Так что если у вас предполагается работа без доступности центра, то стоит свести внесетевые функции к минимуму. Стандартная отказоустойчивость как часть дизайна. Водитель должен отчитаться о разбитом ящике молока – не стоит сразу дублировать форму на случай, если связи нет. Может достаточно создать напоминание об этом событии с принудительным заполнением в конце маршрута и оставить сам рапорт только сервисом на бэке? Не работает встроенный принтер – сохраним файл. А иногда и просто добавим бумажный формуляр к планшету, а в аппликации потребуем сделать его снимок.

Ошибки молодости

Разработчик сфокусирован на задании и не знает всей предыстории и, главное, последующих приключениях того, что он пишет. Особенно в большом проекте, где он один из легиона. Чтобы попасть в production и выстрелить, ошибка имплементации должна пережить всякие ревью, рефакториниги, автоматическое и ручное тестирование. Да и после этого, обычно, починить можно максимум за недельку. Редко, когда на ошибочном исполнении висят несколько процессов (хотя и такое бывает). А вот недочёт проектирования может вылиться в месяцы работы.  Одним из таких подводных камней была моя уверенность, что новая система сменит старую и автоматизация заменит ручной труд. Система датчиков должна была свести к минимуму интеракцию с пользователем, искоренить человеческий фактор и поднять достоверность данных. На деле же заказчик боялся довериться системе и не стал менять процедуры ручных проверок. Ни в каких требованиях и ожиданиях это не было обговорено. Ручной ввод был на случай отказа датчиков, а не в дополнение к ним. Система не могла справиться с прыжками и конфликтами в показаниях между данными от ручных измерений и сенсорами. Пришлось добавить еще один сервис для коррекции входных данных, перенаправить потоки, поменять процессы и переустановить весь прод. С тех пор я всегда рассчитываю на то, что новый продукт работает side-by-side. Этот подход так же помогает подготовиться к миграции и поддержке множества версий.

Ну и как найти и учесть все подобные случаи заранее? А никак. Архитектура большого проекта похожа на школьные опыты по биологии. Там, где рассматривают кожицу лука под микроскопом. Сначала вы смотрите на всё со стороны и добавляете контрастную жидкость. Потом вставляете в микроскоп и настраиваете свет, пытаясь остаться в границах на минимальном приближении. И лишь найдя цель, меняете увеличение на максимум фокусируетесь на деталях. То есть сначала вы делали блок схему, а потом перед непосредственной разработкой будете делать архитектуру каждого блока, заполняя его деталями. По необходимости будете добавлять всякие flow и sequence – они легче всего воспринимаются всеми участниками процесса разработки. Так что в отличии от строительства, вы начинаете разработку с наброска, а детальную архитектуру получите лишь в конце. Поэтому так полезны, хоть и не популярны, большие UML пакеты, позволяющие ссылки на диаграммы и вложенные чарты. Разработка – это drill down от blue-print до detailed architecture.

Agile architecture concept
Agile architecture concept

Что же нужно делать в начале – это инфраструктуру. То, что заказчик явным образом не просит, а значит и добавить её позже будет сложно. Если и не технически, то политически точно. Основа любого проекта – команда. Именно на людях стоит сосредоточится и задать единый язык и шаблон. По законам Мёрфи – если в коде будет плохой кусок, то его обязательно выберут как пример и размножат бесчисленное количество раз. Обговорите с разработчиками структуру проекта, названия и, если нужно, стилистику кода. Многие считают нейминг не важным, но в долгой разработке у всего есть дополнительный вес. Единый язык продуктового отдела и разработчиков, увековеченный в коде, сильно упрощает поддержку и модификации. Представьте, что вам на рабочий стол попал проект в пару сотен тысяч строк, десятки сервисов и баг, который говорит, что расчёт потенциала не верен. Если поиск в базе кода и системе планирования/отслеживания задач с ключевым словом «потенциал» ничего не даст, то вас ждут долгие часы выяснения правильного сценария и пошаговой отладки бизнес-процесса, разбросанного по куче модулей. Вам кажется, что пример высосан из пальца, но мне не раз доводилось самому копаться в подобном, пахнущем кислой радугой, проекте. Обилие синонимов, всяких акронимов и аббревиатур сделает вашу жизнь еще сложнее.

Всё, что нужно делать вручную, будут игнорировать так или иначе. Начало проекта – начало автоматизации. Тут и юнит тесты (для правильного дизайна и возможности рефакторинга), и интеграционные тесты (для стабильности проекта и уменьшения time-to-market), и метрики кода (всевозможные KPI) – всё часть CI-CD. Игры в микросервисы с ручной настройкой и развёрткой оставим мазохистам. Нам необходима команда DevOps. Формально или нет, но кто-то должен быть ответственным за правильную конфигурацию и установку среды. Среды разработки, среды проверок, среды интеграции и т.д. Иначе в будущем вместо среды вас будут ждать суббота и воскресенье разработки и проверки. В производственных системах редко можно найти изолированные бизнес-кейсы.  Все микросервисы должны будут взаимодействовать друг с другом и между ними будет явная или не явная зависимость. Устранить этот недостаток можно еще одним уровнем абстракции! Cервис – оркестратор сервисов. Тот, что вызывает цепочку других сервисов, чтоб обеспечить необходимый результат.  

Delivery service orchestrates domain services in business flow
Delivery service orchestrates domain services in business flow

Вернёмся к нашему грузовику. Водитель хочет начать маршрут. Для этого необходимо: получить квоту на топливо, заправиться, погрузить товар, подтвердить погрузку, составить маршрут, сообщить на точки отгрузки предположительное время прибытия и так далее. Если каждый этап станет отдельным сервисом, то клиент будет отвечать за бизнес. А хотелось бы чтоб он был как можно тоньше. Удобно группировать несколько таких шагов в один процесс и вызов. Сервис заправки – он проверит маршрут, квоту и авторизирует заправку. То есть последовательно запустит 3–4  микросервиса (с десяток API вызовов и сохранить состояние между ними). Конечный автомат. Плодить такие сервисы бесплатно тоже нельзя. Стоит создать жирненькие мета-сервисы объединяющие кросс-домейн процессы, вместо того, чтоб рулить всем из фронта. Не легковесные они, потому как знают многое о многих и строят сложные процессы взаимодействия. Однако связь односторонняя. Собственно – это простой медиатор. Основная причина не раздувать клиентскую часть лежит в разнообразии таких приложений с однообразием и стандартизацией процесса. Абсолютно тот же функционал должен быть доступен в каком-нибудь легаси винформ монолите, нативном андройд клиенте, который кто-то запилил вашему заказчику пару лет назад и новой веб-аппликации из вашего пакета. Очень удобно все три приложения заставить обращаться к одному сервису, сделав миграцию из legacy в nextgen быстрой и легко управляемой.

Помимо планирования есть еще и проверки того, что план соблюдают. Настройка правил статистического анализатора кода и внедрение проектных тестов (solution unit-test), на мой взгляд, задача архитектора. Что такое проектные тесты? Это жесткие правила ломающие билд при нарушении, написанные в виде юнит теста или плагина к какому-нибудь сонару. Примеры подобных тестов:

·       Минимальное покрытие тестами в определённых модулях

·       Ограничение по количеству заигнориных тестов

·       Тест на то, что тест с ограничением тестов в игноре не заигнорин

·       Список запрещённых референсов (например уровень бизнес-логики не должен знать о типах в базе данных)

·       Список разрешённых референсов (допустим open source и legacy библиотеки)

·       Разрешённые типы файлов (к примеру файлов .sql не должно существовать)

·       Naming и структура проекта (если должно быть 3 слоя и каждый отдельной библиотекой, а тесты заканчиваться на _Test то будьте любезны)

·       Парсинг и проверка скриптов на соответствие (например скрипт конфигурации должен создавать одноименную запись и в параметрах окружения и в файлах)

·       Минимальное количество строк лога в каждом классе (если актуально)

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

Такие тесты всегда делаются под конкретный проект и архитектуру решения. Всё это заставляет разработчика задуматься еще раз, и не даёт его менеджерам возможность легко увеличить тех.долг. Только не надо делать из тестов фетиш. Типа: «Каждый модуль должен быть на 100% покрыт тестами.». 100% покрытие тестом необходимое условие для пельменей, а не для проекта.

Теперь пора строить план. Что вы должны выдать в качестве необходимого функционала – вам сообщат все заинтересованные участники. Надо понять как много (или мало) останется на инфраструктуру. Все Agile, но только, когда им удобно. Выделить месяц на создание основы проекта без деловой логики/функционала, почему-то не хотят. Не достаточно прозрачно. Или сложно тестировать. Все уверены, что основа проекта закладывается с самой сложной формы в UI. Вот gateway ваш, безопасность и мониторинг можно и позже – их же всё равно никто не видит. А заказчику нужно что-то показать. Так что опять нужно будет продавать необходимость и своевременность. Как обычно апеллируя к тому, что увеличение числа процессов и компонентов прямо пропорционально стоимости внедрения 3-х «С» — сквозных системных служб. И, как всегда, создаётся впечатление, что это понимаете вы и пара инженеров, но не управленцы.

Если всё получилось, то «земля, прощай» и в добрый путь.


ссылка на оригинал статьи https://habr.com/ru/post/552868/

Huawei: настройка VXLAN фабрики

Привет Хабр!

В данной статье хочу поделиться настройкой VXLAN фабрики на оборудовании Huawei. На Хабре, да и на других ресурсах довольно подробна описана технология, как работает control plan, data plane, архитектура и т.д., поэтому в этой статье будет приведена настройка коммутатора с некоторыми пояснениями. Любая критика приветствуется. Для тестирования конфигурации появилась возможность добавить в EVE-NG коммутатор Huawei CE12800. За подробностями сюда и сюда. Data plane к сожалению там работает плохо, но control plane хорошо и не поддерживается часть функционала (m-lag, L3VXLAN например).

Общее описание схемы и подготовка underlay

В фабрике будет использоваться 2 Spine и 4 Leaf (2 из которых объединены в m-lag пару). Между Spine и Leaf коммутаторами используются point to point подсети с 31 маской и увеличен MTU. Используется симметричный IRB. Spine коммутаторы так же будут выполнять роль BGP route reflector. Инкапсуляция и деинкапсуляция будет производиться на Leaf коммутаторах.

Начну с настройки m-lag пары leaf коммутаторов, для правильной работы нужен keepalive линк и peer линк. По peer линку может идти полезная нагрузка поэтому необходимо учитывать полосу пропускания этого линка. Так же следует учитывать, что m-lag в исполнении Huawei накладывает некоторые ограничения, например нельзя построить ospf соседство через агрегированный интерфейс (или можно но с костылями):

dfs-group 1  priority 150  source ip 192.168.1.1 # IP адрес keepalive линка # stp bridge-address 0039-0039-0039 #для правильной работы STP задаем одинаковый bridge id # lacp m-lag system-id 0010-0011-0012 #задаем system id для LACP # interface Eth-Trunk0 #создаем peer линк  trunkport INTERFACE #добавляем интерфейс в LAG   stp disable  mode lacp-static  peer-link 1 # interface Eth-Trunk1 #пример агрегированного интерфейса в сторону сервера например   mode lacp-static  dfs-group 1 m-lag 1

Проверяем, что m-lag пара собралась:

<Leaf11>disp dfs-group 1 m-lag *                : Local node Heart beat state : OK Node 1 *   Dfs-Group ID   : 1   Priority       : 150   Address        : ip address 192.168.1.1   State          : Master   Causation      : -   System ID      : fa1b-d35c-a834   SysName        : Leaf11   Version        : V200R005C10SPC800   Device Type    : CE8861EI Node 2   Dfs-Group ID   : 1   Priority       : 120   Address        : ip address 192.168.1.2   State          : Backup   Causation      : -   System ID      : fa1b-d35c-a235   SysName        : Leaf12   Version        : V200R005C10SPC800   Device Type    : CE8861EI    <Leaf11>disp dfs-group 1 node 1 m-lag brief * - Local node  M-Lag ID     Interface      Port State    Status                Consistency-check        1     Eth-Trunk 1    Up            active(*)-active      --

Пример настройки интерфейса внутри фабрики:

interface GE1/0/0  undo portswitch  #переводим интерфейс в режим L3  undo shutdown  #административно включаем интерфейс  ip address 192.168.0.1 31  ospf network-type p2p #меняем тип OSPF интерфейса на point-to-point  mtu 9200 #увеличиваем MTU интерфейса

В качестве underlay протокола маршрутизации используется OSPF:

ospf 1 router-id 10.1.1.11  area 0.0.0.0   network 10.1.1.1 0.0.0.0 #анонсируем anycast lo только с m-lag пары   network 10.1.1.11 0.0.0.0   network 192.168.0.0 0.0.255.255

Так же в качестве протокола маршрутизации можно использовать два BGP процесса, один для underlay маршрутизации и второй для overlay маршрутизации.

bgp AS_UNDERLAY #процесс для underlay маршрутизации  <settings> bgp AS_OVERLAY instance EVPN_NAME #процесс для overlay маршрутизации  <settings>

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

<Leaf11>disp ospf peer brief OSPF Process 1 with Router ID 10.1.1.11                    Peer Statistic Information Total number of peer(s): 2  Peer(s) in full state: 2 -----------------------------------------------------------------------------  Area Id         Interface                  Neighbor id          State  0.0.0.0         GE1/0/0                    10.1.1.100           Full  0.0.0.0         GE1/0/1                    10.1.1.101           Full -----------------------------------------------------------------------------

Соседство собралось, проверим маршрутную информацию:

<Leaf11>disp ip routing-table protocol ospf Proto: Protocol        Pre: Preference Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route ------------------------------------------------------------------------------ _public_ Routing Table : OSPF          Destinations : 11       Routes : 13  OSPF routing table status : <Active>          Destinations : 8        Routes : 10  Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface         10.1.1.2/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                     OSPF    10   2             D   192.168.0.0     GE1/0/0        10.1.1.3/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                     OSPF    10   2             D   192.168.0.0     GE1/0/0       10.1.1.12/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                     OSPF    10   2             D   192.168.0.0     GE1/0/0      10.1.1.100/32  OSPF    10   1             D   192.168.0.0     GE1/0/0      10.1.1.101/32  OSPF    10   1             D   192.168.0.8     GE1/0/1

Подготовка overlay

Для начала необходимо глобально включить поддержку EVPN на коммутаторе:

evpn-overlay enable

Spine коммутаторы выполняют роль Route-reflector. Плюс нужно добавить строку undo policy vpn-target в соответствующей address family, чтобы Spine смог принять все маршруты и переслать их клиентам. Соседство строим на loopback адресах.

bgp 65000  group leafs internal  peer leafs connect-interface LoopBack0  peer 10.1.1.11 as-number 65000  peer 10.1.1.11 group leafs  peer 10.1.1.12 as-number 65000  peer 10.1.1.12 group leafs  peer 10.1.1.2 as-number 65000  peer 10.1.1.2 group leafs  peer 10.1.1.3 as-number 65000  peer 10.1.1.3 group leafs  #  ipv4-family unicast   undo peer leafs enable   undo peer 10.1.1.11 enable   undo peer 10.1.1.12 enable   undo peer 10.1.1.2 enable   undo peer 10.1.1.3 enable  #  l2vpn-family evpn   undo policy vpn-target   peer leafs enable   peer leafs reflect-client   peer 10.1.1.11 enable   peer 10.1.1.11 group leafs   peer 10.1.1.12 enable   peer 10.1.1.12 group leafs   peer 10.1.1.2 enable   peer 10.1.1.2 group leafs   peer 10.1.1.3 enable   peer 10.1.1.3 group leafs

На Leaf коммутаторах настраиваем нужный address family. Для m-lag пары хочется сделать политику подменяющую next-hop на anycast loopback ip адрес, но без такой политики все работает. Huawei подменяет next-hop адрес на адрес который указан в качестве source ip адреса интерфейса NVE. Но если вдруг возникнут проблемы с автоматической подменой всегда можно навесить политику руками:

bgp 65000  group rr internal  peer rr connect-interface LoopBack0  peer 10.1.1.100 as-number 65000  peer 10.1.1.100 group rr  peer 10.1.1.101 as-number 65000  peer 10.1.1.101 group rr  #  ipv4-family unicast   undo peer rr enable   undo peer 10.1.1.100 enable   undo peer 10.1.1.101 enable  #  l2vpn-family evpn   policy vpn-target   peer rr enable   peer 10.1.1.100 enable   peer 10.1.1.100 group rr   peer 10.1.1.101 enable   peer 10.1.1.101 group rr

Проверяем, что overlay control plane собрался:

<Leaf11>disp bgp evpn peer  BGP local router ID        : 10.1.1.11  Local AS number            : 65000  Total number of peers      : 2  Peers in established state : 2    Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State  PrefRcv   10.1.1.100      4       65000    12829    12811     0 0186h15m Established        0   10.1.1.101      4       65000    12844    12822     0 0186h15m Established        0    <Leaf11>disp bgp evpn peer 10.1.1.100 verbose #лишние строки удалены для сокращения вывода  BGP Peer is 10.1.1.100,  remote AS 65000  Type: IBGP link  Update-group ID: 2  Peer optional capabilities:   Peer supports bgp multi-protocol extension   Peer supports bgp route refresh capability   Peer supports bgp 4-byte-as capability   Address family L2VPN EVPN: advertised and received

Подготовка L2 VXLAN

Сперва создадим NVE интерфейс отвечающий за инкапсуляцию/деинкапсуляцию пакетиков:

interface Nve1 #создаем NVE интерфейс  source 10.1.1.1 #для m-lag пары используем anycast ip адрес  mac-address 0000-5e00-0199 #обязательно для m-lag пары на обоих коммутаторах настраиваем одинаковый MAC адрес, это необходимо для работы L3 VXLAN

Для организации L2 VXLAN необходимо создать bridge-domain и примапить к нему vlan, l2 подинтефейс или интерфейс целиком. К одному bridge-domain могут быть примаплены разные VLANs.

bridge-domain 150 #создаем bridge-domain vlan 150 access-port interface Eth-Trunk12 #можно мапить vlan в конфигурации bridge-domain, а можно в создавать l2 подинтерфейс  vxlan vni 22150 #определяем vni  evpn #создаем evpn instance   route-distinguisher 10.1.1.11:22150   vpn-target 65000:22150 export-extcommunity   vpn-target 65000:23500 export-extcommunity #этот rt нужен в будущем для L3 VXLAN   vpn-target 65000:22150 import-extcommunity # interface GE1/0/9.150 mode l2 #создаем подинтерфейс  encapsulation [default,dot1q,untag,qinq] #выбираем тип инкапсуляции  bridge-domain 150 #мапим к нужному bridge-domain # interface Nve1   vni 22150 head-end peer-list protocol bgp #определяем, что для BUM трафика будет использоваться ingress replication list с автообнаружением по BGP

Проделываем такую же работу на остальных коммутаторах и проверяем работу. На коммутаторах должны появиться EVPN маршруты типа 3:

<Leaf11>disp evpn vpn-instance name 150 verbose  VPN-Instance Name and ID : 150, 1   Address family evpn   Route Distinguisher : 10.1.1.11:22150   Label Policy        : label per instance   Per-Instance Label  : 16,17   Export VPN Targets  : 65000:22150 65000:23500   Import VPN Targets  : 65000:22150 # <Leaf11>disp bgp evpn vpn-instance 150 routing-table inclusive-route  BGP Local router ID is 10.1.1.11  Status codes: * - valid, > - best, d - damped, x - best external, a - add path,                h - history,  i - internal, s - suppressed, S - Stale                Origin : i - IGP, e - EGP, ? - incomplete    EVPN-Instance 150:  Number of Inclusive Multicast Routes: 3        Network(EthTagId/IpAddrLen/OriginalIp)                 NextHop  *>    0:32:10.1.1.1                                          0.0.0.0  *>i   0:32:10.1.1.2                                          10.1.1.2  * i                                                          10.1.1.2

Посмотрим попристальнее на анонс полученный от соседа:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table inclusive-route 0:32:10.1.1.2   BGP local router ID : 10.1.1.11  Local AS number : 65000    EVPN-Instance 150:  Number of Inclusive Multicast Routes: 2  BGP routing table entry information of 0:32:10.1.1.2:  Route Distinguisher: 10.1.1.2:22150  Remote-Cross route  Label information (Received/Applied): 22150/NULL #видим нужный нам vni  From: 10.1.1.100 (10.1.1.100)  Route Duration: 7d19h17m35s  Relay Tunnel Out-Interface: VXLAN  Original nexthop: 10.1.1.2  Qos information : 0x0  Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>, Tunnel Type <VxLan>  AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255  Originator: 10.1.1.2  PMSI: Flags 0, Ingress Replication, Label 0:0:0(22150), Tunnel Identifier:10.1.1.2  Cluster list: 10.1.1.100  Route Type: 3 (Inclusive Multicast Route)  Ethernet Tag ID: 0, Originator IP:10.1.1.2/32  Not advertised to any peer yet

BUM трафик должен ходить, можно приступать к проверке связности между хостами. Для этого с хоста VM1 пропингуем хост VM2:

ubuntu@test-vxlan-01:~$ ping 192.168.50.3 PING 192.168.50.3 (192.168.50.3) 56(84) bytes of data. 64 bytes from 192.168.50.3: icmp_seq=1 ttl=64 time=0.291 ms --- 192.168.50.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.291/0.291/0.291/0.000 ms # ubuntu@test-vxlan-01:~$ ip neigh 192.168.50.3 dev eth0 lladdr 00:15:5d:65:87:26 REACHABLE

В это время на сети должны появиться анонсы 2 типа. Проверим:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table mac-route  BGP Local router ID is 10.1.1.11  Status codes: * - valid, > - best, d - damped, x - best external, a - add path,                h - history,  i - internal, s - suppressed, S - Stale                Origin : i - IGP, e - EGP, ? - incomplete   EVN-Instance 150:  Number of Mac Routes: 3        Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop *>i   0:48:0015-5d65-8726:0:0.0.0.0                          10.1.1.2  * i                                                          		10.1.1.2  *>    0:48:0015-5df0-ed07:0:0.0.0.0                          0.0.0.0 

Посмотрим анонс пристальнее:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table mac-route 0:48:0015-5d65-8726:0:0.0.0.0   BGP local router ID : 10.1.1.11  Local AS number : 65000   EVN-Instance 150:  Number of Mac Routes: 2 #два маршрута, потому что приходит от двух RR  BGP routing table entry information of 0:48:0015-5d65-8726:0:0.0.0.0:  Route Distinguisher: 10.1.1.2:22150  Remote-Cross route  Label information (Received/Applied): 22150/NULL  From: 10.1.1.100 (10.1.1.100)  Route Duration: 0d00h07m19s  Relay Tunnel Out-Interface: VXLAN  Original nexthop: 10.1.1.2  Qos information : 0x0  Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>, Tunnel Type <VxLan>  AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255  Route Type: 2 (MAC Advertisement Route)  Ethernet Tag ID: 0, MAC Address/Len: 0015-5d65-8726/48, IP Address/Len: 0.0.0.0/0, ESI:0000.0000.0000.0000.0000  Not advertised to any peer yet

Проверяем CAM таблицу коммутатора:

<Leaf11>disp mac-add bridge-domain 150 Flags: * - Backup        # - forwarding logical interface, operations cannot be performed based            on the interface. BD   : bridge-domain   Age : dynamic MAC learned time in seconds ------------------------------------------------------------------------------- MAC Address    VLAN/VSI/BD   Learned-From        Type                Age ------------------------------------------------------------------------------- 0015-5d65-8726 -/-/150       10.1.1.2      evn                   - 0015-5df0-ed07 -/-/150       Eth-Trunk1.150      dynamic             450 ------------------------------------------------------------------------------- Total items: 2

Подготовка L3 VXLAN

Настало время выпустить хосты за пределы своей подсети, для этого будем использовать distributed gateway.

Для начала создадим нужный VRF:

ip vpn-instance EVPN  ipv4-family   route-distinguisher 10.1.1.11:23500   vpn-target 65000: 23500 export-extcommunity evpn   vpn-target 65000: 23500 import-extcommunity evpn  vxlan vni 23500

В конфигурацию BGP Leaf коммутаторов добавляем анонс IRB:

bgp 65000 l2vpn-family evpn   peer rr advertise irb

Создаем L3 интерфейс для маршрутизации в нужном VRF:

interface Vbdif150 #номер должен совпадать с номером bridge-domain  ip binding vpn-instance EVPN  ip address 192.168.50.254 24  mac-address 0000-5e00-0101  vxlan anycast-gateway enable  arp collect host enable #генерация маршрута второго типа на основании arp записи

Повторяем конфигурации на других Leaf коммутаторах и проверяем:

<Leaf11>disp ip vpn-instance SDC-EVPN   VPN-Instance Name               RD                    Address-family   EVPN                        10.1.1.11:23500            IPv4 <Leaf11>disp evpn vpn-instance name __RD_1_10.1.1.11_23500__ verbose  VPN-Instance Name and ID : __RD_1_10.1.1.11_23500__, 2   Address family evpn   Route Distinguisher : 10.1.1.11:23500   Label Policy        : label per instance   Per-Instance Label  : 17,18   Export VPN Targets  : 65000 : 23500   Import VPN Targets  : 65000 : 23500

На некоторых моделях коммутаторов (лучше свериться с официальной документацией) необходимо создание специального сервисного интерфейса для продвижения L3 VXLAN трафика. Полоса этого интерфейса должна быть в два раза больше пиковой полосы для L3 VXLAN трафика. При наличии большого количества Vbdif интерфейсов (более 2 тысяч) требуется создание дополнительных сервисных интерфейсов.

interface Eth-TrunkXXX  service type tunnel  trunkport 40GE1/1/1

На этом настройка L3 VXLAN завершена. Проверим доступность между хостами из разных подсетей:

ubuntu@test-vxlan-01:~$ ping 192.168.51.1 PING 192.168.51.1 (192.168.51.1) 56(84) bytes of data. 64 bytes from 192.168.51.1: icmp_seq=1 ttl=63 time=0.508 ms  --- 192.168.51.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.508/0.508/0.508/0.000 ms

Связность есть, теперь проверим маршрутную информацию:

<Leaf11>disp arp interface Vbdif 150 ARP timeout:1200s ARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlow EXP: Expire-time  src: Source ip   dst: Destination ip  IP ADDRESS      MAC ADDRESS    EXP(M) TYPE/VLAN/CEVLAN   INTERFACE ---------------------------------------------------------------------------------------- 192.168.50.254  0000-5e00-0101        I                  Vbdif150 192.168.50.1    0015-5df0-ed07   15   D/150/-            Eth-Trunk1.150 ---------------------------------------------------------------------------------------- Total:2         Dynamic:1       Static:0    Interface:1    OpenFlow:0 Redirect:0 # <Leaf1>disp bgp evpn vpn-instance 150 routing-table mac-route  BGP Local router ID is 10.1.1.11  Status codes: * - valid, > - best, d - damped, x - best external, a - add path,                h - history,  i - internal, s - suppressed, S - Stale                Origin : i - IGP, e - EGP, ? - incomplete   EVN-Instance 150:  Number of Mac Routes: 7        Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop  *>    0:48:0000-5e00-0101:0:0.0.0.0                          0.0.0.0  * i                                                          10.1.1.2  * i                                                          10.1.1.2  *>i   0:48:0015-5d65-8726:32:192.168.50.3                    10.1.1.2  * i                                                          10.1.1.2  *>    0:48:0015-5df0-ed07:0:0.0.0.0                          0.0.0.0  *>    0:48:0015-5df0-ed07:32:192.168.50.1                    0.0.0.0 

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

<Leaf11>disp bgp evpn vpn-instance __RD_1_10.1.1.11_23500__ routing-table mac-route  BGP Local router ID is 10.1.1.11  Status codes: * - valid, > - best, d - damped, x - best external, a - add path,                h - history,  i - internal, s - suppressed, S - Stale                Origin : i - IGP, e - EGP, ? - incomplete   EVN-Instance __RD_1_10.1.1.11_23500__:  Number of Mac Routes:         Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop *>i   0:48:0015-5d65-8726:32:192.168.50.3                    10.1.1.2  * i                                                          10.1.1.2 *>i   0:48:0015-5df0-ed08:32:192.168.51.2                    10.1.1.3  * i                                                          10.1.1.3 # <leaf11>disp bgp evpn vpn-instance __RD_1_10.1.1.11_23500__ routing-table mac-route 0:48:0015-5d65-8726:32:192.168.50.3   BGP local router ID : 10.1.1.11  Local AS number : 65000   EVN-Instance __RD_1_10.1.1.11_23500__:  Number of Mac Routes: 2  BGP routing table entry information of 0:48:0015-5d65-8726:32:192.168.50.3:  Route Distinguisher: 10.1.1.2:23500  Remote-Cross route  Label information (Received/Applied): 22150 23500/NULL #добавился L3 VNI  From: From: 10.1.1.100 (10.1.1.100)  Route Duration: 7d08h48m44s  Relay Tunnel Out-Interface: VXLAN  Original nexthop: 10.1.1.2  Qos information : 0x0  Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>Tunnel Type <VxLan>, Router's MAC <3864-0111-1200> #в качестве MAC адреса используется MAC адрес NVE интерфейса VTEPа  AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255  Route Type: 2 (MAC Advertisement Route)  Ethernet Tag ID: 0, MAC Address/Len: 0015-5d65-8726/48, IP Address/Len: 192.168.50.3/32, ESI:0000.0000.0000.0000.0000  Not advertised to any peer yet

Заключение

В данной статье я попытался описать процесс настройки EVPN VXLAN фабрики на базе оборудования Huawei и привести некоторые команды необходимые в процессе отладки.

Спасибо за внимание!

ссылка на оригинал статьи https://habr.com/ru/post/552946/

Почему античитерское ПО блокирует инструменты разгона?

Кто из нас не пользовался читами в играх? Whosyourdaddy, thereisnospoon, hesoyam — помните? Но обращали ли вы внимание, почему, когда игрок пытается разогнать процессор или изменить настройки ПО, срабатывают некоторые программы против читеров вплоть до блокировки? В этой статье, которая будет полезна для читателей, не обладающих глубокими техническими знаниями в области использования ПО для читеров, против читеров, драйверов и того, что с ними связано, попробуем разобраться почему инструменты мониторинга/разгона блокируются античитерским ПО.


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

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

В нашем случае код для переработки берётся с таких сайтов, как kernelmode.info, OSR Online, и других. Особую обеспокоенность вызывают используемые таким программным обеспечением драйверы. Если бы я захотел причинить вред большому количеству людей (отличной мишенью для моей атаки могли бы стать геймеры и компьютерные энтузиасты), я бы в первую очередь использовал драйверы, входящие в состав некоторых программных инструментов, о которых расскажу далее. В статье я пишу только о некоторых драйверах, на самом деле их гораздо больше — кодонезависимыми десятки, если не сотни. Драйверы, о которых пойдёт речь, использовались сообществом читеров ранее или используются сейчас. Попытаемся понять, зачем вообще в такое программное обеспечение включаются драйверы.

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

Зачем нужны драйверы?

За последние 5–10 лет в связи с развитием индустрии профессионального гейминга и повышением технических требований к запуску определённых игр всё большую популярность приобретают инструменты мониторинга оборудования и повышения тактовой частоты процессора. Такие инструменты опрашивают различные компоненты системы, такие как GPU, CPU, датчики температуры и прочее, однако обычному пользователю получить эту информацию не так просто. 

Например, чтобы отправить запрос на цифровой датчик температуры для получения данных о температуре процессора, приложение должно выполнить чтение из моделезависимого регистра процессора. Доступ к таким регистрам процессора и внутренним механизмам чтения/записи возможен только с более высоким уровнем привилегий, например ring0 (на этом уровне работают драйверы). Моделезависимый регистр процессора (MSR) — это тип регистра, представляющий собой часть набора команд x86. Как следует из названия регистра, на процессорах одной модели имеются одни регистры, на процессорах другой модели — другие, что делает их моделезависимыми. Такие регистры используются в первую очередь для хранения специальной информации о платформе и особенностях процессора; они также могут использоваться для мониторинга показателей производительности или значений тепловых датчиков. 

Intel приняла решение включить в набор инструкций x86 две инструкции, позволяющие привилегированному ПО (операционной или другой системе) считывать или записывать данные в MSR. Инструкции rdmsr и wrmsr позволяют привилегированной программе-агенту запрашивать или изменять состояние одного из таких регистров. Для процессоров Intel и AMD имеется обширный перечень доступных MSR, которые можно найти в соответствующих SDM/APM. Тут важно отметить, что большая часть информации в таких моделезависимых регистрах не должна меняться никакими задачами — не важно, привилегированные они или нет. Но даже при написании драйверов устройств необходимость в этом возникает крайне редко.

Многие драйверы, создаваемые с целью программного мониторинга оборудования, позволяют задаче без привилегий (если под привилегиями понимать привилегии администратора) считывать/записывать произвольные MSR. 

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

Клиентское приложение, например десктопное приложение CPUZ, использует функцию WinAPI под названием DeviceIoControl. Говоря простым языком, CPUZ вызывает функцию DeviceIoControl с помощью известного разработчикам управляющего кода ввода/вывода, чтобы выполнить операцию чтения MSR, например, данных накристального цифрового датчика температуры. 

Вы скажете: ну и что? В чём проблема? Проблема в том, что эти драйверы реализуют дополнительную функциональность за рамками своих задач и делают это через тот же самый интерфейс — речь идёт, например, о записи в MSR или в физическую память.

Но, опять скажете вы, если коды известны только разработчикам, в чём же проблема? Плодотворным начинанием будет реверс-инжинеринг: всё, что нужно сделать злоумышленнику, — получить копию драйвера, загрузить её в любой дизассемблер, скажем, в IDA Pro, и проанализировать обработчик IOCTL

Ниже представлен код IOCTL в драйвере CPUZ, используемый для отправки двух байтов с двух различных портов ввода/вывода, — 0xB2 (широковещательный SMI) и 0x84 (выходной порт 4). Вот это уже становится интересно, так как SMI можно заставить использовать порт 0xB2, позволяющий войти в режим управления системой. Не хочу утверждать, что с этой функцией можно натворить дел, просто отмечаю интересную особенность. Порт SMI используется в первую очередь для отладки.

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

Недокументированный драйвер Intel

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

Примечание: под непривилегированным приложением понимается приложение, выполняемое с низким уровнем привилегий, — ring-3; между тем, чтобы выполнить запрос DeviceIoControl, требуются права администратора.

Помимо прочего, драйвер предоставляет непосредственный доступ к порту ввода-вывода для записи, а эта операция должна быть доступна только привилегированным приложениям. Доступом к записи вполне можно злоупотребить во вред конечному пользователю. Вредоносная программа-агент может использовать драйвер, чтобы запустить «отказ в обслуживании» (denial-of-service) посредством записи в порт ввода-вывода, такая запись может использоваться для аппаратного сброса процессора.

В диагностическом инструменте Intel такие операции имеют определённый смысл. Однако драйвер подписан, входит в состав официально поставляемого инструмента, и, если он попадёт в нечистоплотные руки, его можно использовать для причинения вреда в нашем случае игровым приложениям. Возможность чтения и записи в физическую память означает, что злоумышленник может получить доступ к памяти игры в обход традиционных методов доступа, например, без получения доступа к процессу и без использования Windows API для чтения виртуальной памяти. Злоумышленнику, конечно, придётся постараться, но разве когда-нибудь такая мелочь останавливала мотивированного человека? 

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

HWMonitor

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

На скриншоте ниже показан другой метод чтения части физической памяти через функцию MmMapIoSpace. Эта функция часто используется злоумышленниками под видом доверенного инструмента для мониторинга оборудования. А как обстоят дела с записью в моделезависимые регистры процессора? Этот инструмент не предполагает запись ни в какие MSR, тем не менее, правильно переработанный код позволяет записывать данные в любой моделезависимый регистр процессора. Ниже приводятся два примера различных блоков IOCTL в HWMonitor.

Отметим, что используемый HWMonitor драйвер — это тот же самый драйвер, который использует CPUZ! ПО против читерства, естественно, может просто запретить запуск HWMonitor, но у злоумышленника есть выход — он может с таким же успехом воспользоваться драйвером из CPUZ

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

Возможность доступа к таким регистрам через любой непроверенный интерфейс дает злоумышленникам возможность изменять системные данные, к которым у них ни в коем случае не должно быть доступа. Через эту уязвимость злоумышленники могут обходить защитные механизмы, устанавливаемые третьими сторонами, например ПО против читеров. Такое ПО может фиксировать обратные вызовы, например ExCbSeImageVerificationDriverInfo, что позволяет драйверу получать информацию о загруженном драйвере. При помощи доверенного драйвера злоумышленникам удаётся скрывать свои действия. Античитерское ПО логирует/отмечает/делает дамп довольно большого количество подписанных пользователями драйверов, но всё же считает доверенными некоторые драйверы из состава WHQL или продуктов Intel. К слову, античитерское ПО само использует операцию обратного вызова, чтобы запретить загрузку драйверов, например упакованного драйвера для CPUZ (иногда античитерское ПО не запрещает загрузку драйвера, а просто фиксирует факт его наличия, даже если имя драйвера было изменено).

MSI Afterburner

Теперь вам должно быть понятно, почему загрузка многих таких драйверов блокируется античитерским ПО. Про MSI Afterburner лучше всего почитать в exploit-db. С ним проблемы те же, что и с вышеописанными драйверами, и для сохранения целостности системы и игровых приложений загрузку этого ПО разумно будет запретить.

Справедливости ради следует сказать, что описанные уязвимости уже устранены, но я всего лишь привёл пример того, как неожиданно могут повернуться многие, казалось бы, полезные инструменты. Несмотря на то, что MSI отреагировала соответствующим образом и обновила Afterburner, были обновлены не все инструменты OC/мониторинга.

Заключение

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

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

Читеры стали задействовать такие драйверы ещё в 2015–2016 годах, а возможно, и раньше; однако до этого времени код с демонстрацией на крупных читерских форумах не публиковался. Блокировать драйверы необходимо, чтобы запретить обход античитерского ПО через доверенный сторонний драйвер и защитить игру от хакеров, использующих такой метод атаки. 

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

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы

ссылка на оригинал статьи https://habr.com/ru/company/skillfactory/blog/552392/

Три доступных «полочника» — как может выглядеть такая акустика, и что находится у нее «под капотом»

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

На фотографии: Arslab Stereo One. Источник: Audiomania.ru
На фотографии: Arslab Stereo One. Источник: Audiomania.ru

[27 900] Arslab Stereo One — крупная и «уверенная в себе» полочная система. По габаритам и весу она может сравниться с ELAC Debut B6.2, о которых мы говорили в прошлый раз. Одна колонка Arslab Stereo One весит 7,1 кг, что на 300 грамм легче, однако она и чуть выше [390 мм], плюс — обладает аналогичным по диаметру НЧ-динамиком [16,5 см]. Он снабжен бумажным диффузором, выполненным по технологии холодного прессования, чтобы снизить вероятность искажений на высокой громкости до ничтожного минимума. При этом колонке достался относительно крупный ВЧ-динамик [22 мм] с шелковым куполом и внимательно подобранная начинка. Инженеры смогли задействовать компоненты по максимуму, добились сбалансированного и детального звучания, обеспечили универсальный характер применения системы. Stereo One по мощности подходит для работы в небольших и средних комнатах до 22 квадратов и может выполнять роль боковых или тыловых колонок домашнего кинотеатра.

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


[29 490] Monitor Audio Bronze 50 6G — самая компактная модель шестой серии акустики этого бренда. Весит колонка всего пять килограмм, а ее высота достигает 265 мм. Понятное дело, что такую систему сложно обеспечить крупным низкочастотным динамиком — здесь он пятидюймовый. При этом басовик снабдили многослойным диффузором C-CAM — это технология производства на основе сплава алюминия с керамическим покрытием. Вместе с DCM [damped concentric mode] она минимизирует резонансы и искажения звучания.

На фотографии: Monitor Audio Bronze 50 6G. Источник: Audiomania.ru
На фотографии: Monitor Audio Bronze 50 6G. Источник: Audiomania.ru

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

Максимальный уровень звукового давления, которое генерирует система, составляет 107 дБ. Этого будет достаточно для небольших и средних по площади помещений, плюс — использования акустики в роли фронтальных или тыловых каналов домашнего кинотеатра. Bronze 50 настроены таким образом, чтобы колонки можно было размещать в зависимости от требований дизайна пространства — точное направленность на слушателя не требуется.

Дополнительные обзоры на английском есть тут и здесь.


[34 890] DALI Oberon 1 — младшая модель в линейке бренда с достаточно скромными габаритами. Она весит всего 4,2 кг и обладает средней высотой [274 мм — чуть выше Bronze 50 и намного ниже Arslab Stereo One]. При этом здесь присутствуют крупные НЧ-динамики [133 мм], что необычно для компактной акустики. Басовики обладают диффузорами из древесно-бумажной массы, антирезонансным шасси и задействуют технологию SMC [soft magnetic compound]. Она позволяет приблизить впечатления от прослушивания к звучанию, воспринимаемому слушателем на живых выступлениях любимых музыкантов.

На фотографии: DALI Oberon 1. Источник: Unsplash.com
На фотографии: DALI Oberon 1. Источник: Unsplash.com

ВЧ-динамик обладает диаметром 29 мм. Он тоже установлен на шасси, защищающее его от вибраций. Возможное максимальное звуковое давление этой системы — 106 дБ, что более чем достаточно для обычных комнат в квартире и подключения к домашнему кинотеатру.

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

Дополнительные обзоры на английском — первый и второй.


Что еще у нас есть на Хабре:


ссылка на оригинал статьи https://habr.com/ru/company/audiomania/blog/552424/