Записки IT специалиста

TDP – суровая действительность В молодые годы, а я только-только пришел на работу в компьютерную фирму и стал более-менее свободен в финансах, чтобы позволить себе купить не топовую, но более-менее современную систему, приключилась со мной эта история. А рассказать я ее решил именно потому, что многие комментаторы в заметках про TDP сводили все именно к процессору, что в корне не верно. Итак, был у меня компьютер, а сердцем того компьютера был процессор Intel Pentium 4 3 ГГц на ядре Northwood. Довольно горячий камень, надо сказать. Но далеко не такой производительный, как бы мне хотелось. Денег радикально поменять платформу у меня не было, хотя тот же Athlon XP 3200+ выглядел крайне привлекательно, но уже не за горами были многоядерные Intel и 64-битные AMD, и я решил подождать новинки. А что делать с текущей системой? Правильно – разогнать. В те времена это было одновременно и проще, и сложнее. Проще – потому что технических ограничений было меньше, а сложнее – информации про разгон также было крайне мало, а интернет еще не был так распространен. Компьютер был у меня неплохой, не топовый, но собран с запасом из надежного железа, которое показало свою надежность в реальных сборках, которыми мы торговали. В общем неделю я урывками на рабочем месте собирал информацию в сети по разгону и потом только приступил к воплощению своих идей в жизнь. Но реальность быстро мне показала, что наши желания далеко не всегда совпадают с нашими возможностями. Процессор мертво застрял на отметке 3200 МГц, уходя по температуре в жестокий троттлинг. Что надо сделать? Правильно – купить кулер побольше, что я и сделал, модель уже не помню, но это было что-то из суперкулеров от Thermaltake, одна из самых дорогих и эффективных моделей. И дело пошло! Я потихоньку поднял тактовую частоту до 3500 МГц, добился стабильной работы и приготовился двигаться дальше. Через пару часов покорились 3700 МГц и я запустил стресс-тест. Ничего не предвещало беды, но вот раздался громкий хлопок из-под стола, и квартира погрузилась во тьму, одновременно наполнившись ни с чем не сравнимым запахом горелой электроники. Как человек с профильным образованием (инженер связи) я уже понял, что произошло, выдернул ПК из розетки и пошел включил автомат в щитке. Последствия разгона меня очень сильно огорчили. Во-первых, взорвался блок питания, ключевые транзисторы там просто порвало, а цвет текстолита под их ножками говорил о том, что в режиме перегрева они находились достаточно длительное время. Во-вторых, разъем доппитания 12 В полностью расплавился, намертво прикипев к плате, текстолит вокруг VRM сильно потемнел. Процессор намертво приплавился к сокету, но вот с ним ничего страшного и не произошло. Да и приплавился не сам процессор, а некоторые его ножки, по которым шел ток питания, сам кристалл так и не перешагнул планку в 90 градусов. Процессор сняли, нагрев сокет паяльным феном, материнская плата и блок питания на выброс. Плюс очередные траты на замену, которые оказались совсем-совсем не кстати. Так не кстати, что вместо материнской платы на чипсете Intel пришлось брать убогонький и куда менее производительный SiS. А для себя я сделал выводы, что никогда не нужно рассматривать систему только через один ее параметр или характеристику. Иначе получится классическое: одно лечим – другое калечим. Хотите разогнать? Разгоняйте, но перед этим убедитесь, что все компоненты системы выдержат такой режим, а не только один процессор.

Кинопоиск до 360 дней бесплатно Кинопоиск — тысячи фильмов и сериалов без рекламы, в высоком качестве. Яндекс Музыка и Книги тоже в мультиподписке Плюс. Попробуйте бесплатно ❤️ Попробовать #реклама 18+ kinopoisk.ru О рекламодателе

