Сетевые технологии *

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

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

История о том, как сисадмин борется с конторой с бюджетом в 60 млрд.
В продолжение комментария.

Глава 1. Первые блокировки, obfs4proxy

Глава 2. Вторая волна, вынос части инфры из AWS.

Глава 3. Попытка попасть в белые списки.

Глава 4. Появление cloak/trojan/hysteria/vless.

Глава 5. Белые списки, поднятие серверов в РФ

Глава 6. Отрыв IP, резервирование

Глава 7. Multihop

В первой статье я рассказывал историю «деда из деревни», который вместе с внуком поднял свой почтовый сервер вместо Gmail — на обычном VPS, с доменом, DNS‑записями и всеми сопутствующими приключениями. Эта иллюстрация продолжает ту линию: дед-айтишник и внук уже не просто радуются первому письму, а разбираются, что происходит с их маленьким сервером в большом почтовом мире.

В данном руководстве приведена инструкция по внедрению двухфакторной аутентификации (2FA/TOTP) для VPN-доступа на базе OCSERV (OpenConnect Server) в связке с FreeRADIUS и FreeIPA.

Думаю, вы уже в курсе, что происходит в РФ с белыми списками: работают белые списки, ТСПУ в режиме drop-all пропускает только одобренные IP + SNI, рунет медленно, но верно становится интранетом

Мы просканировали 46 млн российских IP-адресов, нашли 63 тысячи выживших, разобрали работу ТСПУ. И главное - актуальные методы пробива (от Serverless-функций и покупки VPS с белым IP до туннелей через WebRTC).

В прошлой статье я разобрал, как устроена сеть Yggdrasil. Теперь - про Yggdrasil-ng: рерайт с Go на Rust за 3,5 дня, неделя на один баг в пяти строках, новые фитчи (включая CKR - VPN через mesh), и мобильный клиент, в котором перенос работы с TUN внутрь Rust дал прирост скорости почти в десять раз. В статье бонус - новое приложение, которое вам понравится ;)

Привет. Полгода назад я выложил singbox-launcher — десктопный GUI для управления ядром sing-box. По фидбеку стало понятно: идея зашла, людям удобно собирать и отлаживать конфиги на ноутбуке, а потом переносить их на роутеры и другие сетевые устройства. Подробнее о десктопной версии я писал на Хабре.

Пару слов для тех, кто не в контексте. Есть небольшой класс кроссплатформенных сетевых ядер, которые умеют гибкую маршрутизацию трафика и поддерживают современный набор протоколов: WireGuard, VLESS, SOCKS5, Shadowsocks, Hysteria2, TUIC и так далее. Sing-box в этом списке — не самый раскрученный, но для меня он оказался наиболее интересным: быстрая эволюция, внимание к деталям, чистый код, живое общение мейнтейнеров с пользователями, классно организованный по логике конфиг.

Довольно быстро стали приходить запросы на Android-порт. Первое время казалось, что это будет прямое переиспользование десктопного кода. На практике сценарии потребления на мобильных оказались сильно другими: другой UX, другой lifecycle, Doze и background-лимиты, OEM-специфика, ограниченный экран, другие ожидания от автозапуска и обновлений. В итоге пришлось переписать практически всё с нуля.

Результат этой работы — LxBox, и сегодня я хочу рассказать, чем он отличается от существующих Android-клиентов и как устроен изнутри.

На старых Intel Mac установка proxy-клиента часто превращается в странный квест: если приложение ставится, подписка импортируется, серверы вроде бы появляются, но рабочего подключения всё равно нет. На macOS Catalina 10.15.8 эта проблема ощущается особенно остро: часть современных клиентов уже не поддерживает систему, часть формально запускается, но ломается на встроенном core, а автоматический импорт VLESS/Reality-конфигов может создавать пустую заглушку вместо рабочего профиля.

Эта инструкция написана не экспертом по сетям, а обычным пользователем для таких же обычных пользователей. Я собрал в одном месте весь путь, который реально сработал у меня на старом Intel iMac: как понять, какая версия клиента вообще подходит для Catalina, где брать старые релизы, как распознать сломанный импорт, как вручную собрать рабочий config и почему Telegram Desktop может не заработать, даже когда браузер уже работает.

