Администрирование

Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Недавно я написал две статьи, посвящённые настройке /etc/config/wireless в OpenWrt. В одной я разобрал настройки секции wifi-device, а в другой wifi-iface. Но этого оказалось мало, и в комментариях меня спрашивали о тонкостях настройки mesh-сети. Что ж, спешу выполнить эту просьбу и представляю на ваш суд наиболее полный гайд, посвящённый сборке и настройке Wi-Fi mesh-сетей на базе OpenWrt.

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

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

Второе. Статья получилась достаточно большая и может вас утомить. Я долго сомневался, стоит ли делать большую статью или всё же разделить на разные темы. Например, вынести отдельно часть про роуминг и отдельно про настройку конфигов. Но в итоге решил, что полезнее будет иметь полное руководство в одном месте. В конце концов, главная цель этой статьи показать, что при должном уровне настройки беспроводные mesh-сети ничуть не уступают кабелю. Мне по роду занятий часто приходится слышать замечания коллег, которые говорят: «Да всё беспроводное и mesh это фигня, нет ничего лучше кабеля. Вот я купил домой mesh-систему всего из трёх узлов, а она не работает как нужно». Забегая вперёд, хочу сказать, что если всё сделать как надо, можно добиться небывалой производительности. Не без гордости могу заявить, что в моём арсенале есть mesh-сети, состоящие из более чем 50 узлов, построенные исключительно на OpenWrt и без использования внешних контроллеров.

Если у вас стоит Always On Availability Groups, вы наверняка бывали в такой ситуации: в SSMS всё зелёное, дашборд показывает «Synchronized», а пользователи звонят с жалобами на тормоза. Смотришь на secondary — а там redo_queue_size 600 МБ, реплика отстаёт на полчаса. Ни одного алерта.

У нас это случилось на продуктивном кластере с 1С: secondary молча отвалился в SYNCHRONIZING, а мы узнали только при плановом переключении. Полтора часа redo queue. Стало понятно, что встроенный дашборд SSMS — это не мониторинг. Дальше — как мы это закрыли Zabbix'ом за вечер.

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

Чтобы пакет добрался из точки А в точку Б через государственную границу — через барьер, через фильтр, через ограничение — по ту сторону должен быть кто-то, кто готов его принять. Узел. Человек. Связь. Сеть держится не на протоколах — она держится на доверии между людьми, которые решили её построить. Протокол — это язык. Но прежде чем говорить, нужно захотеть слушать друг друга.

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

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

Всем привет! Меня зовут Эрик, я инженер технической поддержки в Ринго. Сегодня поговорим об истории операционной системы macOS. О том, как она развивалась с 1989 года и стала одной из самых технологически зрелых ОС на рынке и что происходит с ней прямо сейчас.

macOS — операционная система для компьютеров Mac, разрабатываемая Apple с начала 2000-х годов. macOS лежит в основе всей экосистемы Apple на стороне рабочих станций. Она тесно интегрирована с iOS, iPadOS, watchOS и tvOS, а её архитектурные решения напрямую влияют на то, как устроены iPhone и iPad.

Если коротко, macOS — это Unix-подобная операционная система с открытым ядром, богатой историей архитектурных переходов и одной из самых строгих в индустрии политик обратной совместимости. 

Пытаемся найти логику в очередном наезде Трампа и Карра на иностранные гаджеты.

Вы наверняка слышали: правительство США запретило потребительские Wi-Fi роутеры иностранного производства из-за «угроз национальной безопасности».

И вы, скорее всего, задаетесь вопросом: «Что за фигня происходит?»

Обычные будни в Америке времен Дональда Трампа и председателя FCC (Федеральной комиссии по связи) Брендана Карра. Пока что вам, скорее всего, ничего не грозит, но если хотите понять, откуда столько шума — читайте дальше.

Transform processor в OpenTelemetry часто воспринимается как «универсальный костыль» на случай, когда стандартных процессоров уже не хватает. В итоге в конфигурации появляются OTTL-инструкции, которые вроде бы корректны, но ведут себя непредсказуемо: условия не срабатывают, поля не меняются, данные теряются без явных ошибок.

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

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

Из того, что активно обсуждается в сообществе: возможно появление чего-то вроде «государственного VPN» — для доступа к сервисам, которые де-факто не запрещены, но не могут нормально работать в условиях текущих ограничений. Более прагматичным мне кажется другой сценарий: серия сделок между крупными игроками и государством, в обмен на сотрудничество. Полуофициальные договорённости в серой зоне, назначение «уполномоченных операторов».

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

Привет, Хабр! На связи Александр Усов, системный инженер в K2Tex. В своей предыдущей статье я уже делал подробный обзор фич ALD Pro и их особенностей, с которыми регулярно сталкиваюсь. Сегодня хочу поделиться тем, чему мы учим администраторов заказчиков: как реально эксплуатировать эту систему, а не просто развернуть и оставить на холостом ходу. Разберу, как устроены «расширенные атрибуты» и почему следует избегать одинаковых названий отделов в оргструктуре, какую функциональность ALD Pro унаследовал от FreeIPA, а в чем превзошел, и каким образом эффективнее организовать журналирование событий.