TDP – заблуждения и реальность. Продолжение В прошлой заметке мы разобрали общие вопросы касающиеся TDP и регулировки производительности процессора. Сейчас немного углубимся в детали. Разбирать будем на примере Intel, так как данный производитель имеет часть документации, касающейся этого вопроса в свободном доступе, AMD разглашает меньше подробностей, но в целом принцип и там и там одинаков, отличаются лишь детали реализации. Еще раз напомним, что TDP – это всего лишь рекомендация по выбору системы охлаждения и данный параметр не отражает реального потребления процессора. Реально же используются значения PL1 и PL2. PL1 – пороговое значение средней долговременной мощности. Его не рекомендуется устанавливать выше TDP и обычно эти значения равны. PL2 – пиковое значение мощности которое может быть кратковременно достигнуто. При превышении этого значения вступаю в дело алгоритмы ограничения мощности и путем регулировки частоты и напряжения удерживают мощность в рамках этого значения. Но есть один тонкий момент. Нижний предел охлаждения у нас находится на уровне PL1 (который не должен превышать TDP) и, следовательно, процессор должен уметь длительно работать с радиатором, рассеивающим указанную мощность. Проще говоря, для условного процессора с 95 Вт TDP пользователь может купить кулер, на коробке которого указаны те же 95 Вт и не испытывать проблем. А дальше представляем себе бассейн и две трубы, по одной в него приходит вода, по другой уходит. Радиатор всегда рассеивает свой TDP, т.е. у нас в единицу времени уходит мощность PL1. Но тут мы открутили вентиль и начали наливать в бассейн воду в объеме PL2 за ту же единицу времени. Как долго мы можем работать в таком режиме? Очевидно, что пока не переполнится бассейн, а это зависит от его объема и его свободной части. У радиатора это зависит от теплоемкости. Но как правильно определить доступный объем? Для этих целей Intel использует специальный параметр Turbo Time (Tau), который рассчитывается по экспоненциально взвешенному скользящему среднему (EWMA) и определяет время, которое процессор может находиться в режиме от PL1 до PL2. Если мы сразу выходим на мощность PL2, то это время будет равно 8 секундам, при меньших показателях мощности оно будет иным, меняющимся не линейно, а по экспоненте. После чего процессор возвращается на уровень PL1 и не превышает его до тех пор, пока нагрузка не опустится ниже определенного значения за определенное время. Если вернуться к аналогии, то рассчитав примерное время наполнения бассейна система ждет пока он гарантированно сольется. Это позволяет избежать перегрева не только процессора, но и элементов питания материнской платы, которые также ориентируются на значения TDP. У AMD примерно все тоже самое, только существует еще один ограничивающий фактор в виде температуры ядра, который также начинает ограничивать производительность даже до достижения PL2. А в особо запущенных случаях процессор даже не будет пытаться разгоняться. Понятно, что все эти показатели высчитаны из расчета, что будет применяться самый слабый радиатор и подсистема питания также будет впритык. Но как быть обладателям дорогих материнских плат с мощным питанием и суперкулеров? Для них производители предусматривают в BIOS специальные режимы, например, у Gigabyte он называется, как: 🔸 *Enhanced Multi-Core Performance* Allows you to determine whether to apply the highest Turbo ratio to all CPU cores Которое фактически изменяет лимиты PL1, PL2 и Tau с общим расчетом на то, чтобы процессор мог большее время находится в разгоне. На дорогих платах таких настроек может быть несколько, точнее несколько градаций настроек, скажем, как «умеренно, максимально, ультра». Китайцы и вовсе пошли впереди планеты всей, на некоторых платах может быть вовсе снят лимит с PL2, а то и с PL1, точнее установлен в значение 4096W, чтобы корректно работал расчет Tau. К чему это может привести догадаться несложно. Если вы не обеспечили эффективного охлаждения и дали предельную нагрузку, то от платы может пойти волшебный дым.

Yandex Ecom Open Air — летнее событие про онлайн-продажи Yandex Ecom Open Air 2026 объединяет деловую программу, живое общение и атмосферу фестиваля в одном потоке. Здесь обсуждают технологии, которые становятся частью среды. Исследуют силы, которые влияют на весь рынок. Находят новые связи, идеи и точки роста. В течение дня пространство фестиваля наполняют выступления, дискуссии, встречи, специальные форматы, музыка и активности партнёров. Присоединиться к происходящему можно из любой точки — на площадке фестиваля или через онлайн-трансляцию. Зарегистрироваться #реклама 18+ ecomfest.ru О рекламодателе

