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

С момента написания первой статьи о B4 прошло полгода. Казалось бы, не очень много времени, но софтина получила ну очень большое количество фич, о которых хочется рассказать подробно. Не буду скрывать: хабраэффект сделал своё дело, и благодаря большому интересу после первой статьи очень многие не разочаровались в отсутствии какого-то функционала, а активно помогали - коммуникацией, запросами, тестированием, - благодаря чему все эти фичи в B4 и появились.

В итоге на сегодняшний день B4 - это не инструмент для обхода блокировок (коим и задумывался изначально), а полноценный сетевой мультитул с гибкой и продвинутой маршрутизацией таргетированного трафика.

В стандартных клиентах, таких как v2rayN, используются специальные (geo) файлы, которые позволяют проксировать, блокировать трафик, а также пропускать его напрямую в зависимости от домена/IP адреса назначения. Пользователь @runetfreedomсоздал такие файлы для российских пользователей, за что ему большое спасибо. В теории, настроив маршрутизацию с этими файлами один раз, не нужно постоянно включать/выключать VPN или прокси при пользовании интернетом, так как клиент вроде v2rayN проксирует только заблокированные сайты. На практике же...

Когда на графиках мониторинга появляется аномальный всплеск трафика, ваш первый порыв — сразу врубить фильтры и блокировать всё подозрительное, но на практике именно подобное чаще всего приводит к ошибкам.

На самом деле DDoS-защита начинается не с выбора сервиса и не с настройки правил — она начинается с диагностики. В этой статье мы разберём полный цикл: от момента появления алерта до выбора между Always-On и On-Demand моделями защиты.

Отказоустойчивость в промышленном Ethernet не всегда означает предсказуемость. Даже при рабочем резервировании асимметрия задержек может сбить синхронизацию, исказить расчеты PTP и привести к ошибкам в управлении.

Разбираем, откуда берется эта проблема и как учитывать ее при проектировании сети.

Умная квартира в новостройке: что у системы под капотом и какие ошибки допускают застройщики

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

На рынке умных технологий для многоквартирных домов (МКД) до сих пор живут два стереотипа: «это дорого» и «жители всё равно не пользуются». Каждый раз, когда я слышу это на переговорах, предлагаю посмотреть на цифры реальных строящихся объектов — и на то, как система умного дома устроена внутри. После этого тональность разговора обычно меняется.

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

Два объекта, две комплектации

Первый объект — ЖК класса «Бизнес+». В доме 184 квартиры, 25 этажей. Он прошёл оценку по методике Единого ресурса застройщиков (ЕРЗ) и получил статус «умного дом класса А» — это высший уровень цифровизации жилых зданий.

Второй — ЖК класса «Комфорт». Разноэтажная застройка, 963 квартиры, паркинг на 150 машино-мест. Объекты строили разные застройщики, но умная квартира в обоих случаях реализована на одной платформе.

Всем привет! Я Никита, тимлид команды Android в Банки.ру. 

Недавно, внедряя в приложение фичу авторизации без SMS-кода (seamless), мы столкнулись с тем, что она в упор отказывалась работать – но только на Android. Мы дебажили ее полторы недели, перепробовали все возможные варианты и закошмарили всех доступных операторов связи, прежде чем узнали, что все дело было… в энергосбережении.

В статье рассказал про наш путь борьбы с энергосбережением и, возможно, это сэкономит вам десятки часов дебага.

Привет, Habr! Меня зовут Валентин, я DevOps-инженер команды Platform V Kintsugi. Мы занимаемся развитием облачного сервиса и на практике регулярно сталкиваемся как с архитектурными задачами построения распределённых систем, так и с вопросами обеспечения их безопасности.

В предыдущей части мы подробно разобрали механизм делегирования TLS-соединения на уровень Service Mesh и показали, как Egress Gateway может выступать полноценным участником PostgreSQL handshake. Однако этот сценарий рассматривался в упрощённой конфигурации — один сервис, один сертификат, одно подключение.

С чего все началось

Хотел простую вещь: отслеживать цену на пару товаров, которые ждал со скидкой. Чтобы не заходить руками каждый день, а получить уведомление, когда подешевело.

Думал, это вечер работы. requests.get(), выдрать цену, сравнить, отправить в телегу (упрощенно, конечно).

Оказалось, парсинг цен на маркетплейсах — это не про HTTP‑запрос. Это про репутацию IP‑адресов, про то, как браузер выдает себя поведением, и — на финале — про пост‑квантовую криптографию в TLS‑рукопожатии. Три площадки (Ozon, WB, Яндекс.Маркет) дали мне три совершенно разных уровня защиты, и на каждом я застревал по‑своему.

Это первая (после нулевой) статья из серии Нейро сети для самых маленьких, в которой мы разбираем инфраструктуру для запуска нейронных сетей.

Для обучения и инференса нейросетей и для любых видов High Performance Computing используются специализированные технологии: GPU/TPU, RDMA, Kernel bypass, NVLink, InfiniBand, RoCE и другие. Про некоторые из них большинство только что-то слышали, но сталкиваться с ними не приходилось.

Нельзя просто взять ванильный стек Linux, воткнуть в него 400Gb Ethernet+IP и получить рабочее решение. Почему?

Потому что общее решение на масштабе в большинстве случаев проигрывает специализированным как в скорости, так и в стоимости. Как бы странно последнее ни звучало.

