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

Я никогда не понимал, как именно traceroute обнаруживает каждый сетевой переход. Оказывается, всё дело в хитром трюке с TTL и примерно в 80 строках на Rust.

Мы уже привыкли жить в глобальном информационном мире, где, с одной стороны, довольно важно знать точное время, а с другой стороны - легко его получить, достаточно настроить на компьютере NTP, да вот хотя бы просто выполнить команду типа ntpdate pool.ntp.org.

Но есть нюанс: со всеми этими замедлениями, блокировками и "белыми списками" больше нет никакой гарантии, что как раз в нужный момент они не заблокируют нам и NTP протокол, ведь известные мировые NTP-сервера вряд ли будут в белых списках, а использовать какие-нибудь другие - ну, вспоминается история пропадания некоторых доменных имен из НСДИ, недоступность Гугла через мобильный интернет, и заявленный ввод платы "за доступ к часам точного времени", что бы под этим не подразумевалось.

В общем, спасение утопающих...
К тому же, как говорят, "любой, кто увидел Ардуино - рано или поздно делает часы или метеостанцию".
Простые часы мы делать не будем, а сделаем вполне IT-шный NTP-сервер.

Если администрировать Linux-сервера достаточно долго, рано или поздно сталкиваешься с сетевой фильтрацией. Где-то нужно закрыть лишние порты, где-то ограничить доступ между сегментами сети, а где-то настроить NAT.

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

В этой статье разберёмся, как появился nftables, чем он отличается от привычного iptables, как устроена его архитектура и как на практике использовать его для настройки firewall на Linux-сервере.

Naïve-клиент для iOS и macOS и сервер, устанавливающийся одной командой

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

Как найти причину латенси в пайплайне обработки HTTP запроса за 5 минут: разбираем шаг за шагом

Я достаточно ленивый и рациональный человек. В конце прошлого года у CloudFlare и его клиентов были непростые дни и утро Infra инженеров начиналось не с кофе. Плюс, те, кто много работает с CF знают про 503 и 520 ошибки и, если вы не на Enterprise тарифе, они также могу доставить неприятности. Хочу поделиться подходом и инструментом, которые помогли решить эти проблема и рационализировать/автоматизировать их решение в последствии.

Алерт в три часа ночи: время ответа выросло с 150 ms до 1.2 секунды. Или хуже — пользователи получают 502/503/504. Дежурный инженер открывает дашборд и видит красный график. Что-то тормозит. Но что именно?

Это CDN? Ingress? Приложение? База? Сеть между чем-то из вышеперечисленного? Каждый вариант ведёт к совершенно разному исправлению: перезапуск пода не поможет, если проблема в маршрутизации CDN, а звонок в поддержку хостера бесполезен, если у вас медленный SQL-запрос. Гадать дорого — особенно в три часа ночи.

В этой статье я покажу системный подход к поиску узкого места. Шаг за шагом, с минимумом телодвижений, используя данные, которые у вас скорее всего уже есть (или которые легко начать собирать). Акцент будет на CDN, Hosting Provider, Ingress.

Путь запроса

Прежде чем искать проблему, давайте зафиксируем, через какие этапы проходит типичный HTTP-запрос. Это простая архитектура, характерная для небольшой команды — но знакомая и наглядная(межсерверное взаимодействие в Netflix в качестве примера не будем использовать):

User → CDN → SLB (Nginx) → App(POD) → Connection Pooler → RDBMS

Шесть слоёв. Каждый может вносить свою задержку, свои ошибки — и каждый дает свои сигналы для диагностики.

Ключевое наблюдение: SLB (балансировщик, Nginx, HAProxy, ALB) сидит в центре и является вашей точкой отсчёта. Его логи подскажут, куда смотреть — налево (сеть, CDN) или направо (приложение, база).

Шаг 1. Точка опоры: логи балансировщика

Это лучший стартовый шаг — особенно если у вас еще нет развитого observability-стека и внешнего мониторинга. Достаточно Nginx access log.

Два ключевых значения:

Переменная Nginx Что измеряет $request_time Полное время обработки запроса — от первого байта клиента до последнего байта ответа $upstream_response_time Время ожидания ответа от upstream (вашего приложения)

Если вы ещё не логируете эти значения, добавьте их в log_format:

log_format timing '$remote_addr - $request_uri ' 'status=$status ' 'rt=$request_time ' 'uct=$upstream_connect_time ' 'urt=$upstream_response_time'; access_log /var/log/nginx/access.log timing;

Теперь у ва

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

Важная оговорка. Я работаю в малом бизнесе. Тратить лишние несколько тысяч рублей на битрикс или другие аналоги можно, но не хочется. К тому же телеграм закрывал все возникающие вопросы и проблемы. Если уж тысячи людей оставили без выбора, отечественный аналог может просто скопировать функционал телеграма, проверенный годами работы. К сожалению, МАХ является лишь копией ICQ NEW (в последствии VK Teams), застрявших в 2016 году. Некое понятие о работе кода я имею, но программистом не являюсь. Поэтому ниже пойдёт чистый "пользовательский" опыт.

И введём термина Б50 - бухгалтер пятидесяти лет. Вообразите себе обычную трудягу, которой поставили приложение МАХ. Она им пользуется каждый день, не разбирается ни в коде, ни в костылях, ни в банальных вещах по типу "перенесите иконку на панель задач". Под этот термин попадают и узкопрофильные специалисты - в трафаретной печати или деколи они просто асы. Но когда дело доходит до компухтеров - они предпочитают позвать сисадмина или любого молодого человека, по возрасту своему умеющего разбираться с технологиями.

Anthropic выпустила модель, которая за несколько недель нашла тысячи неизвестных уязвимостей во всех основных ОС и браузерах. ФРС и Минфин США экстренно собрали руководителей крупнейших банков. Разбираемся, что это значит для архитектуры безопасности в реальной организации – и что CISO стоит пересмотреть уже сейчас.

Три события апреля 2026 года

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

Событие первое. 7 апреля Anthropic представила Claude Mythos Preview – фронтирную LLM (Large Language Model – большая языковая модель), которая автономно обнаружила тысячи критических уязвимостей нулевого дня во всех основных операционных системах и браузерах. Среди находок – 27-летний баг в OpenBSD и 16-летняя уязвимость в FFmpeg. Но модель не просто обнаруживает уязвимости – она самостоятельно выстраивает цепочки из нескольких багов и создаёт рабочие эксплойты. В одном из примеров Mythos Preview скомбинировала четыре уязвимости в браузере, чтобы выйти из песочницы рендерера и обойти защиту ОС.

Чтобы оценить масштаб: предыдущая модель Anthropic, Claude Opus 4.6, успешно эксплуатировала уязвимости в JavaScript-движке Firefox менее чем в 1% случаев. Mythos Preview – в 72%. Но даже Opus, например, за 4 часа смог написать два рабочих эксплойта к уязвимости CVE-2026-4747 в ядре FreeBSD.

Событие второе. Anthropic запустила Project Glasswing – закрытый консорциум, куда вошли AWS, Google, Microsoft, Apple, CrowdStrike, Palo Alto Networks, Cisco, NVIDIA, JPMorgan Chase, Linux Foundation и ещё более 40 организаций. Задача – применить возможности Mythos для защиты критической инфраструктуры, пока модели с аналогичными способностями не стали доступны злоумышленникам. Anthropic выделяет до $100 млн в кредитах на использование модели участниками и $4 млн – на поддержку безопасности open-source проектов. Публичного доступа к Mythos нет. Конкретного срока выхода – тоже (и скорее всего в таком виде модель не выйдет из-за слишком высокой стоимости работы, а постепенно способности Opus 5.0, 6.0 догонят ее).

В предыдущей статье мы обсуждали некоторые меры, которые пользователь может предпринять против spyware, детектирующего факт использования VPN и сливающего полученные данные “Большому брату”.