TDP – заблуждения и реальность TDP (Thermal Design Power) активно используется при обсуждении потребления процессоров и другой электроники. При этом данный показатель часто путают с максимальной рассеиваемой мощностью или потребляемой электрической мощностью. Однако это не так, TDP является требованием по выбору системы охлаждения и отражает некую среднюю рассеиваемую мощность на усмотрение производителя. Так Intel определяет его как: ▫️ Расчетная тепловая мощность (TDP) представляет собой среднюю мощность в ваттах, которую процессор рассеивает при работе на базовой частоте со всеми активными ядрами в условиях определенной Intel сложной рабочей нагрузки. В AMD несколько иной, но тоже очень схожий подход: ▫️ TDP — это максимальная устойчивая мощность, которую процессор может потреблять с помощью «реального» программного обеспечения при работе в определенных пределах температуры и напряжения. При этом и те и другие говорят о некой «реальной» нагрузке ими самими и определенной. Также следует отметить, что TDP рассчитывается для базовой частоты процессора, просто Intel говорит об этом прямо, а AMD несколько завуалировано. Таким образом TDP не показывает ни реальной потребляемой мощности, ни реальной рассеиваемой тепловой. Это некий средний показатель, который призван помочь вам выбрать кулер. Т.е. если вы на процессор с TDP 100 Вт поставите кулер способный рассеивать такую мощность, то ваш процессор при среднестатистической нагрузке перегреваться не должен. Ключевое слово здесь – не должен. На самом деле вся система работает немного не так. То, что публикуется как TDP есть ни что иное как определенный лимит мощности для устойчивой долгосрочной работы. Но есть еще один, второй лимит мощности, который указывает какую мощность допустимо потреблять процессору в турбо-режиме и как долго он может это делать. У Intel эти параметры так и называются PL - Power Limit, PL1 и PL2. Их оба можно найти в документации, первый равен указанному на коробке TDP процессора, а второй указывает максимально потребляемую в турбо-режиме мощность. Например, у Core i7-14700K это 125 Вт и 273 Вт. Разница, согласитесь, впечатляющая. AMD публикует только PL1, он же TDP, максимальную мощность можно узнать только из неофициальных источников. Так для того же R9 5900X цифры составляют 105 Вт официальной рассеиваемой мощности и около 145 Вт максимальной. Схема работы при этом примерно такая, при увеличении нагрузки процессор разгоняется таким образом, чтобы потребляемая им мощность не превысила значение второго лимита мощности. Пока это значение не достигнуто процессор может продолжать работать на более высоких частотах, по достижению второго лимита мощности процессор должен через некоторое, достаточно небольшое время, вернуться к первому лимиту и работать в нем, пока не будет снята нагрузка. Штатная цифра для процессоров Intel – 8 секунд. Рассчитана она исходя, опять-таки, из некоторых средних представлений Intel и подразумевает использование стокового охлаждения. В целом посыл ясен – кратковременно процессор может достигать максимальной потребляемой мощности, но нахождение его в этом состоянии лимитировано. Это обусловлено тем, что ни штатная система охлаждения, ни штатная система питания могут быть не рассчитаны на долговременную высокую нагрузку. Но данные параметры не являются догмой и, тем более, нигде жестко не прошиты. Они доступны для регулирования в BIOS и производители материнских плат и готовых компьютеров могут настраивать эти параметры согласно собственным представлениям. Чаще всего такие настройки существенно увеличивают возможность процессоров работать по достижении второго лимита мощности, не возвращаясь к первому, т.е. практически все время находиться в турбо-режиме. Ну а почему бы и нет, если производитель знает, что система питания платы это позволяет. Производители мобильных устройств могут, наоборот, прикрутить как лимиты, так и время нахождения в турбо-режиме ради снижения тепловыделения и экономного расхода заряда аккумулятора.

Модуль ядра Linux. Как его написать, собрать, запустить 📅 3 августа в 20:00 МСК 👌 Бесплатно. Урок в рамках старта курса «Разработка ядра Linux». На открытом уроке мы подробно обсудим инструменты и методы, необходимые для разработки, а также поделимся реальными примерами и практическими советами. Зарегистрироваться #реклама 16+ otus.ru О рекламодателе

