Зачем (затем, что нужно кормить баллистическую модель)
Для построения траекторий КА и их носителей нужны данные. В первую очередь — аэродинамические. Они нужны при определении сил и моментов, действующих на космический аппарат (или его ступень), а также для оценки теплового состояния конструкции. Характеристики зависят от внешнего вида КА и параметров полета и обычно выглядят как обширные простыни с зависимостями соответствующих коэффициентов от углов атаки, чисел Маха, высот и много еще чего.
Есть несколько способов получить эти цифры:
CFD. Всякие ANSYS, floEFD, solidWorks flow simulation и так далее. Большие и серьезные программные пакеты с серьезным ценником. И для стартапа, пилящего свой шаттл в гараже, такой софт обойдется приблизительно во столько же, во сколько и сам гараж.
Приближенные графоаналитические методы. Потому что люди уже давно запускают в воздух и вакуум самые разные девайсы. Данные по их обтеканию в трубах и свободном потоке занесены в справочники, табулированы и параметризованы по удлинениям, углам стреловидности, толщинам профилей и так далее и тому подобное. Проблема таких подходов — в необходимости «на глаз» работать с различными книгами и атласами характеристик, переносить цифры с бумаги в электронный вид и страдать, страдать, страдать, когда геометрия приобретает формы, отличные от «цилиндроконический корпус с тонким крылом»
Приближенные методы на базе локальных параметров обтекания. Занимают промежуточное положение между первыми двумя и основаны на разбиении геометрии исследуемого ЛА на фрагменты, взаимодействием между которыми можно пренебречь. Поскольку возмущения в потоке не могут распространяться быстрее скорости звука и за пределы скачков уплотнения, то подобные методы лучше всего работают на больших скоростях (M ~ 8-10 и выше). Ими мы и займемся
Два основных метода — метод касательных клиньев и метод Ньютона. В каждом из методов поверхность ЛА дробится на элементарные площадки, затем определяется местный угол атаки (между плоскостью и набегающим потоком). В методе локальных скачков угол атаки сравнивается с максимальным допустимым (после него скачок отходит от поверхности), затем определяется степень повышения давления в потоке.
Н.Ф. Краснов. Аэродинамика. том 1. Тэта — угол отклонения скачка, бэта — угол наклона поверхности, создающей скачок, дельта — параметр, зависящий от показателя адиабаты. Решив это уравнение методом Ньютона, получим необходимый нам угол скачка и параметры преобразования потока.
В методе Ньютона предполагается, что в избыточное давление превратится вся та часть удельного импульса потока, что шла по нормали к обтекаемой поверхности.
Основы метода Ньютона. Н.С. Аржаников, Г.С. Садекова. «Аэродинамика летательных аппаратов»
Если же угол — отрицательный, то поток испытывает разрежение, которое для малых углов хорошо аппроксимируется. Если угол превышен, то поток при обтекании тупого угла разрежается до вакуума (во всяком случае, давление на поверхности становится нулевым)
Зная габариты ЛА, можно определить его омываемую поверхность и характерный габарит. С этими цифрами на основе расчетно-экспериментальных данных можно вычислить коэффициент трения плоской пластины и дополнить им коэффициент сопротивления ЛА.
Оценка трения эквивалентной пластины по критерию Рейнольдса
Отдельно выступает случай сильно разреженного газа (определяется числом Кнудсена, зависящим от скорости, плотности и габаритов ЛА). В этом случае метод Ньютона модифицируется с учетом произвольного движения молекул газа после столкновения с поверхностью
Все превратится в треугольники
Теперь нужно получить данные о геометрии ЛА. Есть множество форматов, но самым удобным кажется STL. Каждая запись исчерпывающе описывает элементарную площадку на поверхности тела через три точки, которые ее формируют, и ориентированный вектор нормали. А еще Blender, которым я достаточно сносно владею, умеет экспортировать в него модели. Однако есть нюанс — STL, создаваемый Blender-ом — это бинарный файл, чтение которого немного отличается от работы с привычными текстовыми файлами (csv, json и так далее). Но для таких оказий в NodeJS есть класс Buffer. А сам бинарный STL снабжен подробной документацией.
Для начала через поставляемый в fs метод open открываем на чтение бинарник, после чего из полученных сведений выбираем поле size и создаем нужный нам буфер для чтения данных.
Это код работы с STL
Ничего особенного, просто каждый раз сползаем еще на 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Интересующий нас график — черный, для сплошной среды. Точки взяты с него
График качества с высоты 85 км (где в полной мере применимы методы сплошной среды) с модельным расчетом. Как и в предыдущем случае, видна уверенная сходимость со средней погрешностью в ~5%. Кстати, обратим внимание на красный и синий графики качества из статьи AIAA — аэродинамическое качество для разреженных потоков быстро уменьшается.
Тест 3. Крыло с тонким профилем
Главное ограничение метода — малые скорости, для которых уже нельзя пренебрегать взаимодействиями между разными участками обтекаемого тела. Особенно это заметно при решении задачи обтекания конуса при малых (M ~2 — 3) скоростях. Здесь метод будет давать завышенные коэффициенты ( особенно сопротивления).
Расчет в диапазоне скоростей M = 2 — 6 (коэффициент подъемной силы от угла атаки)
Красный график — теория тонкого профиля, синий — модельный расчет
Первый график — Мах 2, второй — Мах 4, третий — Мах 6. Угол атаки — в градусах
По предварительным оценкам, полученная модель лучше всего подходит для определения характеристик КА при скоростях M > 3,5 — 4 и для высот до ~ 90 км. Однако расчет показывает хорошую сходимость начиная с M=4, а полученные цифры аэродинамического качества хорошо коррелируют с «барьером Кюхемана» .
Сплошная линия — теоретический предел аэродинамического качества, точки — результаты модельного расчета. По горизонтали — Махи
А теперь — немного хулиганства (и спойлер к циклу следующих статей). Кажется, я начинаю понимать, как нам одолеть Илона Маска. И это — нулевой шаг к захвату мира.
Девайс для захвата мира, если что — то аэродинамическое качество пепелаца порядка 2,7 — 3,5. Ну и мне нравится «Скайлон» как прототип, но мы обойдемся без теплообменников
А пока у меня появился инструмент, позволяющий оценивать характеристики самых разных пепелацев, причем в наиболее интересном с точки зрения атмосферного полета космических аппаратов коридоре высот и скоростей — с достаточно хорошей (~5%) точностью.
Если кому-нибудь интересно, то код живет здесь. Вдруг Вас настигнет творческий порыв, и Вы поможете мне одолеть дозвук, трансзвук и малый сверхзвук.
В жизни каждого проекта наступает тот самый волнительный и незабываемый момент, когда от архитектора требуется только архитектура. Волнительный он по вполне понятным причинам. К этому моменту вы уже столько раз повторяли и уточняли дизайн, что и сами стали верить в эту сказку. А теперь вот раз и надо архитектуру. Не концепции и технологии, а вот прям весь хребет слона, которого будут растить пару лет в инкубаторе, а потом лет 10 на пастбищах по всему миру, пока из резервации он не попадёт в консервацию. Ну а памятным это событие делает тот факт, что все последующие годы вам будут припоминать всё мелкие недочёты, которые почему-то вы не смогли предвидеть. Ведь вам дали неделю, а может даже и целых две на то, чтоб определить направление и основные вехи разработки всех команд на годы вперёд.
Unus pro omnibus, omnes pro uno
И так, контракт подписан и вашей компании выслали официальное извещение о победе на тендере. Теперь пора переходить от теории к практике. Вы работаете в современной компании и все отделы и департаменты давно работают по Agile. То есть их горизонт знаний о проекте ограничен несколькими итерациями. Ну вот эта вот любимая всеми картинка:
Agile development concept
Если бы архитектору дома сказали, что клиенту хватит палатки или может в крайнем случае бытовки, а через год попросили добавить 3 этажа, то он бы, наверное, удивился. Еще сильней он бы удивился, когда еще через год ему добавили требование лифта, еще 5-ти этажей и бассейна на крыше. А чтобы он думал и делал, когда за пару месяцев до сдачи проекта ему сказали, что там еще подземная парковка на 100 машин должна быть – я уж и не знаю. А вот в программной разработке – это всё обычное дело. У нас ведь все такие гибкие и топят за адаптивность, а не выстрелы на опережение (особенно если они уже дорогие, но еще не обоснованные). И если вы просто будете апеллировать к методологии, которая подразумевает не только инкрементальность разработки, но и постоянное корректирование уже созданного, то ваша карьера будет яркой, но не долгой.
Да, сюрприза не получилось. Если не планировать вещи заранее, то всё выходит криво и надо постоянно перестраивать. С одной стороны, никто не хочет тратить год на документацию и детальный план разработки продукта, ведь все мы живём в реальном мире и достаточно хорошо понимаем, что изменения неизбежны и нельзя предусмотреть всё. С другой, очевидно, что если просто бежать, не зная дороги и цели, то шанс в конечном счете оказаться там, где нужно и когда ожидают – ничтожно мал. Так что для начала нужно точно определить, где мы (точку А), и куда должны попасть (точку Б). Слава богу на этапе начала разработки вы уже прошли несколько шагов в нужном направлении и примерно представляем цель и длину маршрута.
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
Что же нужно делать в начале – это инфраструктуру. То, что заказчик явным образом не просит, а значит и добавить её позже будет сложно. Если и не технически, то политически точно. Основа любого проекта – команда. Именно на людях стоит сосредоточится и задать единый язык и шаблон. По законам Мёрфи – если в коде будет плохой кусок, то его обязательно выберут как пример и размножат бесчисленное количество раз. Обговорите с разработчиками структуру проекта, названия и, если нужно, стилистику кода. Многие считают нейминг не важным, но в долгой разработке у всего есть дополнительный вес. Единый язык продуктового отдела и разработчиков, увековеченный в коде, сильно упрощает поддержку и модификации. Представьте, что вам на рабочий стол попал проект в пару сотен тысяч строк, десятки сервисов и баг, который говорит, что расчёт потенциала не верен. Если поиск в базе кода и системе планирования/отслеживания задач с ключевым словом «потенциал» ничего не даст, то вас ждут долгие часы выяснения правильного сценария и пошаговой отладки бизнес-процесса, разбросанного по куче модулей. Вам кажется, что пример высосан из пальца, но мне не раз доводилось самому копаться в подобном, пахнущем кислой радугой, проекте. Обилие синонимов, всяких акронимов и аббревиатур сделает вашу жизнь еще сложнее.
Всё, что нужно делать вручную, будут игнорировать так или иначе. Начало проекта – начало автоматизации. Тут и юнит тесты (для правильного дизайна и возможности рефакторинга), и интеграционные тесты (для стабильности проекта и уменьшения time-to-market), и метрики кода (всевозможные KPI) – всё часть CI-CD. Игры в микросервисы с ручной настройкой и развёрткой оставим мазохистам. Нам необходима команда DevOps. Формально или нет, но кто-то должен быть ответственным за правильную конфигурацию и установку среды. Среды разработки, среды проверок, среды интеграции и т.д. Иначе в будущем вместо среды вас будут ждать суббота и воскресенье разработки и проверки. В производственных системах редко можно найти изолированные бизнес-кейсы. Все микросервисы должны будут взаимодействовать друг с другом и между ними будет явная или не явная зависимость. Устранить этот недостаток можно еще одним уровнем абстракции! Cервис – оркестратор сервисов. Тот, что вызывает цепочку других сервисов, чтоб обеспечить необходимый результат.
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-х «С» — сквозных системных служб. И, как всегда, создаётся впечатление, что это понимаете вы и пара инженеров, но не управленцы.
Если всё получилось, то «земля, прощай» и в добрый путь.
В данной статье хочу поделиться настройкой 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 адресах.
На Leaf коммутаторах настраиваем нужный address family. Для m-lag пары хочется сделать политику подменяющую next-hop на anycast loopback ip адрес, но без такой политики все работает. Huawei подменяет next-hop адрес на адрес который указан в качестве source ip адреса интерфейса NVE. Но если вдруг возникнут проблемы с автоматической подменой всегда можно навесить политику руками:
<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.
В конфигурацию 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 и привести некоторые команды необходимые в процессе отладки.
Кто из нас не пользовался читами в играх? 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. Приходите, будет сложно, но занимательно.
Узнайте, как прокачаться и в других специальностях или освоить их с нуля:
Ранее мы рассказали о трех «бюджетных» парах систем полочного типа. Этот материал набрал более восемнадцати тысяч просмотров и около трех десятков комментариев, поэтому сегодня продолжим анализировать базовый ценовой сегмент полочников и посмотрим на обзоры моделей, которые идут бок о бок с теми, что попали в предыдущую подборку.
На фотографии: 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
Похожие технологии реализованы и в дюймовом высокочастотнике. Он закрыт оригинальной защитной сеткой. Однако производитель поставляет в комплекте и общую защиту на магнитных фиксаторах, охватывающую переднюю панель колонки [с правой стороны на фотографии выше]. На задней ее части находится фазоинвертор 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
ВЧ-динамик обладает диаметром 29 мм. Он тоже установлен на шасси, защищающее его от вибраций. Возможное максимальное звуковое давление этой системы — 106 дБ, что более чем достаточно для обычных комнат в квартире и подключения к домашнему кинотеатру.
В комплекте присутствуют сетчатые экраны со скругленными углами для фронтальной части акустики. Они различаются по оформлению в зависимости от вида отделки системы.
Дополнительные обзоры на английском — первый и второй.