Доменные имена не резолвятся, страницы висят, а по IP всё доступно. В логах DNS‑сервера при этом чисто, BIND запущен, конфигурация на первый взгляд выглядит рабочей.

Разбираемся, как одна ошибка в forwarders может отправить DNS‑запросы по кругу и превратить обычный резолвинг в цепочку таймаутов.

Когда очередной мессенджер внезапно перестает работать без специальных инструментов, о которых теперь нельзя публично упоминать вслух, многие неожиданно вспоминают, что до эпохи «ватсапов» и «телеграмов» человечество вполне успешно общалось по электронной почте. Тем более что адрес e-mail сегодня есть практически у каждого. Правда, стоило пользователям снова вспомнить об этой технологии, как выяснилось, что и здесь не всё спокойно.

С месяц назад в Рунете начали циркулировать тревожные слухи: популярные почтовые сервисы вроде Яндекс Почты и Mail.ru якобы один за другим отключают бесплатный доступ по протоколам IMAP, POP3 и SMTP, благодаря которым почта десятилетиями работала через привычные внешние клиенты. Почитав новости (в том числе и на Хабре), я решил разобраться, какие службы действительно продолжают работать с почтовыми программами вместо веб-интерфейса и насколько удобно ими пользоваться. Результатами этих изысканий и хочу сегодня поделиться.

TLS 1.3 с прямой секретностью - это правильный выбор. Если завтра скомпрометируют серверный ключ - прошлые сессии не расшифруются. Эфемерные ключи уничтожены. Все продумано.

Проблема в том, что это защита от одного сценария. Не от того, о котором идет речь.

Привет, Хабр! Меня зовут Максим Теплых, эксперт по тестированию на проникновение в ИТ-компании Innostage. В этой статье я хочу рассмотреть тему, которая с годами становится все более актуальной — тестирование систем, использующих ГОСТ TLS. Кратко расскажу о самой технологии, а также покажу подходы и наработки, которые применяем на практике. 

Заранее приношу извинения за объемное и несколько затянутое введение. Хотя изложение начинается не с динозавров и не с истории древней Руси, тему все же необходимо раскрыть с некоторой предыстории.

Вы задумывались когда‑то, как устроены вот эти окончания адресов разных сайтов? Например, как работают.com,.org? Для чего они придумывались и кто ими сейчас управляет? Сегодня я расскажу невероятную историю о том, как закрытая система стала невероятно огромным и миллионным рынком. Встречайте — TLD, ДВУ или просто домены верхнего уровня.

Мы с другом учимся в Китае. В апреле, в очередной раз меняя умерший VPN, решили собрать свой, заточенный под Great Firewall, на протоколе Reality: VPN‑трафик в нём выглядит для системы фильтрации как обычная HTTPS‑сессия с каким‑нибудь сторонним сайтом. Я взял на себя бэкенд, бота и Mini App. Друг отвечал за серверную часть и ноды.

Ниже — про два месяца разработки, три версии интерфейса и отказ от целой механики из‑за банков.

Когда звонок начинается через Wi‑Fi, а продолжается уже в LTE, для пользователя ничего не происходит — разговор просто не обрывается. Но внутри сети в этот момент запускается цепочка сетевых процедур.

В статье разбираем как работает хэндовер по фазам и показываем, как переход выглядит в логах.

Попался вот тут интересный проект https://habr.com/ru/articles/1052536 - дай, думаю, потестирую, как оно работает?

А потестировать сходу нельзя, в релизах имеются разные сборки под разные платформы, вот только для моей arm64 (aarch64) нет.
Надо бы собрать - но оно написано на Rust, с Rust я не работаю, поэтому на компьютере ничего нужного для сборки нет, устанавливать всё это на настроенный компьютер как-то не очень хочется - но ведь можно сделать это в контейнере!

И получилась вот такая пошаговая инструкция:

Представьте, что вы перенеслись в 7 августа 1996 года. Закройте глаза и вообразите мир, где напряжённость в отношениях с Россией, Китаем и Ближним Востоком высока, люди обеспокоены технологическим пузырём, а брюки-клёш снова в моде. Трудно представить, я знаю.

Если совсем коротко: я написал свой VPN на Rust — побайтово-корректный TLS 1.3 с заёмом чужого сертификата, гибридное постквантовое рукопожатие, пять режимов маскировки и под 700 Мбит/с на скачивание. Ниже — как это устроено изнутри и десяток шишек, на которых я учился. Но начать хочется издалека.

В облачных сетях принято разделять два уровня: физический Underlay и виртуальный Overlay. Если Underlay — это фундамент здания (кабели, коммутаторы, базовая IP-связность), то Overlay — инженерные коммуникации: невидимые глазу, но без которых жизнь в доме остановится. От того, насколько эффективно и надёжно спроектирован Overlay, напрямую зависят скорость пользовательских приложений и стабильность всей платформы.

Привет! Меня зовут Валерий Симаков, я разработчик команды Network DPL в MWS Cloud Platform. Сегодня мы подробно поговорим о сетевой составляющей нашего облака, а именно об устройстве Data Plane (DPL) в Overlay-слое — том самом слое, который и отвечает за передачу пользовательского трафика. Мы разберём, как из разрозненных компонентов рождается единый, слаженный механизм передачи данных. Благодарю коллег из команды Network DPL за помощь в подготовке статьи.