Как я тянул свою первую сеть В начале нулевых, на самой заре своей трудовой деятельности я работал в одном бюджетном НИИ инженером, фактически выполняя задачи системного администратора. Почему инженером? А потому что в штатном расписании не было системного администратора и появился он там очень нескоро. И вот встал вопрос создания первой в организации локальной сети, пока что в масштабах бухгалтерии, но все как надо – на витой паре. В один не очень прекрасный день мне выдали бухту кабеля, стопку кабель-каналов и иного сетевого оборудования и сказали – вперед! - Это как, вперед? – не понял я, - а сеть кто тянуть будет? - А в чем проблема? – удивился мой начальник, - сеть какая? Компьютерная. А кто тут по компьютерам? Я немного удивился такой постановке вопроса и попытался пояснить, что сеть – это та же слаботочка, у нас в штате есть электрик, который как раз и может таким заняться, а к нему можно добавить в помощь сантехника, который один фиг днями спит в своей каморке. Если бы это не был бюджет или руководство было бы более гибким (скажем так), то вопрос можно было бы решить легко и просто – за премию они бы сами все протянули и добавки бы попросили. Но увы и ах, финансовым поощрением там и не пахло. А дальше вступает в силу типично бюджетная фишка: они делают вид, что платят – мы делаем вид, что работаем. При этом все это всегда прикрывалось имитацией бурной деятельности. Но я был тогда молодой, зеленый и все мои понятия о производственных процессах были далеки от реальности. В итоге мой начальник отправил меня к их начальнику просить на завтра две единицы рабочей силы. Их начальник не возражал, а наоборот вызвал и поставил задачу – помочь молодому инженеру завтра с прокладкой сети. А на завтра случилось неожиданное: в подвале внезапно «забил фонтан» и сантехник оказался ну очень сильно занят, электрик задумчиво смотрел в полуразобранный щиток и идти тянуть сеть они наотрез отказались. Ну как так? Я к их начальнику. А он мне доходчиво пояснил, что в их должностной инструкции нет ничего про компьютерные сети и они согласились помочь сугубо по причине наличия свободного времени, а так как у них появилась собственная работа, то извини… Я к своему начальнику, тот повторил мне тоже самое. Тогда я спросил, а как же моя должностная инструкция, после чего мне доходчиво пояснили, что я вообще здесь на птичьих правах, ибо взят сугубо из жалости ко мне и гуманизма и если посмотреть в мою должностную инструкцию, то меня можно хоть сегодня выгонять за профнепригодность. Возразить тут было нечего. Разве что надо было пояснить, что это ни они меня взяли из жалости, а я из жалости к ним пришел (что по факту так и было), но я был молод, зелен и смирившись пошел тянуть сеть. Выдали мне оранжевую советскую дрель, ни разу ни ударную и два тупых победитовых сверла. Сверла грелись, гнулись, после чего я их выравнивал молотком на ступеньке лестницы и шел назад бороться с бетонной стеной. Но силы были явно не равны. Пошел к начальнику и попросил хотя бы купить новые сверла. На что получил ответ, что для того, чтобы купить новые, надо списать старые, а они вполне еще ничего, все сверлят, никто не жаловался. Поняв, что я тут просто лягу костьми еще на первом десятке отверстий я в обеденный перерыв поехал домой и привез нормальный перфоратор. Взамен я получил порцию ворчания от начальника, мол молодежь никуда не годится, все сверлили, никто не жаловался, а этому перфоратор подавай. С перфоратором дело пошло веселее и к вечеру я основной объем монтажа закончил. А на утро меня встретили ухмыляющиеся сантехник и электрик и поинтересовались как мне вчера работалось. Потом отвели в сторонку и пояснили мне, что я эпический долбоящер. Основной смысл их речи был прост: ты же инженер, у тебя же есть спирт… Но это уже совсем другая история…

Dell PowerVault ME5 — ME5212, ME5224, ME5284 Основные ошибки, которые мы видим регулярно в проектах: • Забывают про внешние полки ME584 и ME512 пытаясь получить максимум объема в рамках одной СХД; • Ставят ME5212 под транзакционные базы — через полгода задержки • Выбирают all-flash ME5224 туда, где половина емкости идет под холодный архив Каждая такая ошибка обходится дорого. А с ростом цен на NAND в 3 квартале 2026 (до 10-15% по прогнозу TrendForce) — обойдется дороже. Подготовили полный разбор: какая ME5 под какую задачу, как состыковать SSD и NL-SAS без потери скорости, три причины перейти с ME4 уже сейчас. Узнать больше #реклама О рекламодателе