Знаете, что общего между щенком лабрадора и корпоративным AI-проектом? Оба сначала кажутся милыми и недорогими, а через полгода жрут столько, что хочется плакать. Только щенок хотя бы ласкается, а нейронка просто молча выставляет счет за GPU. В этой статье мы вместе с Александром Меркушевым (AI-консультант, архитектор облачных и AI решений, руководитель экспертной группы по внедрению ИИ в Яндексе) разбираемся, как AI меняет структуру инфраструктурных затрат, что с этим делать уже сейчас и, главное, поможет ли тут FinOps.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

«Бди!» — сказал Козьма Прутков. И действительно, как инженер я считаю важным бдительно следить за показателями сетевых устройств, да и не только сетевых. На связи Александр Балезин из отдела сетевой разработки Yandex Infrastructure. Сегодня расскажу о нашем новом коллекторе метрик с сетевых устройств, о том как мы к нему пришли и о системах вокруг сетевых метрик.

Начиная работать с Podman, я задал себе вопрос — функционирует ли healthcheck в Podman так же, как в Docker? Да и нет. В этой статье разберем, зачем он вообще нужен, какие бывают типичные ошибки при запуске контейнера с healthcheck, выясним детали о systemd и Quadlet.

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

Эта история заставила меня остановиться и подумать. Не о том, как быстрее восстановить доступ к утраченному сервису — технически это вполне решаемая проблема. А о природе произошедшего: почему схема, работавшая годами, сломалась?

Привет, Хабр!

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

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

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

Сервер лагает. Смотришь на диск — df -h говорит 95% занято. Запускаешь du -sh /* — в сумме набирается 20%. Куда делись остальные 75%? Файлы не найти, место не освободить, сервис падает.

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

Kubernetes-кластер без сети — не кластер, а просто набор несвязанных компонентов. Чтобы «оживить» его, важно понимать, что такое Container Network Interface (CNI) и как он работает.

В статье — детальный разбор механизма CNI: что такое CNI-плагин, как он запускается и какие операции выполняет в кластере. В конце работа CNI демонстрируется на примере кастомного плагина.

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

Некоторое время назад, Роскомнадзор, в очередной раз, решил усложнить мне жизнь, а именно - стал блокировать и разрывать VPN-соединения по протоколу SSTP (Secure Socket Tunneling Protocol), при помощи которого я подключался к устройствам в своей домашней сети. Протокол SSTP относительно медленный, но к числу его преимуществ можно отнести то что он не требует наличия "белого" IP-адреса, т.к. он использует SSL / TLS канал и способен работать через Keenetic Cloud с использованием доменного имени, зарегистрированного в облачной службе KeenDNS.

Блокировки и разрывы SSTP-подключений продолжались примерно 2 или 3 недели и потом прекратились, однако невозможность всё это время нормально использовать свою домашнюю сети (где у меня, например, находится экспериментальный стенд) побудила меня искать альтернативные способы подключения к себе домой.

В этой статье будет рассказано о том, как развернуть на выделенном виртуальном сервере (VPS / VDS) свой личный VPN-сервер, работающий по протоколу AmneziaWG, а затем сконфигурировать развернутый VPN-сервер и домашний роутер фирмы Keenetic таким образом, чтобы внешние клиенты, подключившись к VPN-серверу получали доступ к устройствам в домашней сети.

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

В статье расскажем, как мы разработали Platform V Product 360 — решение по управлению продуктовым каталогом (PIM) ориентированное на рынок e-commerce и при этом закрывающее задачу управления банковскими продуктами

Привет, Хабр! На связи команда SoftStore. В последнее время информационное поле бурлит: СМИ открыто заявляют о финальной блокировке Telegram уже в первых числах апреля 2026 года, WhatsApp давно находится под жесткими ограничениями и регулярно сбоит, а мобильные операторы вовсю обкатывают пресловутые «Белые списки» (White Lists). Панические настроения множатся каждый день, обрастая мифами и неработающими советами.

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

Реальность такова: механизмы белых списков появились не сегодня. Это планомерное развитие систем ТСПУ (Технические средства противодействия угрозам). На данный момент эти ограничения наиболее агрессивно применяются на сетях мобильного интернета. В моменты активации такого режима логика DPI (Deep Packet Inspection) меняется на противоположную: вместо того чтобы блокировать запрещенное (Black List), система начинает отбрасывать (drop) все пакеты, кроме тех, что идут к явно разрешенным ресурсам.

Анатомия мобильного White List: Трафик ходит только до инфраструктуры экосистем: Яндекс, VK, Сбер, личные кабинеты операторов связи, маркетплейсы (WB, Ozon) и ограниченный пул банков. Если вы попытаетесь отправить TCP-пакет на любой другой IP-адрес — он просто исчезнет. ТСПУ не будет ждать передачи 16 КБ данных для анализа сессии, пакет дропнется на этапе хендшейка.

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

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

На этом фоне технология Single Sign-On (SSO) из удобной опции превратилась в базовый элемент современной инфраструктуры доступа. Она позволяет централизовать аутентификацию и убрать избыточные проверки, не снижая (а при правильной реализации — повышая) уровень безопасности.

Разберёмся, как SSO устроен на уровне протоколов и архитектуры, и как эта технология реализована в системе для многофакторной аутентификации и контроля доступа MULTIFACTOR.