Почему трафик в ЦОДе балансируется не так, как вы ожидали
LAG часто воспринимают как простую и понятную вещь: объединили несколько линков — получили больше пропускной способности и отказоустойчивость. Но в реальности всё упирается не только в наличие агрегированного канала, а в то, как именно по нему раскладываются потоки.
Из-за этого и появляются знакомые инфраструктурные сюжеты: один линк забит, другой почти пустой; после изменения топологии поведение трафика меняется неочевидно; ECMP вроде есть, но равномерности всё равно нет; в VxLAN/EVPN-фабрике проблема становится ещё менее прозрачной.
7 июля в 20:00 на бесплатном уроке вместе с преподавателями-практиками разберём, как на самом деле работает балансировка трафика в сетях ЦОД: от LAG и хеширования до ECMP, vPC/MLAG и VxLAN/EVPN. Фокус — на том, какие решения в дизайне сети помогают избежать перекосов, перегрузок и сценариев уровня «всё упало, всё пропало». Присоединяйтесь.
Больше бесплатных уроков июля по инфраструктуре, сетям, разработке, AI и другим направлениям собрали в дайджесте — там можно посмотреть все темы месяца.
Вебинар «Злоумышленник на крючке: практические кейсы применения Threat Deception Platform»
Злоумышленник не всегда начинает с громкой атаки. Часто он действует тихо: изучает инфраструктуру, ищет доступы, проверяет сетевые ресурсы и пробует подключиться к перспективным системам.
На вебинаре25 июня (с 11:00 до 12:00, онлайн) расскажем, как технологии класса Deception помогают заметить такие действия на раннем этапе с помощью системы ловушек и приманок.
Покажем конкретные кейсы из практики проектов R‑Vision и разберём:
как технологии класса deception дополняют существующие средства защиты;
какие ловушки лучше всего срабатывают на практике;
какие атаки можно обнаружить до развития инцидента;
как работает и какие задачи решает платформа R‑Vision TDP;
как понять, что вашей компании уже нужен этот инструмент.
Отдельно обсудим, как R‑Vision TDP можно использовать в киберучениях для проверки готовности команд реагирования, а также как инструмент подтверждения выполнения регулярных требований.
Вебинар будет полезен руководителям ИБ, специалистам SOC, инженерам по мониторингу и реагированию, а также командам, которые хотят повысить качество обнаружения без сложного и ресурсоёмкого внедрения.
Неделю назад здесь пробегала новость про "белый VPN" от Билайна - мол, запустили легальный доступ к Spotify, Netflix и паре других сервисов через подписку. Звучало как анонс без деталей: ни механизма, ни цены, ни внятного списка.
А сегодня в смс упала рассылка с конкретикой. И это уже не "планируется" - это работает.
Что именно включили
Механизм оказался прозаичным до приятного: услуга «статический IP-адрес» для домашнего интернета. 180 рублей в месяц. Подключаешь - и устройства в твоей домашней сети (ПК, ноут, Smart TV, телефон по тому же Wi-Fi) ходят на список зарубежных сервисов напрямую, без VPN-клиента, без настроек, без плясок с конфигами.
Сам Билайн называет это "белым VPN". Формулировка гендиректора простая: есть сервисы, которые не попали под ограничения Роскомнадзора, но сами перестали работать с Россией. Вот к ним и открывают прямую дорогу. Концепцию, к слову, ещё весной показывали на ПМЭФ - но одно дело слайд на форуме, другое дело строчка в личном кабинете, которую можно нажать.
Я полез в список
Дальше начинается интересное. В рассылке приложен список сервисов, доступных с этой услугой. Больше сотни наименований в четыре колонки. И если первая новость крутилась вокруг развлечений (стриминги, игры), то здесь видно совсем другую картину.
Я читаю его глазами человека, который пилит пет-проект на LLM и половину дня живёт в AI-инструментах. И вижу там почти весь свой рабочий стек:
OpenAI / ChatGPT, Perplexity, Hugging Face, Character.AI, Pi AI;
Cursor, JetBrains, Replit, Windsurf, Trae, Bolt, Qodo - то есть среды и AI-помощники для кода;
Плюс привычное - Steam (???), Spotify, Netflix, PayPal, Wise, Revolut, Stripe. Но лично для меня ключевое не это. Ключевое - что в список наконец-то попали инструменты, на которых реально работаешь, а не только те, которыми отдыхаешь.
Чем это отличается от обычного VPN - и почему для AI это важно
VPN для работы с нейросетями - это отдельный жанр боли. Канал то падает, то лагает, ответ модели обрывается на середине, стрим токенов рвётся. А ещё многие сервисы не любят, когда ты заходишь с явного VPN-адреса из публичного пула: можно словить капчу на каждый чих, а то и подвесить аккаунт «за подозрительную активность».
Статический белый IP от оператора - это другое. Это твой постоянный адрес, легальный с точки зрения сервиса, не из шумного VPN-пула. Для модельки, которая отвечает потоком, стабильность канала важнее, чем кажется. И когда твой основной VPN в очередной раз ложится отдохнуть, приятно знать, что Cursor и ChatGPT на домашней машине продолжают работать как ни в чём не бывало.
Где подвох
Трезвая часть.
Только домашний интернет Билайна. Это не мобильная сеть и не твой ноут в кафе. Работает ровно в той домашней сети, где висит статический IP. Ушёл из дома - ушёл и доступ.
Регистрация и оплата сервисов - по-прежнему на тебе. Услуга открывает сетевую дорогу, но подписку на ChatGPT Plus или Midjourney за тебя никто не оплатит, и в стоимость 180 рублей она не входит. Как платить зарубежному сервису из РФ - отдельный квест, который эта услуга не решает.
Список закрытый и может меняться. Сегодня сервис в списке, завтра - нет. И обратное тоже верно: список явно будут расширять.
IP всё равно может попасть в бан-листы. Белый он для оператора, но сам сервис вправе вводить свои ограничения.
Почему это всё-таки хорошая новость
При всех оговорках - это первый звоночек, который мне правда нравится. Не очередной костыль на стороне пользователя, а доступ, встроенный в инфраструктуру оператора, легально и в один клик. И судя по тому, что про "открытие доступа без VPN" заговорил уже не один оператор, это не разовая акция Билайна, а тренд, к которому остальные, скорее всего, подтянутся.
В Китае запустили первую в мире коммерческую оптоволоконную систему, которая работает сразу в трёх диапазонах длин волн: S, C и L. Обычные магистрали задействуют преимущественно C-диапазон, поэтому одновременное использование трёх окон прозрачности сразу расширяет доступную полосу.
Вторая составляющая решения это четырёхъядерное волокно. В одном физическом волокне проложены четыре световедущих ядра, и по каждому идёт свой поток данных. Пространственное разделение каналов внутри одного кабеля умножает ёмкость без прокладки дополнительных линий.
По данным разработчиков, пропускная способность одного ядра выросла почти на 50 процентов, а суммарная ёмкость системы превышает показатели обычного одномодового оптоволокна более чем в пять раз.
Ключевой момент в том, что испытания прошли не в лаборатории, а на действующей линии длиной 35 километров. Она соединила вычислительные центры в Циндао провинции Шаньдун, то есть режим эксплуатации был близок к реальной нагрузке между дата-центрами.
Для задач машинного обучения пропускная способность межсоединений имеет прямое значение. Крупные модели обучают на кластерах из тысяч ускорителей, и скорость обмена между узлами и между дата-центрами часто становится узким местом. Более широкий канал снижает простои дорогого железа.
Если технологию удастся масштабировать, операторы и облачные провайдеры смогут поднять пропускную способность на уже проложенных трассах. Это дешевле и быстрее, чем строить новые линии с нуля.
Теперь можно отслеживать стабильность работы сайтов, серверов и приложений, размещенных в нашей инфраструктуре или на сторонних платформах.
Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.
Что можно мониторить:
Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.
Доступность серверов. Сервер перестал отвечать на запросы — среагируете до того, как это заметят остальные.
TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.
SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.
Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.
Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации →
Стоимость — 30 ₽ в месяц за сервис, списания почасовые.
Собрал клиент AmneziaVPN для Ubuntu 22 ...и сделал это через Dockerfile, который Вы можете отредактировать для любого дистрибутива
Зачем понадобилось
Свежие блокировки Роскомнадзора отрезали меня от различных VPN, которыми я периодически пользовался для доступа к зарубежным продуктам, официально в РФ не представленным. Например, к Gemini.
Моей последней надеждой стала self-hosted Амнезия. Я восстановил доступ на всех своих устройствах, кроме одного - домашнего ПК под GPU-вычисления, работающего на Ubuntu 22.04.
Последние версии клиента AmneziaVPN 22-ю убунту не поддерживают: релизы для Linux собираются на Ubuntu 24.04, поэтому есть ограничения в поддержке дистрибутивов из-за версии glibc.
Как это может помочь другим
22-я убунта - это всего лишь пример. Если Ваши вкусы специфичны, да настолько, что AmneziaVPN не работает на выбранном дистрибутиве, докерфайл с лёгкостью можно адаптировать. Единственная дистрибутиво-зависимая часть в докерфайле - вызов apt-get
Что сделано
Я подготовил докерфайл, который из чистого образа ubuntu:22.04 устанавливает Qt и все прочие зависимости, качает репозиторий клиента AmneziaVPN, собирает проект и готовит инсталлятор. Выходная сборка, for my best knowledge, аналогична релизам авторов проекта. Вот здесь PR в официальный репозиторий со всеми объяснениями.
Я писал докерфайл в личных целях, мог что-то не учесть, открыт к критике и предложениям.
Как воспользоваться
Подготовка
Докерфайл качает официальный Qt-инсталлятор (я работал по инструкции вот здесь), поэтому потребуются активный Qt-аккаунт и IP-адрес не из РФ. Qt запрещает скачивания по российским IP-адресам. Нужно либо включить VPN, либо собирать на хостинге за пределами РФ (например, Казахстан). Да, я знаю, что это недостаток - пока не придумал, что с этим делать.
По умолчанию инсталлятор Qt смотрит на учётные данные в файле $HOME/.local/share/Qt/qtaccount.ini. Этот файл прокидывается в докер, поэтому он должен быть на машине для сборки. Если этого файла нет, можно перед запуском докера скачать любой GUI/CLI установщик Qt и пройти в нём страницу логина. Если не хочется возиться с инициализацией аккаунта на машине, то я оставил лазейку по прямой передаче логопасса в докер.
Сборка
Скачать мой форк репозитория, перейти в папку с ним и запустить докер.
Голландская полиция совместно с NCSC-NL отключила прокси-ботнет из 17 миллионов устройств. Это одна из крупнейших операций по выводу из строя вредоносной инфраструктуры.
Перехват C2. Следователи получили наводку и выяснили, что более 200 управляющих серверов физически размещены у местного нидерландского хостинг-провайдера. Вместо блокировок на уровне DNS полиция просто арестовала сами серверы, физически отключив командную инфраструктуру.
Инфраструктура оказалась связана с сервисом Asocks, который продавал доступ к миллионам IP-адресов. Через зараженные устройства злоумышленники прогоняли спам, фишинг, организовывали DDoS-атаки и обходили антифрод-системы банков и маркетплейсов.
Зараженные устройства. В сеть массово угоняли роутеры, IoT-камеры, смартфоны и ПК. География огромная — затронуто 163 страны. Вредонос превращал их в резидентские прокси. Устройства работали как скрытые exit-узлы, обеспечивая преступникам анонимность в сети.
Вы попали в следующую ситуацию: граница, проверка, оператор просит разблокировать телефон. Отказаться нельзя или невыгодно. Что можно?
Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.
В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.
400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.
Четыре режима
Real PIN - открывает реальный аккаунт.
Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.
Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.
Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).
Честно про границы
Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».
Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).
Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.
Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.
YouTube начал требовать отключить средства обхода блокировок для просмотра видео. Ограничение касается каналов с жёсткими региональными правами на контент: в первую очередь спортивных — «Формула 1», некоторые футбольные лиги, отдельные музыкальные лейблы. Это каналы, где рекламодатели платят за показы в конкретных странах, а правообладатели продают лицензии по регионам. YouTube обязан контролировать, из какой страны смотрит зритель, — иначе нарушаются условия лицензий.
Для обычных видео — летсплеев, обзоров, подкастов, авторского контента — ничего не изменилось. Средства обхода блокировок работают как прежде. Явление касается единичных каналов с крупными медиапартнёрами и существует уже не первый год — просто периодически всплывает у новых пользователей и вызывает волну тревоги.
Прятать данные в TLS-трафике: как выглядит настоящий стелс
Больше 70% интернет-трафика — зашифрованный TLS. Это не баг, это фича: тонны HTTPS-соединений, WebSocket-потоков, мобильных приложений и игровых клиентов создают идеальный фон для передачи данных без привлечения внимания.
Идея простая: если нужно спрятать дерево, прячь его в лесу. В случае интернета этот лес состоит из миллионов TCP/443-соединений, которые выглядят настолько обычно, что именно это делает их интересной средой для экспериментов.
Почему TLS-трафик — удобная маскировка
TLS скрывает содержимое пакетов. DPI может видеть метаданные — размер, timing, SNI в Client Hello, но не payload. Если ваше соединение выглядит как обычный HTTPS-запрос или долгоживущий WebSocket, оно сливается с фоном.
Практическая сторона: можно передавать данные внутри легитимных TLS-сессий, используя существующие протоколы как транспорт. Это не новая идея — стеганография в сетевых протоколах обсуждается десятилетиями, но TLS даёт дополнительный слой: шифрование на уровне протокола скрывает структуру payload от внешнего наблюдателя.
Где это может быть полезно
Обход блокировок в странах с жёстким DPI — если трафик неотличим от обычного HTTPS, его сложнее фильтровать
Распределённое хранилище данных в трафике — архивные данные можно держать не на диске, а в виде пакетов, циркулирующих между нодами
Covert channels для исследований в области безопасности — тестирование систем мониторинга и обнаружения аномалий
Технические ограничения и риски
Главное ограничение — timing и packet size analysis. Если трафик выглядит нетипично по объёму или интервалам, статистические методы могут его вычислить. Traffic shaping помогает, но не решает проблему полностью.
Второе — легитимность. Если используешь чужую инфраструктуру или протоколы без согласия провайдера, это может нарушать ToS. В корпоративной среде такие эксперименты быстро привлекут внимание security-команды.
Третье — надёжность. Пакеты теряются, соединения рвутся, данные нужно восстанавливать. Без механизмов коррекции ошибок и redundancy хранилище в трафике превращается в лотерею.
В итоге: технически возможно, но требует продуманной архитектуры, понимания сетевых протоколов и готовности к тому, что решение будет хрупким. Как proof-of-concept — интересно. Как production-инструмент — сомнительно.
Передача параметров ssh с помощью суффиксов имени хоста
В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).
Host tproxy
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080
У этой рекомендации есть один существенный недостаток — она не обеспечивает модульность конфигурации и вынуждает дублировать информацию. В случае, если требуется обеспечить подключение к тому же серверу из интернета через NAT или через SSH-прокси, или без SOCKS5-прокси и переадресации портов, причём во всех возможных комбинациях:
изнутри с переадресацией портов,
изнутри без переадресации портов,
снаружи с перадресацией портов,
снаружи без переадресации портов,
для данного сервера придётся добавить ещё три секции Host, часть сведений в которых будет дублироваться. Если же компания подключилась к двум провайдерам и сэкономила на маршрутизации BGP, понадобятся уже шесть частично дублирующих друг друга секций Host. Дублирования сведений, как известно, желательно избегать, и для этого следует каким-либо образом доработать исходную рекомендацию.
Сущность предлагаемой доработки
Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.
В случае, если суффикс должен добавлять параметры, специфичные для определённого хоста, например, его реальное имя DNS, или параметры переадресации портов, в которых фигурирует адрес локального сокета, индивидуальный для каждого из хостов, команда Match должна будет содержать два аргумента originalhost: один — с шаблоном имени хоста, и второй — с шаблоном суффикса. Пример:
Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
Hostname srv-10-79.rtk.company.com
Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
ProxyJump gate-10-1+yota
Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080
За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:
Match originalhost "tproxy,tproxy+*"
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.
Match originalhost "*+rsa,*+rsa+*"
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
Виртуальные бои с взаимной блокировкой сайтов и сервисов перешли в реальный мир. Евросоюз изучает возможность проложить оптические магистрали в Азию через Арктику. Почему не хватило текущей надёжности Интернета, который разрабатывался как сеть, способная сохранить работоспособность после ядерной войны?
Азия и Ближний восток: риски и возможности
Вместо локальной системы связи для одной страны Интернет стал глобальной сетью. При этом магистральные каналы прокладывались не равномерно, а там, где удобно. В результате оказалось, что большая часть магистральных каналов между Европейским союзом и Китаем, Индией и другими важными партнёрами из Юго-Восточной Азии проложена через Россию или Ближний Восток.
В 2024 году в Красном море Йемен повредил четыре подводных кабеля в Красном море. А уже в этом году Иран угрожал блокировать не только Ормузский пролив, но и интернет-каналы, проходящие у его берегов. Так как долговременное примирение геополитических противников никто не гарантирует, ЕС задумался над прокладкой кабелей через арктический регион.
Трафик через полюс
У Европы два варианта прокладки интернет-кабелей — через Северо-Западный проход. Аналог Северного морского пути в обход Канады и Аляски по Северному Ледовитому океану. Однако придётся решать вопросы работы в сложных ледовых условиях. Есть опыт многомесячных перерывов в ремонте интернет-магистралей, находящихся в подобных условиях. Альтернатива — не проще: проложить кабели непосредственно через Северный полюс.
Кажется, что в таких условиях получат новые возможности спутниковые сервисы связи. Однако в текущей ситуации захочет ли Европа зависеть от американских компаний? А OneWeb вряд ли потянет полноценную связь регионов. Часть коммерческой нагрузки может взять на себя сервис спутниковой связи IRIS, основное назначение которого — связь для европейских госструктур и силовиков.
В любом случае реализация обхода через Арктику намечена к 2030 году. За 5 лет может ещё всё измениться.
ИТ-компаниям приходится учитывать не только требования локальных регуляторов, но и геополитику, чтобы готовиться к сложностям с доступностью электронных компонентов и каналов связи. К сожалению, на это уходят ресурсы, и приходится прикладывать дополнительные усилия, чтобы это не сказывалось на пользователях.
Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️
Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).
В этот день вы сможете вместе с нами узнать, как поменяют правила игры:
автоматизированное реагирование;
облачное детектирование;
архивное хранение метаданных.
Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:
Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы
Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML.
В трёх треках программы обсудим не только ML‑инфраструктуру, но и базы данных, стораджи, инструменты разработки, observability‑решения, SRE и эксплуатацию и управление трафиком.
Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы:
«Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс)
«ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech)
«Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon)
«Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud)
«ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк)
«Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)
Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.
Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.
Представлен сервис «taken.» который позволяет оценить, какую информацию о вас знают сайты в интернете. Спойлер: они знают буквально всё — от вашего местоположения до точных настроек системы, заряда батареи и даже установленных шрифтов.
dpi-checkers — open-source инструмент от hyperion-cs — показывает, каким именно методом ваш провайдер режет трафик: RST после 16-го пакета, SNI-дроп или CIDR-вайтлист. Прогнал на трёх подключениях — картина неожиданная.
Пользователи рунета давно заметили: «интернет дома» и «интернет у бабушки в области» — это два разных интернета. YouTube грузится на одном провайдере и не грузится на другом. Discord висит на мобильном, но работает на проводе того же оператора. Это не случайность и не деградация сети — за каждым таким симптомом стоит конкретный технический механизм на L4/L7.
Набор тестов dpi-checkers (часть на Go как CLI-утилита, часть в браузере на JS) позволяет идентифицировать метод фильтрации, который применяет конкретный ISP. Я прогнал проверки на трёх подключениях: домашнем у федерального провайдера, мобильном у одного из «большой четвёрки» и через знакомого в другом регионе.
Пять методов которые реально встречаются в РФ. DPI — не одна технология, а класс решений. Современный Deep Packet Inspection анализирует не только заголовки L3/L4, но и содержимое L7: по особенностям TLS handshake система определяет сервис назначения даже без знания IP и применяет политику — пропустить, сбросить, замедлить. Когда в новостях пишут «провайдер замедляет YouTube» — это упрощение. Технически применяется один из нескольких методов, и симптомы у пользователя разные в зависимости от метода.
CIDR-вайтлисты — блокировка по IP-подсетям. Трафик к адресам вне «доверенного» списка не пропускается. Жёсткий метод, чаще встречается на мобильных тарифах 4G+/5G.
TCP 16-20 (rps-разрыв) — DPI ждёт первые 16–20 пакетов TLS-сессии, детектирует SNI нежелательного хоста и отправляет RST обеим сторонам. Клиент видит «сайт упал», хотя сервер жив. Основной механизм замедления YouTube в 2024–2025.
Подмена DNS-ответов — перехват запроса на уровне провайдера, возврат заглушки или 0.0.0.0. Старый метод, обходится DoH/DoT, но используется как первая ступень.
SNI-блокировка — поле Server Name Indication в TLS handshake передаётся открытым текстом до установки шифрованного канала. DPI читает его и сбрасывает соединение по домену.
QUIC-блокировки — UDP/443 режется целиком или деградирует, чтобы клиент откатился на TCP, где уже работает SNI-фильтрация.
Что показал dpi-checkers на трёх подключениях. Домашний федеральный провайдер — TCP 16-20 в чистом виде: соединение с рядом зарубежных сервисов рвётся ровно после 16–18 пакетов в TLS-сессии, RST приходит от «провайдерского» адреса, не от сервера назначения. Мобильный оператор — комбинация SNI-дропа и QUIC-блокировки: UDP/443 не проходит вообще, TCP-соединение с теми же хостами рвётся по SNI до завершения handshake. Региональный провайдер через знакомого — DNS-подмена как первая ступень плюс CIDR-ограничения на часть подсетей Cloudflare.
Исследования Citizen Lab и проект net4people фиксируют схожие паттерны по всему рунету — методы стандартизированы, оборудование у операторов в основном одно и то же (ТСПУ от Эшелона и аналоги). Различия между провайдерами — в настройке порогов и в том, какие именно списки им спустили.
Для меня как человека, который строит корпоративные сети, это не абстрактный research. Когда у сотрудника «не работает» корпоративный сервис — первый вопрос теперь не «а VPN включён?», а «какой метод фильтрации у его провайдера?». TCP RST лечится иначе, чем DNS-подмена, и иначе, чем QUIC-блок. dpi-checkers даёт ответ за пять минут вместо часа диагностики вслепую.
Как определить свой внешний IP когда действуют белые списки Минцифры
Когда Министерство цифровой деградации России начинает ограничивать Интернет по своим белым спискам, внезапно обнаруживается, что из привычных инструментов не работает ничего. Невозможно зайти ни на один сайт: 2ip.rumyip.ruifconfig.meipify.orgwhatismyipaddress.comwww.whatismyip.comipinfo.io потому что никто из них не занесён в белые списки. Timeweb есть в белых списках, timeweb.com/check-ip страница открывается, но во время работы белых списков все поля пустые. Из поисковых серверов в этот момент доступен только Яндекс, но он тоже ничем не может помочь в данной ситуации, потому что не готов к такому, и предлагает те же самые сайты которые недоступны.
Вспоминаем жизнь до появления поисковых серверов - создаём свои коллекции нужных ссылок вручную.
В момент действия белых списков мне через моего сотового провайдера «Мегафон» (физически я нахожусь в СПб или Ленобласти) доступен очень ограниченный перечень сайтов. Возможно, что в том месте где Вы находитесь белый список будет другим. Просмотрев вручную всё что мне доступно по состоянию на 7 мая 2026 нашёл всего две ссылки которые показывают мой IP адрес: Яндекс Интернетометр yandex.ru/internet и Reg.ru reg.ru/web-tools/myip В Интернетометре Яндекса можно ещё и скорость померить. Из сервисов whois рабочий нашёл только один nic.ru/whois Разумеется, не надо заходить на эти ресурсы через свою выходную ноду VPN. Также, в момент когда действуют белые списки, возможно ещё и замедление скорости доступа даже к тому что разрешено. Привычный дизайн сайтов может быть нарушен, из-за того, что внешние ресурсы подгружаемые сайтом недоступны во время работы белых списков.
IP адрес который выдал Вашему устройству сотовый провайдер можно посмотреть на самом устройстве. На Android это вот тут: Settings / About phone / Status / IP Address
Возможны другие варианты. На BlackView BV9800: Settings / System / Advanced / About Phone / IP Address
Во время работы белых списков на смартфоне 100.82.28.67 а внешний IP на сайте Яндекс Интернетометр в это же время показывает 178.178.244.80
100.64.0.0 — 100.127.255.255 (маска подсети 255.192.0.0 или /10). Данная подсеть рекомендована согласно RFC 6598 для использования в качестве адресов для CGN (Carrier-Grade NAT); Вики
PS: Запасайте наличные рубли, во время работы белых списков либо оплата наличными, либо предоплата на сайте. Оплата банковской картой в это время не работает. Видимо эквайринг Сбербанка в белые списки не попал.
Сервис Your IP Security & Privacy Audit проверяет подключение пользователя на предмет утечек, а также на безопасность сетевого соединения. Решение просматривает: IP, утечку гео и WebRTC, DNS, чёрный список IP-адресов, цифровые отпечатки в браузере.
Если вы считаете, что вы обманули белые списки Роскомнадзора с помощью VLESS и прочих квн-чудес, то просто представьте, как всё это держится на Yandex Cloud и VK Cloud за счет того, что они арендуют сервера с диапазонами айпи в белых списках...
На днях решил посмотреть свой IP через VPN и заметил хостинг YANDEX CLOUD или VK LLC. И вот непопулярное мнение с ноткой теории заговора, но я задумался о том, почему ВК и Яндекс вообще допускают диапазоны IP своих VDS (про сервисы не говорим, так как исключения легко можно настроить) и особо не спешат блокировать свои IP, и хочу высказать догадку.
Не видел такой точки зрения, но мне кажется, что ВК и Яндексу выгодно и очень прибыльно хостить сервера, айпи которых в белом списке, так как это тот самый важный элемент для КВН, обходящих белые списки и без точки входа во внешний Интернет, оно бы не заработало.
Представлен открытый проект TapMap, который следит за всеми подключениями на интерактивной карте и показывает, к серверам в каких странах отправляет запросы ПК пользователя.
Проект сканирует приложения, сервисы, страны и порты за последние 30 дней. При этом данные никуда не улетают — всё локально на компьютере.
Представлен открытый проект FMHY Filterlist — это список вредоносных ресурсов и другого сомнительного ПО в сети, где есть фейковые сайты популярных репакеров, торрентов и софта, пиратские сайты, где хоть раз нашли вирусы, а также «серые» ресурсы, сервисы с сомнительной репутацией вроде Avast, McAfee, Tlauncher, 360 Total Security и других. Разработчики проекта постоянно обновляют список угроз. Фильтр уберёт большинство вредоносных сайтов из доступной сети и не даст пользователям перейти на них.
Бесплатный проект email-fake позволяет генерировать одноразовую электронную почту за один клик. Сервис создаёт почтовые ящики, чтобы пользователи могли зарегаться в различных сервисах и получать любые коды доступа без регистрации и получения спама на личную почту.
Разработчики из «Яндекса» спрятали пасхалку на «1984» Оруэлла в коде заглушки с запретом на VPN. Ранее приложения вроде «Яндекс Погода», «Яндекс Пэй» и «Кинопоиск» при попытке их открыть с включённым VPN начали отображать плашку, в которой утверждается, что зайти в приложение с VPN не получится.
Могу ли я, деревенский пенсионер, стать айтишником и писать про интернет на Хабр в 2026 году?
В этом посте хочу поделиться своим опытом: может ли человек без профильного образования, без работы в провинциальном «айти‑парке», да ещё и на пенсии, стать тем самым «деревенским айтишником» и писать полезные вещи на Хабр в 2026 году.
Меня зовут Алекс, я живу в Архангельской области, в обычной деревне, и последние годы занимаюсь тем, что добываю нормальный интернет — себе, соседям и всем, кто приходит с фразой: «Сделай, как у Вани, только чтобы не дорого и не падало».
По профессии я не программист и не сетевой инженер. Всю жизнь работал ближе к «земным» делам, а айти было где‑то поблизости в виде «помоги настроить, починить, провести». Но так получилось, что именно на пенсии я стал тем человеком, который:
подбирает и вешает уличные LTE‑роутеры вроде NR‑712 ;
колдует с антеннами, кабелями и спутниковыми «тазами»;
пишет истории и технические заметки про всё это — сначала «для своих», а теперь и под Хабр.
Пример того, чем я сейчас занимаюсь:
У себя в доме поднял нормальный интернет на базе уличного CPE (NR‑712) и домашнего роутера, чтобы дочка могла учиться, а я — работать с сайтами и сервисами.
Помог соседу Ване вытащить скорость из «одной палки и молитвы», прикрутив к его старой спутниковой тарелке 4G‑облучатель и нормально настроив всю связку.
Параллельно начал вести рубрику «712‑й на связи» — по сути, деревенский новостной дайджест: что происходит в мире связи, ИИ и спутникового интернета, и как это вообще касается нашей реальной жизни за городом.
За последние пару лет я успел наделать кучу ошибок:
покупал «чудо‑антенны», которые обещали 100500 dBi и, конечно, не работали;
связывался с неподходящими операторами и неделями ловил сигнал там, где его физически почти нет;
верил рекламе «поставь эту фишку — будет счастье», пока не понял, что без понимания физики и нормального монтажа никакая интернет фишка не спасёт.
Часть этих ошибок я уже обернул в рассказы и статьи — с примерами, цифрами и честным деревенским юмором. Часть ещё ждёт своего часа.
В дальнейших постах хочу:
продолжать рассказывать живые истории — как мы в деревне боремся за мегабиты, когда вокруг лес и дизель‑генератор;
делиться практикой по уличным LTE‑роутерам, антеннам и бюджетным решениям «для своих»;
иногда смотреть "наверх" — спутниковый интернет и агентный ИИ — и перевoдить всё это на язык «а нам-то, в деревне, что с этого?».
Этим постом я, по сути, знакомлюсь с аудиторией Хабра: я не «сеньор девопс из корпорации», я тот самый человек, который ставит интернет в доме, где оптика закончилась в соседнем райцентре.
Если вам близка тема связи в регионах, бюджетных сетевых решений и «человеческих» рассказов с матчастью — буду рад видеть вас в комментариях и следующих историях.
В начале марта я писал о возможных изменениях с доменами .ru/.рф/.su! Тогда многие сомневались, что это действительно введут. Теперь — уже факт.
Анонимные сайты в России уходят в прошлое. Регистрация доменов .ru/.рф/.su будет возможна только после прохождения идентификации через «Госуслуги».
Новое правило станет обязательным с 1 сентября. Информация уже обновлена на сайте реестра, а владельцам доменов начали приходить уведомления с требованием пройти подтверждение личности. В противном случае домен могут удалить.
Про анонимность, похоже, можно окончательно забыть 😒
Коротко подведу итоги последних обсуждений по вопросам уязвимости средств обхода, как я их понимаю .
Преамбула: Многие популярные средства обхода блокировок открывают порт на localhost, на котором отвечает SOCKS-прокси. Трафик, идущий через этот прокси, отправляется в туннель, который завершается на удалённом сервере, где Интернет не столь ограничен. Для удобства использования уже этот прокси заворачивается в сетевой TUN-интерфейс, что позволяет пускать через него трафик приложений, которые с прокси работать не умеют/не хотят.
Проблема: Как правило, этот SOCKS-прокси не требует авторизации. А потому любое приложение, знающее о существовании открытого порта или TUN-интерфейса, может отправить запрос через него на подконтрольный создателям приложения сервер, и тем самым выяснить, куда именно ведёт обходной туннель. При этом выяснить наличие порта можно простым перебором (localhost обычно быстр), а список сетевых интерфейсов приложение может запросить без особых прав.
Последствия: Это позволяет РКН в перспективе полностью автоматизировать поиск и блокировку индивидуальных средств обхода блокировок, при этом не обрубая зарубежный трафик полностью. С недавних пор все российские ИТ-компании обязаны этому содействовать, блокируя пользователей с обнаруженным туннелем и/или донося на этих пользователей РКН. Любое российское приложение может оказаться стукачом.
Пути решения на Android:
Раздельная маршрутизация по сетевым адресам (например, ru - напрямую, не ru - в туннель) - скорее вредна, чем полезна. Приложение может сделать два запроса к "своим" серверам, один из которых находится за рубежом, получить от них ответы с адресом отправителя, и сравнить. Адреса разные = есть туннель.
"Обычная" раздельная маршрутизация по приложениям - гарантий не даёт. Насколько я понимаю, она просто задаёт сетевой интерфейс, который приложение использует по умолчанию, но не запрещает приложению использовать другие интерфейсы. Также она не мешает сканировать порты в поисках SOCKS-прокси.
Shelter, Knox и тому подобные песочницы - не слишком помогают. Они скроют часто проверяемый флаг TRANSPORT_VPN, но не защитят от перебора портов в поисках SOCKS. Проверяется утилитами вроде RKNHardening.
Включить авторизацию на SOCKS-прокси и ограничить доступ к TUN интерфейсу - пока доступно не везде. Сейчас добавление этой фичи в приложения для обхода обсуждается. Некоторые уже поддерживают. Это не помешает злонамеренному приложению увидеть, что прокси есть - но не позволит узнать адрес сервера. Также без ограничения доступа к TUN пароль на прокси не поможет.
Раздельные IP на вход и выход - довольно хороший способ. В худшем случае в бан улетит сервер-выход, а вы продолжите подключаться на входной.
Различные устройства - неудобный и дорогой, но надёжный способ. Одно устройство только для российских приложений, без следа средств обхода, подключается в Сети только через мобильный интернет. Второе - для всего остального. Но не стоит забывать про проблемы вебсайтов (см. ниже).
Что делать с сайтами?
Потенциально на сайт может быть внедрён JS-скрипт (через трекеры или рекламные сети), который пытается провести аналогичный анализ через сопоставление двух обращений на сервера в разных сетевых локациях. При этом правила CORS, не позволяющие скриптам произвольно обращаться к другим веб-сайтам, не особенно помешают. Они не позволяют скрипту прочитать ответ, но сервера всё ещё получат запрос - а значит, могут выполнить сопоставление сами, если они подконтрольны создателю скрипта.
Поэтому разумным представляется такой вариант: два разных браузера, или два разных профиля в одном браузере. Один без прокси, под работу с доступными сайтами и один под потенциальную запрещёнку. В оба профиля ставим адблокер и жёстко режем доступ к любым рекламным сетям - не гарантия, но может помочь. Во втором профиле - никакой раздельной маршрутизации, все запросы строго через прокси. На российские и другие подозрительные ресурсы через второй профиль не ходим никогда.
Некоторые сотовые операторы (не будем показывать пальцем) не нашли ничего лучше чем заблокировать google com, а вместе с ним кучку вполне добропорядочных отечественных сервисов. Про неотечественные и не говорю.
Ну и куда податься бедному крестьянину, желающему посмотреть на "замедленном" Ютубе про выращивание рассады, и поискать в интернете чертежи теплицы, сидя на даче?
Пришлось пенсионерам приобщаться к премудростям работы сетей и к технологиям исправления поломанного. Заодно и телеграм с вотсапом заработали.
Если цель всего этого цирка - поднятие компьютерной грамотности и воспитание недоверия - работа проводится успешно.
Wireshark: установка, фильтры и разбор реальных сценариев
Сеть ведет себя странно, но непонятно где именно — знакомая ситуация? Wireshark в таких случаях помогает увидеть трафик изнутри: перехватить пакеты, отфильтровать нужное и найти проблему — будь то задержки, потери пакетов или подозрительная активность.
В блоге разобрали инструмент с нуля: установка на Windows, Linux и macOS, работа с интерфейсом, фильтры захвата и отображения, практические сценарии — от отладки медленного соединения до анализа VoIP-звонков.
ТСПУ как система: что можно утверждать, а что пока остаётся реконструкцией
Я изучал тему ТСПУ по открытым источникам и в какой‑то момент понял, что главная проблема обсуждения здесь — смешение разных уровней знания. Подтверждённые факты, правдоподобные инженерные выводы и чистые гипотезы часто складывают в одну корзину.
Чтобы не скатываться в источники «одна баба сказала» мифологию, полезно развести эти уровни отдельно.
Подтверждённый слой
На основании открытых данных можно считать достаточно подтверждённым следующее:
ТСПУ распределены по сетям операторов и управляются централизованно.
система использует комбинацию механизмов: DPI, DNS и более грубые сетевые методы.
ТСПУ хранит контекст и может реализовывать не только статические блокировки, но и временные ограничения.
в системе существует разрешительная/запретительная политика (Белые/черные списки).
ТСПУ имеет ресурсные пределы; кроме того и режим bypass (Пропускаем весь трафик).
РКН планирует существенно увеличивать мощность и бюджет этой инфраструктуры.
Вероятный слой
Следующий уровень — это уже не прямое подтверждение, а реконструкция, которая хорошо ложится на наблюдаемую логику таких систем:
скорее всего, внутри реализован многоступенчатый pipeline обработки и принятия решений;
белые списки, скорее всего, работает как fast‑path (дешевое, с точки средния ресурсов решение) для удешевления обработки части трафика;
часть решений может приниматься по совокупности признаков, а не по одному сигнатурному совпадению, возможно накопительная система, как в антифроде;
под высокой нагрузкой система, вероятно, переходит к более дешёвым сценариям анализа и воздействия;
Telegram и сопоставимый трафик можно предположительно отнести к дорогому классу нагрузки для DPI, так как. MTProxy маскируются под https и требуют более глубокого L7 анализа, тоже похоже относится и к VLESS.
Гипотетический слой
Пока нет оснований уверенно утверждать:
как именно устроен механизм применения правил;
используются ли ML/AI‑компоненты, или всё построено на правилах и эвристиках;
как именно система управляет таблицей состояний соединений — как очищает её, какие записи вытесняет при нехватке ресурсов и по каким правилам хранит информацию о текущих и недавних сетевых сессиях;
где именно находятся пороговые значения для включения bypass;
насколько отличается глубина L7-разбора между разными типами трафика.
Мой промежуточный вывод такой: ТСПУ разумно анализировать не как отдельное устройство, а как распределённую систему с централизованным управлением, ограничениями по вычислительным ресурсам и, вероятно, несколькими режимами деградации.
Если к теме будет интерес, я могу подготовить аналитическую статью: архитектура, стоимость анализа и пределы блокировок. Готов коллаборациям с другими исследователями.
Об авторе:
Я занимаюсь информационной безопасностью, основной профиль — практическое тестирование на проникновение (pentest), расследование инцидентов и анализ защищённости инфраструктур. В том числе работаю с инцидентами, связанными с хищением криптоактивов и разбором сложных кейсов, требующих технического и аналитического подхода.
Представлен онлайн-проект Project Backbone, который показывает как устроена глобальная сеть Интернет в режиме реального времени. Можно посмотреть на кабели под океанами, серверы в разных странах, оптоволокно под городами. Также через какие маршруты идут данные, как связаны регионы и насколько всё это глобально, включая спутниковые группировки.
Открытый сетевой инструмент Deep Eye может автономно искать уязвимости и проводить тесты на проникновение в исследовательских целях. Проект использует нейросети, которые коллективно ищут уязвимости на выбранном ресурсе и пытаются проводить различные тесты. Решение поддерживает 45 методов и атак. Алгоритмы системы собирают всю информацию о сайте, включая поддомены и DNS.
Проект просуществовал более восьми лет, набрал 20 тысяч звёзд на GitHub и стал стандартом для HTTP-маршрутизации в Kubernetes. Теперь поддержка и разработка полностью прекращена: новых релизов, багфиксов и патчей безопасности не будет.
Причина архива: ресурс Ingress изначально был слишком ограничен. Весь расширенный функционал реализовали через vendor-специфичные аннотации, нормального RBAC не было, протоколы: только HTTP/HTTPS. Gateway API решает все эти проблемы на уровне спецификации.
Мейнтейнеры рекомендуют переходить на реализации Gateway API:
"If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."
Если это для борьбы с БПЛА, то можно же отследить странное перемещение сигнала от вражеского мобильного устройства даже без GPS данных от него, используя Location‑based services (LBS) + MLP + подключить в наше время к анализу ИИ. Сразу выборочно направлять данные о подозрительном объекте «куда следует» и блокировать. Чем больше станций — тем точнее, но почему‑ то наоборот «массово демонтируют оборудование провайдеров на опорах „Россетей“ — вредительство?»
Вот выдержка из гугла:
1. Как провайдер определяет скорость
Оператор не просто видит местоположение, он анализирует динамику изменения сетевых параметров:
Частота хендоверов (Handover Rate): Это основной показатель. Если телефон переключается между базовыми станциями (Cell ID) каждые 30–60 секунд, алгоритмы сети понимают, что объект движется по трассе или в поезде. Зная расстояние между вышками, система вычисляет среднюю скорость.
Доплеровский сдвиг (Doppler Shift): При быстром движении частота радиоволны меняется (эффект Доплера). Оборудование базовой станции измеряет это отклонение, что позволяет определить мгновенную скорость объекта относительно вышки.
Изменение Timing Advance (TA): Параметр TA определяет задержку сигнала и расстояние до вышки (шагами по ~550 метров). Если значение TA быстро уменьшается или растет, оператор видит радиальную скорость сближения или удаления.
2. Как провайдер определяет высоту (Z-координату)
Это более сложная задача, но в современных сетях (LTE/5G) она решается так:
Протокол LPP (LTE Positioning Protocol): Сеть может запросить у смартфона данные его внутренних датчиков. Если в телефоне есть барометр, он передаст данные о давлении в зашифрованном виде оператору, что даст точность высоты до 1–3 метров.
MDT (Minimization of Drive Tests): Это функция, при которой смартфоны анонимно передают отчеты о качестве покрытия, включая GPS-координаты (в том числе высоту над уровнем моря), если навигация включена.
UTDOA (Uplink Time Difference of Arrival): Несколько вышек фиксируют время прихода сигнала с точностью до наносекунд. Разница во времени позволяет построить 3D-модель и вычислить высоту (Z), даже если у телефона нет GPS или барометра. Это метод «обратной триангуляции».
Анализ диаграммы направленности: Антенны на вышках имеют определенный наклон (Tilt). Анализируя, какой сектор и под каким углом принимает сигнал, система может предположить, находится ли абонент на земле или на верхних этажах небоскреба.
3. Где эти данные обрабатываются?
В архитектуре сети за это отвечают специальные узлы:
GMLC (Gateway Mobile Location Centre): Шлюз, который собирает и выдает координаты внешним сервисам (например, экстренным службам 112).
LMF (Location Management Function): В сетях 5G этот узел отвечает за сложные вычисления 3D-позиционирования в реальном времени.
Выпустили мобильное приложение для Интернетометра от Яндекса
Команда Yandex Infrastructure разработала приложение под iOS и Android для бесплатного сервиса Интернетометр. Как и в веб‑версии сервиса в приложении можно замерять скорость скачивания, скорость загрузки и время задержки интернет‑соединения в миллисекундах.
В приложении доступны светлая и тёмная темы
Сбор информации организован с использованием сети CDN‑серверов Яндекса: для большей точности сервис опрашивает не один, а сразу несколько ближайших серверов. Ежемесячно Интернетометром пользуются 5,5 миллионов человек — в среднем они запускают 18 миллионов измерений.
Сервис предоставляет ключевую информацию о подключении: IP‑адрес, версию браузера, разрешение экрана и так далее. В будущем в приложении будет доступен расширенный режим измерений: он будет особенно полезен для технических специалистов, которые настраивают интернет‑соединение. Также у провайдеров проводной и беспроводной связи появится личный кабинет, где они смогут отслеживать замеры в зоне своего покрытия.
Telegram наносит ответный удар: мессенджер в ответ на блокировку убивает оборудование РКН дудосом.
Что происходит
В последние дни пользователи Telegram в России столкнулись с серьёзными проблемами в работе мессенджера. Ситуация развивается на фоне активных блокировок нежелательного контента самим Telegram и последующих технических проблем с инфраструктурой.
Техническая сторона проблемы
По данным DTF, прокси-серверы Telegram начали генерировать миллиарды запросов в секунду к системам ТСПУ Роскомнадзора. Это происходит в ответ на попытки блокировки: когда РКН проверяет доступность мессенджера для последующей блокировки, прокси-серверы Telegram отвечают массовыми «мусорными» запросами, перегружая оборудование ведомства.
Перегрузка инфраструктуры: оборудование интернет-провайдеров не справляется с обработкой такого объёма запросов
Каскадные сбои: в некоторых регионах наблюдаются нестабильная работа сервиса
Побочные эффекты: зафиксированы случаи, когда из-за сбоев начали работать ранее заблокированные платформы, а "белые списки" (перечни разрешённых ресурсов) перестали функционировать должным образом
Важно: данная информация исходит из неофициальных источников и требует подтверждения.
Контекст: блокировки контента
Проблемы возникли на фоне того, что сам Telegram активизировал блокировку каналов с нежелательным контентом. Это могло спровоцировать изменения в работе протоколов мессенджера и, как следствие, повлиять на характер сетевого трафика.
Реакция властей
Депутаты Госдумы обратились к Роскомнадзору с требованием объяснить причины замедления работы Telegram в России. Парламентарии выразили обеспокоенность массовыми жалобами пользователей на сбои в работе мессенджера.
Интересно, что претензии к регулятору поступают именно после того, как Telegram начал самостоятельно блокировать контент — действие, которое ранее от платформы активно требовалось.
Что это значит для пользователей
Возможны задержки в доставке сообщений
Нестабильная работа при загрузке медиафайлов
Региональные различия в качестве связи
Непредсказуемость работы сервиса в ближайшее время
Кто победит в этой битве? Я ставлю на телеграмм! Паша умный малый.
Принимаем заявки на доклады infra.conf 2026 до 1 апреля
Команда Yandex Infrastructure приглашает докладчиков на большую конференцию по инфраструктуре — infra.conf 2026. В этом году мы встретимся 4 июня уже в третий раз и обсудим ключевые темы, которые касаются обеспечения высоких нагрузок и не только:
инструменты разработки и практики управления разработкой,
базы данных и стораджи,
принципы и практики обеспечения надёжности и доступности,
управление инцидентами
и многое другое.
Отдельное внимание уделим построению и особенностям эксплуатации инфраструктуры в эпоху ML.
Приём заявок на выступление открыт до 1 апреля включительно в этой форме. Чтобы заявить свою тему на этом этапе, достаточно тезисов и общего плана. Координатор конференции и участники программного комитета свяжутся с каждым спикером для обсуждения материала, а финальное решение по докладам будет принято до 1 мая.