С днем системного администратора! Сегодня профессиональный праздник, который в общем-то сильно и не праздник. Во всяком случае какого-то массового масштаба он не имеет. Равно как и многие подобные праздники. Почему так? Возможно, во многом по причине молодости этой профессии и отсутствия массовых скоплений админов на единицу площади. Даже возьмем типичный IT-отдел. Там все поголовно админы? Да нет, вон та парочка, а тут еще пара программистов, сетевик и аналитик. А если посмотреть на эту фирму, в общем и целом, где выяснится, что фирма строительная – то все они строители. И День строителя будут отмечать все вместе и с размахом. Но никто не будет устраивать праздничные мероприятия ради пары администраторов. Точно такая же ситуация и со многими другими узкими профессиями. Тот же день бухгалтера тоже отмечается в основном поздравлениями друг дружке в мессенджерах, и даже в аудиторских или аутсорсерских бухгалтерских фирмах редко устраиваются народные гуляния – нет традиции. Плюс старая гвардия пришла в профессию кто откуда, тогда и специальности такой не было, поэтому привыкла отмечать свои профессиональные праздники, по основной профессии. Я, например, как связист по образованию всегда отмечаю День Радио. Но праздник есть праздник, и нужен он в первую очередь не нам, а нашим коллегам, работу которых мы обеспечиваем на «невидимом фронте», чтобы они еще раз вспомнили, что, когда у них все хорошо – это заслуга того самого парня. Об этом говорит сама история этого праздника, его решил основать администратор с 20-летним стажем Тед Кекатос из Чикаго, который таким образом решил напомнить коллегам о важности своей работы и изначально он назывался «День благодарности системному администратору». Было это в далеком 2000 году, а для кого-то не таком уж и далеком… Правда, тогда и слова то такого и не знали, для клиентов и людей далеких от IT все мы были «программисты». А слово «администратор» более ассоциировалось с администратором отеля или ресторана. Сейчас слово сисадмин всем понятно, но ограничивать праздник только одними сисадминами – это неправильно. Вокруг куча коллег без своих праздников, вы слышали про День DevOps? Вот и я не слышал. Поэтому, как мне кажется, правильно будет основать один общий праздник – День работника IT, который объединит всех причастных под единым знаменем и позволит отмечать его действительно массово. Потому что, отмечая День строителя или День работника торговли отмечают все, начиная от строителей и продавцов, заканчивая бухгалтерами и айтишниками, потому что все они причастны к общему. Так и День айтишника должен объединить всех: кто админит, кто пишет код, пишет промпты, проектирует сети, тянет их и даже подметает пол в серверной. И я не шучу, когда я работал в компьютерной фирме была у нас уборщица – Тетя Шура – бодрая бабулька лет 60, так за пару лет с нами она получила базовое IT-образование и утром вполне могла озадачить вопросом: - Жень, у тебя в мусорном ведре SATA-кабель валяется, на вид целый, ты его выкинул или просто уронил? Ну чем не работник сферы IT? А полы тоже мыть кому-то надо, или грязью и пылью зарастем. Дело важное и дело нужное, без шуток. Но это мысли. А пока – с ПРАЗДНИКОМ коллеги!!!

Яндекс Музыка до 360 дней бесплатно Яндекс Музыка для вас и 3-х ваших близких. Кинопоиск и Яндекс Книги тоже в мультиподписке Плюс. Попробуйте бесплатно❤️ Слушать #реклама 18+ music.yandex.ru О рекламодателе