NAC-системы долгое время ассоциировались с “монстрами” вроде Cisco ISE или Aruba ClearPass. Но что, если собрать российский NAC из модулей «Медведь», «Лиса» и «Заяц», поставить их на страже сети и попробовать закрыть те же сценарии?

Привет, Хабр! С решениями NAC наша команда работает больше 19 лет. Последние годы особенно интересны: российский сегмент NAC заметно вырос, новые продукты появляются регулярно, а интерес со стороны заказчиков подталкивает нас на постоянный анализ рынка. 

Эта статья — часть цикла о NAC-решениях, которые мы разбираем в нашей сетевой лаборатории. На этот раз в фокусе Eltex NAICE — новичок в области контроля доступа, но далеко не новичок в мире сетей.  Разберёмся, как он устроен, какие задачи реально закрывает и насколько уверенно чувствует себя на фоне более привычных NAC-систем. 

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

Причина в том, что речь идёт не об одной точке контроля, а о распределённой системе, где итоговое поведение формируется на пересечении трёх слоёв: централизованного управления, DPI/ТСПУ как контура распознавания и сети оператора как среды исполнения. Именно эта многослойность и объясняет наблюдаемую неравномерность.

Если коротко: После дефейса сайта нашего знакомого из-за утекшего пароля от админки мы поняли, что управлять доступами нетехнической команды (редакторы, SEO, подрядчики) через VPN или статические IP - это боль. Существующие proxy требовали рестартов и рулились конфигами. В итоге мы написали свой forward-proxy на Go, где доступ выдается токеном через расширение браузера, а правила (TTL, лимиты трафика, доступные домены) применяются на лету без разрыва соединений.

Привет!

Эта статья о том, как собрать мобильного оператора «на столе» для тестов функциональности и взаимодействия компонентов ядра сети.

Меня зовут Алексей Червяков, я тимлид команды разработки мобильных продуктов в компании VAS Experts, и мы разрабатываем компоненты ядра сети, которые осуществляют контроль трафика, его подсчет, применяют правила тарификации для абонентов. Корректная работа этих элементов – залог прибыли и отсутствия убытков из-за неоплаченных услуг и трафика.

Приятного чтения!