Если судить по комментариям (и автор в целом согласен с их логикой), то в условиях тотального стукачества иных выходов, кроме как иметь два смартфона (а, возможно, и два десктопа!), действительно почти не остаётся. На первый взгляд это и правда так.

Однако если немного подумать, то окажется, что техническое решение всё-таки есть. Да, оно относительно дорогое (минимальные расходы около 1000-1500 рублей в месяц), но оно существует!

Если интересна архитектура VPN-сервиса, устойчивая к наличию spyware на клиенте, то

Жил-был я. И был у этого "я" небольшой пул виртуальных машин. Но пришло время, и появилось осознание, что у моего облачного провайдера (пусть будет С) не все условия мне нравятся. А, вот, у другого провайдера (путь будет провайдер В) условия для некоторых виртуалок повкуснее. И замыслил я неладное. Я решил разнести инфраструктуру между разными провайдерами. Но эту, так называемую, инфру необходимо скоммутировать между собой. Потому что гонять сервисный трафик через интернеты - дурная затея. И родился у меня план. Даже не так ПЛААААН!!! А следом, и эта статья. Предвосхищая вопросы почему не обычный VPN, отвечу: это во-первых, скучно, во-вторых, не подлежит публикации, в-третьих, в последнее время нестабильное ввиду блокировок. Disclaimer! Цель статьи - рассмотреть вариант осуществить связность конкретных элементов инфраструктуры, используя публичные каналы связи. Статья не ставит целью описать способ обхода блокировок и осуждает (хоть и не искренне) подобные статьи.

Приветствую тебя, %USERNAME%! Ох и давно я не писал ничего на Хабр (10+ лет) — чернила высохли, перо затупилось. И все же, читая последние сводки, мой академический интерес проснулся.

Если вдруг пропустили и не понимаете о чем я, то информационный фон сейчас бурлит: тут и новости про то, как большинство популярных приложений детектируют VPN, и выход утилиты RKNHardering, и методички по борьбе с обходами, и тревожные отчеты о свободе интернета в 2026 году. Но последней каплей стала статья про критическую уязвимость VLESS-клиентов, из-за которой «скоро все ваши VPN будут заблокированы».

Смахнув скупую мужскую слезу, вызванную этим богатым на эмоции потоком, я задумался: а насколько вообще сложно детектируется VPN на Android? Оказалось, что даже с использованием сплит-туннелирования у приложений остается вагон возможностей для детекта (хоть и не 100%, но все же).

В первой части я рассказывал, как уличный NR‑712 вытащил нашу деревню из «цифрового болота» и дал в дом нормальный интернет, а не мучения на 3 Мбит/с. Во второй части хочу показать кухню: какое железо реально работает в поле, как я подсветил Wi‑Fi на полдеревни и чем это всё обернулось людям — от школоты до стариков.

Что если бы каждое устройство в интернете имело свой уникальный адрес, было доступно напрямую из любой точки мира, а весь трафик шифровался автоматически - без настройки VPN, без проброса портов, без центральных серверов?

Именно так работает Yggdrasil - mesh-сеть, в которой ваш адрес вычисляется из криптографического ключа, маршруты строятся сами, а NAT перестаёт быть проблемой. Разбираемся, как это устроено.

Технология eBPF — интересная штука. С её помощью можно без труда внедрять в ядро Linux фрагменты кода, которые затем компилируются в коды операций (опкоды), которые гарантированно не обрушат работу ядра. Набор допустимых инструкций ограничен, переходы назад не допускаются (поэтому не будет никаких неопределённых циклов). При этом вы не можете разыменовывать указатели, но вместо этого можете выполнять проверяемые операции считывания через указатели, которые потенциально могут оказаться неудачными, но при этом не спровоцируют паник на всю систему. eBPF в ядре Linux можно закреплять в тысячах хуков (точек перехвата), в качестве которых могут выступать u-пробы, k-пробы, точки трассировки и даже такие штуки как отказы страниц. У eBPF есть целый спектр захватывающих возможностей, которые при этом очень активно разрабатываются. Фичи, поддерживаемые в каждой конкретной версии ядра, перечислены в виде списка по этому адресу.