Получи грант до 1,35 млн руб. на обучение в магистратуре Хочешь развиваться в сфере ИТ и получить фундаментальные знания с практикой? Поступай в магистратуру Центрального университета! — 4 офлайн программы по востребованным направлениям ИТ — 2 онлайн-программы: машинное обучение и продуктовый менеджмент — 550 грантов до 75% — Вечерние занятия и учеба по выходным — удобно совмещать с работой — Обучение по модели STEM-образования: на стыке науки, технологий и бизнеса — Возможность стажировок и трудоустройства в ведущих компаниях — Государственный диплом за 2 года Магистратура в Центральном университете — это современный подход к образованию, сильный преподавательский состав и актуальные кейсы от индустрии. Оставляй заявку на грант уже сейчас! Зарегистрироваться #реклама 16+ cu.ru О рекламодателе

Обзор российских ОС. Альт Рабочая станция К 11 Продолжаем рассматривать новые версии операционных систем семейства Альт, следующей у нас на очереди Альт Рабочая станция К 11 и это не разновидность Альт Рабочая станция, а отдельная, самостоятельная система, развиваемая по своему сценарию и со своей периодичностью выхода релизов. Можно сказать, что это самая современная и технологически продвинутая система в семействе и на момент написания уже доступна версия 11.4, с которой мы и познакомимся. Мы уже говорили, но скажем снова: несмотря на технологические достоинства с маркетингом у Базальт СПО дела обстоят плохо, это касается и внешнего вида систем (хотя тут начали исправляться), и их именования. Потому что понять из наименования, что это отдельная ОС, а не одна из редакций Рабочей станции решительно невозможно. Ранее Альт Рабочая станция К явно позиционировалась как система для мощных современных ПК, оптимизированная для работы с мультимедийным контентом и предоставляющая самые передовые возможности. Сегодня формулировки немного смягчились и нам просто предлагают комфортную работу в среде KDE и свежими приложениями. Альт Рабочая станция К также входит в Единый реестр российских программ и бесплатна для использования физическими лицами, организации и предприниматели обязаны приобрести лицензию. ✅ Читать далее: https://interface31.ru/post/obzor-rossiyskih-os-alt-rabochaya-stanciya-11k/

⏳ Если планировали поступать в магистратуру в этом году, стоит поторопиться — приемная кампания Университета Иннополис выходит на финишную прямую. 💻 Это хороший вариант для тех, кто хочет серьезно прокачать инженерные навыки и получить практический опыт еще во время обучения. Обучение построено по модели 1+1: 📚 Первый год — фундаментальная подготовка и работа над проектами. 🏢 Второй — практика в компании-партнере, где студенты решают реальные инженерные задачи. Такой формат позволяет еще во время обучения получить опыт коммерческой разработки и выйти на рынок с сильным портфолио. Направления обучения: • ИИ и инженерия данных • Программная инженерия • Робототехника и компьютерное зрение • Инженерия безопасности систем и сетей 💰 Есть бюджетные места, грантовый конкурс и государственная стипендия. 👉 Посмотреть программы и подать заявку можно здесь 👈

Монтирование файловых систем при помощи systemd Казалось бы, монтирование файловых систем в Linux задача простая и не требующая каких-либо доработок. Но очень часто именно в простоте таятся различные сложности и затруднения. Текущая система монтирования уходит корнями еще во времена UNIX и дошла до наших дней без серьезных изменений. Но мир с тех пор серьезно изменился, сегодня в широком ходу сетевые расположения и съемные устройства, работать с которыми классическим образом не слишком удобно. И вот тут нам на помощь снова приходит systemd, предлагая современные методы монтирования файловых систем. ✅ Читать далее: https://interface31.ru/post/montirovanie-faylovyh-sistem-pri-pomoshhi-systemd/

Вы запускаете AI-агента. Сколько он реально стоит в месяц? Мы подготовили калькулятор AI-агента. Он помогает посчитать полную стоимость до старта — от входных токенов до продакшн-инфраструктуры. Что внутри: 🔹формула с учётом количества витков агента 🔹таблицы затрат (минимум и продакшн) 🔹3 готовых примера (чат-бот, мониторинг 24/7, CI/CD) 🔹способы снизить расходы на 40–70% Забирайте калькулятор, чтобы не получить неожиданных счетов👇 ЗАБРАТЬ КАЛЬКУЛЯТОР