В комментариях к "серверу точного времени" (https://habr.com/ru/articles/1023414) предлагали вдобавок к NTP и GPS подключить еще и DCF77, как еще один источник времени.
И я таки сделал это, хоть и в виде отдельной железки, а поскольку техника тут аналоговая - были свои нюансы.

В качестве справки:
DCF77 - это радиостанция, передающая точное время от атомных часов, собственно, это ее основное назначение.
Расположена в Европе, в Германии, неподалеку от Франкфурта. Вещает на длинных волнах на всю Европу, захватывая в том числе часть exUSSR. Передает сигнал, содержащий информацию о времени и дате, UTC+1/UTC+2 в зависимости от "летнего времени".
Также передает местную погоду и может быть использована как средство оповещения, но нас это мало касается.
Рабочая частота 77.5 кГц - поэтому и "DCF77".

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

Проблема простая: расстояние.
Несмотря на большую мощность передатчика и хорошее распространение длинных волн на большие расстояния - 2000 км это 2000 км.

Месяц искал VPN который не палит Россию перед ИИ. Нашёл - 24 часа бесплатно, попробовал. Написал в поддержку прямо во время установки. Три минуты — живой человек, сразу инструкция. Сработало. А потом понеслась …

Привет, Хабр! Меня зовут Сергей, я разработчик облачной платформы в Selectel. В прошлой статье я рассказал об использовании Terraform для создания глобального роутера и настройки сетевой связности между разными регионами облака. Сегодня продолжим тему и объединим в сеть выделенный и облачный серверы.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. После большого релиза 🐙 userver прошло почти два года. За это время мы обзавелись большим количеством внешних пользователей — международных и российских. При этом и количество внутренних пользователей подросло: в Городских сервисах Яндекса появились стни новых сервисов на userver. Функциональность Такси, Еды, Лавки, Доставки, а также Маркета, Финтеха, Фантеха, Электро и Техплатформы обогатилась новыми возможностями и новыми пользователями. А значит, фреймворк стал ещё надёжнее и оттестированнее.

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

За последние десятилетия мы как-то все привыкли, что живем в уютной айтишечке – собственном, закрытом мире, практически лишенном недостатков. И в этом мире были кофе по утрами, смузи в обед и неограниченные поездки на такси, часто оплачиваемые напрямую работодателем. И проблем как будто вообще не существовало. Мы выбирали себе новых работодателей, меняя их как перчатки, и за каждую смену места работу гарантированно получали надбавку 10-30% к заплате.

Но, оглянитесь, времена меняются. А в каких-то странах и в каких-то it-направлениях поменялись невозвратно.

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

Потому что никакого закрытого мира никогда и не было. Был общий капиталистический мир со своими объективно работающими законами, и мы всегда были его частью, на определенном этапе развития - привилегированной частью.

Так вот, один из законов развития такого мира заключается в том, что монополии и государство неизбежно сближаются, сращиваются, сливаются в страстном поцелуе взасос. И это обоюдное влечение, обусловленное объективными экономическими интересами.

В нашей сегодняшней it-индустрии эти процессы происходят прямо сейчас. Нет, они были и раньше, но в последние пару лет и даже месяцев всё это закрутилось с новой, невиданной ранее скоростью. И наши сегодняшние лидеры отрасли - Яндекс, Т-Банк, Озон и другие – наперегонки спешат слиться с государством, а государство спешит слиться с ними. И так – далеко не только в РФ.

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

Одним из перспективных подходов к решению указанных задач является внедрение систем класса Identity and Access Management (IAM), обеспечивающих централизованную аутентификацию, авторизацию и управление учётными данными. Среди свободно распространяемых решений данного класса важное место занимает Keycloak - платформа с открытым исходным кодом, предназначенная для организации единого входа, федерации пользователей и управления доступом на основе стандартных протоколов безопасности.

Актуальность применения Keycloak обусловлена тем, что данная система позволяет унифицировать процессы аутентификации в гетерогенной ИТ-среде, обеспечить поддержку многофакторной аутентификации, интеграцию с LDAP/Active Directory, а также централизованное управление ролями и политиками доступа. При этом архитектурные особенности внедрения Keycloak требуют отдельного анализа, поскольку речь идёт о критически важном компоненте сетевой системы защиты информации.

Место Keycloak в архитектуре сетевой защиты информации

В 2020-ом году отправившись на рекомендованную всем «удаленку» мы в Айдеко перекроили весь роадмап продукта и быстро выпустили Ideco UTM VPN Edition – версию с расширенными возможностями по организации, защите и контролю доступа удаленных сотрудников. Делать что-то другое в IT-продукте в это время казалось несвоевременным. Примерно, как сейчас – не использовать AI-инструменты в работе и AI-функциональность в продукте для защиты. В то время, когда злоумышленники вовсю используют AI-инструменты. И атаки становятся все изощреннее и быстрее.

В 2025 году зафиксировано 90 zero-day эксплойтов в дикой природе. 44% атак нулевого дня нацелены на корпоративные сетевые устройства - NGFW и VPN-шлюзы. Среднее время от публикации CVE до первой эксплуатации в реальных атаках сократилось до 5 дней и еще более сократится. Ни одна сигнатурная база не успевает за этим темпом. Рассказываем, как мы работаем над ML-модулем обнаружения вторжений в Ideco NGFW, что показал натурный эксперимент с ИСП РАН на 73 миллионах сессий и какие ограничения у этого подхода.

Почему сигнатуры перестают справляться

Сигнатурный IPS работает принципиально так же, как антивирус в 1990-х: есть база известных угроз, есть входящий трафик, есть сравнение. IPS - при всей мощи, работает с заранее описанными паттернами.

Проблема не в самом подходе - проблема в скорости появления угроз. По данным Google Threat Intelligence Group, в 2025 году в дикой природе было зафиксировано 90 zero-day эксплойтов. По данным RAND Corporation, среднее время жизни zero-day атаки до её обнаружения составляет 312 дней. За это время сигнатура не появится: её невозможно написать на то, что ещё не обнаружено.

Господа подрядчики, интеграторы, техподдерживатели, к вам обращаюсь. Возможно приходилось сталкиваться с ситуацией, когда надо срочно причинить немного добра, но для этого кровь из носу нужен дамп транзитного трафика. Некоторые вендоры позволяют через cli снифануть и записать результат в файлик *.cap прям на флешку маршрутизатора. А вот дальше проблема: доступа по FTP/SFTP/SCP к файловой системе нет, а счастье-то вот оно лежит, руку протяни, но достать не получается.