Существует несколько различных протоколов, предназначенных для обеспечения бесперебойной работы сети на канальном уровне. Сегодня мы рассмотрим Ethernet Ring Protection Switching – технологию, обеспечивающую высокую доступность и отказоустойчивость в кольцевых топологиях.
Продолжаю серию статей про полезные инструменты для сисадминов. Сегодня расскажу про зарубежные сайты, которые точно должны быть в вашем шорт-листе. Читайте под катом и делитесь своими онлайн-сервисами по мониторингу, тестированию и оптимизации.
Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Исходя из моего опыта, могу сказать, что большинство обладателей OpenWrt-роутеров используют для настройки беспроводных интерфейсов достаточно удобный веб-интерфейс LuCI. И только продвинутые пользователи рискуют править конфиги вручную. Но, как правило, даже они часто ограничиваются лишь указанием основных данных: типа стандарта, канала и, собственно, настроек самой Wi-Fi сети. И совершенно зря, так как wireless-конфиг имеет множество самых разнообразных параметров, позволяющих при правильном использовании увеличить покрытие сети или скорость в несколько раз. В этой статье разберем точную настройку файла /etc/config/wireless в OpenWrt, направленную на создание максимально стабильного покрытия Wi-Fi сети. И посмотрим на предрассудки, которые сложились относительно некоторых параметров. Особенно подчеркну, что мы не будем разбирать все параметры (их действительно очень много), а ограничимся только обозначенной задачей.
Привет, Хабр.
Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен» — системы учета и контроля ИТ-инфраструктуры. В этой статье хочу разобрать одну из самых устойчивых и при этом недооцененных проблем корпоративных ИТ — несанкционированную установку программного обеспечения, Shadow IT.
Во многих компаниях такие установки до сих пор воспринимаются как частный вопрос дисциплины: кто-то поставил лишнее, кто-то обошел регламент. На практике это не отдельные инциденты, а системное явление, которое напрямую влияет и на безопасность, и на управляемость инфраструктуры.
По нашим наблюдениям, в значительной части организаций сотрудники самостоятельно устанавливают рабочий софт, не проходящий централизованное согласование. Причем речь идет не только о специализированных инструментах, но и о вполне привычных вещах: офисных приложениях, утилитах для обмена файлами, удаленного доступа, аналитики и совместной работы.
Важно понимать: в большинстве случаев здесь нет злого умысла. Причины почти всегда лежат в устройстве процессов. Бизнес развивается быстрее, чем ИТ-регламенты, и людям нужно решать задачи здесь и сейчас. При этом согласование нового ПО может занимать дни или недели. Отдельный фактор — работа с подрядчиками, которые устанавливают их в инфраструктуре заказчика привычные им инструменты.
Еще один распространенный сценарий — передача техники между подразделениями. Устройство меняет владельца, а установленное ранее ПО остается без пересмотра. В результате в инфраструктуре постепенно накапливается слой неучтенного и неавторизованного программного обеспечения.
10 лет назад OpenVPN считался надёжным инструментом. Сегодня он блокируется за секунды. За это время сменилось пять поколений протоколов — каждый новый рождался как ответ на то, чему научился цензор. Это история гонки вооружений между математикой и политикой. И она ещё не закончена.
И где мы сейчас ?
2 марта 2026 года я получил на анализ фишинговое письмо. Отправитель - «M e t a», тема - «[Требуется действие] Завершите проверку, чтобы восстановить показ объявлений». SPF pass, DKIM pass, ARC pass - письмо прошло все проверки и лежало во входящих Gmail. Ключ - цепочка Resend.com → Amazon SES → Gmail, где каждый элемент легитимен. Разбираю, как атакующие этого добились и почему это работает.
ZTNA (Zero Trust Network Access) — это модель управления доступом (не только удаленным!), которая проверяет каждого пользователя и устройство (включая установленное и работающее на нем ПО) и даёт доступ не к сети в целом, а к конкретным приложениям и ресурсам. Преимуществом реализации концепции ZTNA в NGFW-решении являются прежде всего возможности файрвола следующего поколения по фильтрации трафика и публикации ресурсов. При этом администратором удобно управлять доступом в одном решении, не прибегая к многочисленным интеграциям наложенных средств защиты.
Особенно важно управлять доступом в современных условиях, когда значительная часть успешных взломов российских компаний в 2025 году происходило с помощью атаки на удаленных сотрудников или подрядчиков (supply chain attack). Специалисты по безопасности испытывают особенную “боль” в контроле подрядчиков - не имея доступ к их ИТ-инфраструктуре и возможностей по мониторингу безопасности, применения политик, настроек и средств защиты.
В Ideco NGFW работа с моделью ZTNA реализована через NAC‑клиент (Network Access Control - контроль доступа к сети на уровне подключения устройства.) и тесную интеграцию с межсетевым экраном, что позволяет существенно безопаснее и гибче управлять доступом сотрудников и подрядчиков по сравнению с классическими VPN и периметровой защитой.
Три года назад я написал статью “Интернет-цензура и обход блокировок: не время расслабляться”. Перечитывая ее сейчас, спустя три года, не могу избавиться от двоякого чувства: с одной стороны я почти во всем оказался прав касательно того, как будут развиваться события, усиливаться блокировки, и регулироваться законодательство. С другой стороны, кое в чем я тогда серьезно ошибся.
А именно: слишком уж я надеялся на то, что доблестные фильтраторы интернета будут заботиться об уменьшении побочных эффектов и так называемого collateral damage, и поэтому будут вынуждены изобретать более сложные технологии детектирования, продолжая увлекательную игру в кошки-мышки. Реальность же оказалась гораздо прозаичнее: зачем думать, когда в руке кувалда? В результате чего имеем следующее: часть детектирования откровенно тупая (например, блок нескольких параллельных подключений к одному IP, что решается использованием gRPC-транспорта для VLESS или XHTTP-транспорта с правильными настройками мультиплексирования), а часть - еще тупее, а именно, никакого детектирования, а тупо бан популярных хостеров и облачных провайдеров целыми подсетями /16 и даже /8 - в результате чего или нельзя подключиться по TLS вообще, или можно, но соединение фризится после передачи примерно 16 килобайт данных, или же блок срабатывает на целую подсеть после случайного обращения к какому-нибудь “плохому” IP-адресу. За анализ огромное спасибо товарищу @0ka и его статьям “РКН создали белый список для 72 AS, но пострадали 391 AS (>225 млн IP адресов)” и “РКН создали список подозрительных айпи адресов (динамическая блокировка 47 AS)”.
Сегодня ядром данной статьи будет MCP — как мост между бекендом‑оберткой с LLM и внешними источниками, но при этом я также затрону смежные темы, чтобы картина была полной и не требовалось дополнительно гуглить.
Я постараюсь не давать устоявшиеся термины в контексте MCP, а также в процессе буду пояснять некоторые «базовые» термины, которые все как бы понимают — но нередко нет, чтобы мы все улавливали один и тот же контекст статьи.
Достался по случаю неисправный 5G роутер Askey RTL6310VW, брендированный под сотового оператора Telefonica, с битой прошивкой (вечный ребут). Прошивок в открытом доступе нет (только FOTA), документации по их установке/восстановлению тоже нет, OpenWRT не поддерживается, гарантия кончилась, у оператора лапки. В общем, кирпич, которому дорога только в помойку. Ради интереса я его разобрал, а там сюрприз - сотовый модем не распаян на плате, как это часто встречается в таких провайдерских CPE, а установлен в М.2 слоте.
В управлении каналами и мощностью передатчика точек доступа Wi‑Fi есть один вечный конфликт: чтобы сеть работала хорошо, нужно знать реальную ситуацию в эфире.
Богатые Cisco, Aruba и прочий Ruckus используют «третий глаз» у точки — отдельный радиоприемник, который для передачи данных вообще не используется. Отдельное радио? В мирное время — премиум‑фича. В трудную годину — уже почти статья за растрату бюджетных денег.
Так что же делать нам, простым смертным?
В современном российском информационном пространстве (видео, статьи, посты и прочее) из каждого чайника слышны разговоры о VPN и Proxy, причём контекст начал настолько размываться, что между этими терминами уже негласно ставится знак равно. Недавно я поймал себя на мысли, что сам не могу чётко сказать, чем эти технологии отличаются. В данной статье попробуем разобраться что же такое VPN и Proxy, а также чётко определить границы этих двух понятий.
Ранее я писал цикл статей: первая, вторая, третья, четвертая. В этой я бы хотел порассуждать на тему безопасности сети SD-WAN в рамках услуги «сеть по подписке».
Подписочная модель предоставления сети подразумевает нулевые затраты (CAPEX) на оборудование. Сеть предоставляется «под ключ» как сервис (или, другими словами, 100% OPEX), все необходимое оборудование доставляется на площадку заказчика в рабочем и настроенном состоянии в «аренду». Бизнес получает рабочую транспортную сеть на удаленных площадках с заданным SLA без необходимости капитальных затрат, найма персонала и прочего.
Когда заходит речь о выборе варианта внедрения решения SD-WAN: как сервис (SaaS) или «все у себя» (On-prem), я иногда слышу фразу: «сервис – это не безопасно». В данной статье я хотел бы порассуждать на тему безопасности сервисной модели SD-WAN в целом и решения от Касперского SD-WAN в частности.
AS (Автономная система) - часть интернета, состоит из блоков IP адресов.
Рекомендую прочитать мою прошлую статью для полного понимания: РКН создали белый список для 72 AS, но пострадали 391 AS (>225 млн IP адресов)
В июне 2025г было замечено (credits: ValdikSS), что на некоторых нодах для тестирования блокировок интернета в РФ наблюдается недоступность TLS 1.3 на серверах OVH.
В статье разберём почему так было и проведём фокус с блокировкой.
Физические терминалы сейчас встретить маловероятно. Однако, чем будет являться GSM модем, работающий через асинхронный последовательный интерфейс для, например, компьютера. Настроим модем и разберёмся в терминологии модели ME(Mobile Equipment) - TE(Terminal Equipment).
В процессе своей трудовой деятельности, начиная от заместителя руководителя по ИТ в крупной образовательной организации и заканчивая ведущим инженером одной из компаний РФ, стоящих на острие современных решений кибербезопасности – меня всегда озадачивал вопрос отказоустойчивости периметрального решения компании или учреждения. При этом хотелось попасть в идеальный баланс между целесообразностью выстраиваемой архитектуры и отсутствием избыточности решения.
Говоря про периметральные NGFW, если отбросить вопрос их корректной настройки инженером и штатного функционирования бекендов, основным способом обеспечения отказоустойчивости является построение кластера из нескольких экземпляров устройств, которые функционируют как единое целое. При этом существуют два принципиально разных варианта реализации – это кластер Active|Passive (A|P) и кластер Active | Active (A|A).
Сегодня я хотел бы поговорить о том, какой тип кластеризации подходит больше к какому типу сети/компании/контекста использования, а также какие преимущества и недостатки имеются у каждого из них.
Кластеризация в режиме Active|Passive представляет собой технологию объединения двух NGFW устройств (каждое из которых будет называться нодой) в единый логический элемент сети (кластер) для обеспечения высокого уровня отказоустойчивости и доступности.
Фактически за счет дублирования физического устройства при этом устраняется проблема «единой точки отказа», когда при выходе из строя узла (как самого NGFW, так и сетевого интерфейса, линка к сетевому интерфейсу) кластер продолжает обрабатывать трафик без прерываний прозрачно для пользователя и сервисов, приложений.
Эта статья появилась как следствие моего желания к обобщению опыта, полученного при изучении внутреннего строения подсистемы работы с RPC в Windows. В течение множества лет я сначала работал с COM/DCOM, создавал кастомные сервера и клиенты, которые использовали эти технологии. При этом вся работа с COM велась с использованием стандартных средств: MIDL и библиотеки ATL. Потом я начал более глубоко вникать в устройство внутренних механизмов Windows и тут возникла необходимость в использовании RPC на гораздо более низком уровне, который бы позволял как можно более полно использовать все возможности этой технологии. Однако, как оказалось, в сети довольно сложно найти какой-то материал, который бы освещал RPC с необходимых мне точек зрения. Поэтому волей-неволей, но мне пришлось самому изучать то, что нужно мне и с той детализацией, которая мне была нужна. Как итог сейчас, например, я могу строить RPC сервера и клиенты абсолютно без использования MIDL или NDR для передачи совершенно произвольных данных. Могу реализовать клиента, который бы осуществлял десятки одновременных параллельных запросов к одному и тому же RPC серверу. Могу возвращать с RPC сервера расширенную информацию об ошибках, а также получать максимально возможную информацию о клиенте, который произвёл вызов. Кроме того я был вынужден достаточно плотно изучить и стандартную подсистему кодирования NDR и теперь у меня есть собственные расширенные примеры кодирования и декодирования всех основных типов на основе официально не декларируемых функций. И теперь весь этот опыт я постараюсь как можно полно и подробно представить в этой статье. Если у кого-либо из читателей возникнут дополнения/замечания, то буду рад услышать полезную информацию от умных людей.
B4 - инструмент обхода DPI на Go с веб-интерфейсом.
Хотелось сделать инструмент, который можно поставить на роутер или любой другой linux-девайс, открыть в браузере и получить работающий результат без возни с десятками аргументов командной строки.
В статье описан способ быстрого превращения обычного VPS с Debian 13 в полноценный OpenWrt роутер за 20 секунд одной командой.
TLDR: Создана рабочая легковесная реализация AmneziaWG для Mikrotik для подключения к AmneziaWG серверам.
Оффлайн(!) конфигуратор на основе AWG-конфига, копия gitlab
Исходники в Github (MIT) копия на gitlab (плз форкайте, а то уже разок github снес мой проект)
upd: Добавлена поддержка протокола AmneziaWG v2.
upd2: Переписали на C, тестим: https://github.com/timbrs/amneziawg-mikrotik-c