Система отслеживания состояния соединений conntrack, часть 2 В прошлой части мы разобрали состояние NEW и ESTABLISHED, сегодня поговорим об более интересных состояниях. Начнем с RELATED, вроде бы просто – это соединения, связанные с уже установленным соединением. Но если начинать разбираться, то вопросов становится больше, чем ответов. Что такое связанное соединение? Это новое соединение, которое является частью уже существующего, хорошие примеры таких протоколов – это FTP, PPTP или SIP. Для них характерно наличие управляющего соединения и связанных с ним соединений для передачи данных. Важно понимать и то, что связанное соединение может быть инициировано как изнутри, так и снаружи, при этом порт передачи данных обычно выбирается динамически, что создает проблемы с фильтрацией таких соединений. Поэтому conntrack как-то должен понять, что это не самостоятельное соединение, иначе оно получит состояние NEW и пойдет в брандмауэр со всеми вытекающими. Для этого он при помощи специальных модулей ядра ipconntrackNNN анализирует данные управляющих протоколов и на их основании выделяет связанные соединения. Если новый пакет соединения, определенного как связанное попадает в брандмауэр, то ему присваивается состояние RELATED. После того, как на этот пакет будет получен ответ связанное состояние перейдет в состояние установленного – ESTABLISHED. Таким образом RELATED – это аналог состояние NEW, но только для связанных соединений, установленных соединений с таким статусом не бывает. Все установленные соединения только ESTABLISHED. Если у вас пакеты связанного соединения не определяются как RELATED, то это может говорить о том, что отсутствует загруженный модуль для работы с используемым протоколом. И последнее состояние соединения – INVALID. Очень часто оно трактуется и понимается неправильно. Скажем нам пришел TCP-пакет уже установленного соединения, но в таблице трассировщика данные о таком соединении отсутствуют. Перед нами типичный INVALID? Вовсе нет. Если корректно указаны все необходимые поля пакета, то он получит состояние NEW. Об этом мы говорили вчера, такое поведение позволяет подхватывать уже установленные соединения без обрыва сеанса связи. Что касается UDP, то там каждый пакет является первым, так как протокол не подразумевает установку соединения. Тогда что такое INVALID? Это пакет, который не может быть идентифицирован, например, имеет некорректно заполненные поля или поврежден. Также сюда относятся ICMP-ответы, для которых отсутствуют соединения породившие запросы. Напоминаем, что для типов ICMP подразумевающих ответы создается соединение с состоянием NEW и переходит в ESTABLISHED и закрывается только после получения ответа. Поэтому если есть ответ, но нет соответствующего ему соединения, то такой пакет будет помечен как INVALID. Также подобное состояние мы можем получить и для вполне легальных пакетов при недостатке ресурсов брандмауэра, например, закончилась свободная память или высокая нагрузка на процессор, перегрев и т.д. Поэтому INVALID не указывает на однозначно вредоносные пакеты, а говорит о том, что conntrack не смог разобраться с идентификацией пакета и резкий всплеск получения подобного состояния может указывать именно не недостаток ресурсов, а не сетевую атаку. В тоже время пренебрегать блокированием INVALID тоже не стоит, так как позволяет эффективно защититься от ряда атак, чаще всего через поддельные ICMP-ответы. Но, повторимся, INVALID – это не только неправильный пакет, а любой, который conntrack по какой-либо причине не смог идентифицировать. Непонимание этого может заставить искать вас черную кошку в темной комнате, которой там нет (сетевую атаку), вместо того, чтобы проверить режим работы оборудования.

🚀 Мечтаешь войти в DevOps, но не знаешь с чего начать? Это твой шанс! Привет, меня зовут Вячеслав Федосеев. Я работаю руководителем команды в DevOps, выступаю как спикер в учебном центре Слёрм и веду собственный проект DevOps Bootcamp. У себя в Telegram-канале я регулярно провожу прямые эфиры, публикую полезные статьи и лекции, а главное — отвечаю на вопросы и помогаю новичкам сделать первые шаги в профессии. Присоединяйтесь, чтобы не пропустить самое интересное! 👉 Канал: @devopsupgrade 🔥 Бонус для начинающих Вместе с командой Слёрм мы подготовили бесплатный мини-курс«Быстрый старт в DevOps». На нём разложим по полочкам главные темы, которые волнуют новичков: 👉 что такое DevOps, и как выстроить работу команды в рамках этой методологии; 👉 Kubernetes, Docker и т.д.: как базовые инструменты выстраивают работу в DevOps; 👉 DevOps и компания: как состыковать критерии успеха. ЗАБРАТЬ БЕСПЛАТНЫЙ КУРС