Здравствуйте! Меня зовут Максим Захаренко, я CEO облачной платформы и автор медиа «вАЙТИ». Хочу поделиться нашим опытом и мыслями о том, как в России строится инфраструктура для облачных сервисов с минимальной задержкой (low-latency). Это взгляд изнутри — от лица провайдера, который каждый день сталкивается с задачей ускорения облака для B2B-клиентов. Поговорим о том, почему задержка — такой важный параметр, как устроены современные дата-центры и сети, какие решения применяем мы и другие российские компании и с какими вызовами приходится сталкиваться.

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

Это — третья часть «Внедрения VMware Horizon глазами инженера». В этот раз разберёмся с сетевой связностью, из чего вообще состоит Horizon и как именовать весь этот «зоопарк».

В предыдущих частях:

Часть 1.

Часть 2.

Сетевое оборудование

В прошлой статье я обещал слегка окунуться в мир сетевого оборудования.

Закрыть тему vSAN, не разобравшись со схемой сети, невозможно. Предполагается, что читатель уже знаком с базовыми принципами сетевой модели ESXi/vSphere — иначе только этой теме пришлось бы посвящать отдельный цикл статей.

Существует множество подходов к построению сети для кластеров VDI. Мы рассмотрим один из практических вариантов — тот, который используем сами в ПИК, — и на его основе набросаем типовую схему подключения ESXi к коммутаторам. Нам потребуется как минимум три отдельных сети. Две из них (для ВМ и vSAN) должны быть высокоскоростными — 10, а лучше 25 гигабит.

С интересом прочитала статью @maybe_elf «Проекту IPv6 исполнилось 30 лет». Но очень удивилась некоторым комментариям к ней. К сожалению, у многих российских ИТ инженеров до сих пор нет понимания неизбежности перехода на IPv6. Поддерживаю позицию Сергея Федотова @FSA. И полностью согласна с мнением Сергея @kovserg, что «на самом деле проблема не в ipv6, а в том что людям лень разбираться в дебрях спецификаций».

Решила поделиться опытом проектирования и внедрения IPv6 соблюдая отраслевые спецификации. Накопился внушительный объем материала (разработка, внедрение, безопасность), но начинать надо сначала и сверху. Так что цель этой статьи – предоставить информацию и рекомендации, касающиеся аспектов планирования адресации при развертывании IPv6.

Но прежде, чем начать я бы хотела добавить еще один аргумент за IPv6. Ну, согласитесь – это красиво!

Десять устройств дома, и каждому нужен прозрачный доступ к моей удалённой инфраструктуре. Ставить клиент защищённого канала на телевизор и колонку — невозможно, на телефон — клиент «молча» отключается, и трафик идёт мимо канала.

Я настроил прозрачный прокси-шлюз на роутере: VLESS+Reality+XTLS-Vision через TPROXY на OpenWrt. Сплит-роутинг по GeoIP и доменам, автообновление списка серверов из подписки каждые 30 минут, балансировка по задержке, procd с автоперезапуском. В статье — полный путь от коробочного Cudy TR3000 до рабочей системы: nftables, policy routing, base64-декодер на awk и все баги, которые я нашёл по дороге.

Приветствую всех!

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

И вот как-то раз я задумался: а как насчёт попробовать связать пару компьютеров по такой сети уже в наши дни? Что из этого получится, и стоит ли вообще пробовать всё это? Сейчас и узнаем…

Telegram выкатил обновление для iOS — MTProto-прокси снова работают. Обновил, подключил, медиа грузятся. Разбираю, почему прокси ломались именно на iOS, как Fake TLS шифрует MTProto-трафик под обычный HTTPS, и почему прокси на российском VPS работает лучше зарубежного.

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

Выделяем ПК или VM, устанавливаем Linux, я предпочитаю Debian (сейчас актуальная версия 12). Устанавливаем Docker и Docker-Compose по оф. инструкции Добавление репозиториев