Система отслеживания состояния соединений conntrack, часть 1 Conntrack – важная часть сетевого стека Linux ответственная за определение сетевых соединений и связывания с ними конкретных пакетов. На основе состояния соединения строится логика работы брандмауэра netfilter, а также высокоуровневых интерфейсов к нему, таких как iptables и nftables. Несмотря на видимую простоту с работой conntrack связано множество заблуждений и в этой заметке мы постараемся разобрать некоторые из них. Прежде всего соединения conntrack, равно как и их состояния существуют сугубо в пределах брандмауэра и нигде более. Кроме того, это исключительно Linux-технология и в среде других ОС она не применима. В рамках пользовательского пространства доступно четыре состояния, это всем известные NEW, ESTABLISHED, RELATED и INVALID. Трассировка соединений происходит в цепочке PREROUTING или OUTPUT, если пакет был порожден локальным процессом. Первый пакет соединения получает статус NEW. И вот здесь есть один важный момент, как conntrack определяет, что этот пакет первый. Например, для TCP мы можем ориентироваться на флаг SYN, но как быть с UDP, где каждый пакет, по сути, первый и последний? Тут все просто, анализируется адрес и порт источника, адрес и порт приемника и если такой записи в таблице трассировщика нет, то пакет становится первый и ему присваивается состояние NEW. Таким образом если в брандмауэр придет TCP пакет уже установленного соединения (без SYN), то conntrack все равно повесит ему состояние NEW и отправит дальше по цепочкам. Это позволяет подхватывать уже установленные TCP-соединения если таблица трассировщика была утеряна (скажем мы перезагрузили роутер). Что будет с пакетом NEW дальше? Он пойдет по цепочкам брандмауэра и будет либо пропущен, либо отброшен. С отброшен все понятно, соединение было отвергнуто с нашей стороны и все повторные попытки соединения снова получат состояние NEW. А вот если пакет был пропущен, то ему присваивается состояние ESTABLISHED? А вот и нет. Для перехода соединения в состояние ESTABLISHED требуется, чтобы через conntrack прошел ответ на этот пакет. И только при наличии ответа узла состояние соединения перейдет в установленное – ESTABLISHED. Причем данное состояние устанавливается как для TCP, так и для UDP, хотя последний в принципе не подразумевает установление соединений. Но, напоминаем, все эти соединения живут только внутри брандмауэра Linux и никак не отражаются в самих пакетах. Для времени жизни UDP соединения используется таймаут, если за указанное в нем время через соединение не прошел ни один пакет – оно считается закрытым. Если пакет прошел – то таймаут сбрасывается и начинается новый отсчет. С TCP все немного сложнее, при нормальном завершении соединения после получения FIN соединение в брандмауэре переходит в состояние TIME OUT (буферное время) и еще в течении некоторого времени считается ESTABLISHED. Это сделано для того, чтобы через брандмауэр могли пройти пакеты «застрявшие» где-то там по дороге. Если соединение было закрыто по RST, то оно сразу переходит в состояние закрытого без выделения буферного времени. При аварийном завершении TCP-соединения его состояние в conntrack будет ESTABLISHED до истечения тайм-аута. Еще интереснее с ICMP, может ли ICMP быть ESTABLISHED? Может, и даже становится. Почему? Потому что многие типы ICMP подразумевают ответ на запрос. Поэтому пришедший ICMP пакет получит состояние NEW, а ответ на него переведет соединение в состояние ESTABLISHED. Однако conntrack понимает, что дальнейшей передачи данных такое «соединение» не подразумевает и после прохождения ответного пакета через netfilter запись о соединении из таблицы трассировщика удаляется.

Партицирование и индексы: миллиарды строк без тормозов Узнайте, как партицирование и индексы ускоряют миллиарды строк. Регистрирация! 19 .08 Узнать больше #реклама 16+ otus.ru О рекламодателе