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

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

Без суда. Без объяснений. Просто потому что «так надо».

В пакет «Антифрод 2.0» тихо добавили правки, которые превращают хостинг-провайдеров из нейтральных посредников в контролёров. Теперь они должны проверять клиентов, сверяться с базами Роскомнадзора и, если что — разрывать договор.

Как хостер должен понять, что у вас внутри VPS — корпоративный VPN или «неправильный» туннель?
Как отличить разработчика, который подключается к серверу, от человека, который просто смотрит YouTube?
И главное — кто будет платить за весь этот контроль?

Параллельно происходит ещё кое-что:
- операторы замораживают расширение каналов в Европу
- крупные сервисы уже режут пользователей с VPN
- из App Store исчезают десятки "неугодных" VPN-сервисов
- бизнесу рассылают методички «как искать VPN»

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

Гайки закручиваются. И в этот раз — не только для «обходчиков блокировок».

Иногда случается такая задача: за непродолжительное время нужно проверить или продемонстрировать работу сетевого оборудования с авторизацией через tacacs. На стенде, с не очень большим количеством устройств (в пределах пары десятков). Но на вопрос про «подключение виртуалки с tacacs+» выясняется, что в текущих реалиях – никак. А вариант «оставить на пару недель свой ноут» (на котором есть VmWare WS с нужной виртуалкой) ну совсем не прельщает.

Эта статья описывает, как внедрить TACACS.NET на Windows в рамках стенда: от базовой настройки до проверки работоспособности и типовых моментов, которые всплывают при первом запуске. Ориентирована на системных инженеров и администраторов, которым нужно быстро перейти от «чистого Windows» к конфигурации для работы на стенде.

Привет всем! Меня зовут Саша Иргер, я эксперт по разработке ПО в департаменте проектирования и разработки пакетного ядра сети в YADRO. Вчера мой коллега опубликовал на Хабре статью про Policy Control: как и зачем классифицировать трафик в сотовой сети. Сегодня продолжу тему и разберу, как конкретно работает User Plane. По сути, он организован так, чтобы удовлетворить требования от Policy Control. Давайте посмотрим, что здесь интересного.

Привет, Хабр! Меня зовут Алексей, и я продолжаю копаться в беспроводных технологиях. В прошлый раз мы настраивали Wi-Fi в OpenWrt для максимальной стабильности и покрытия. Сегодня я хочу поговорить о другой, не менее увлекательной теме - мониторинге беспроводного эфира с помощью легедарного роутера TP-Link MR3020.Многие скажут: «Зачем мне это? У меня и так всё работает». А я отвечу: возможности, которые открываются, могут удивить. Давайте сразу к делу.

В апреле 2026 года мы выпускаем обновление Ideco NGFW Novum. Это плановый релиз, в котором развиваются пять направлений: централизованное управление, защита DNS, управление удалённым доступом, SD-WAN и кластеризация. Ниже разбираем, что именно изменилось и какие задачи это решает.

В IETF появился draft, который обещает интернет без dual-stack, без CGNAT и без мучительного перехода. Спасение для всех, кто двадцать лет тащит IPv6 в гору, не станет будущим сети.

draft-thain-ipv8-00, опубликованный 14 апреля 2026 года на бумаге выглядит слишком хорошо: IPv4 становится подмножеством IPv8, dual-stack будто бы больше не нужен, каждому владельцу ASN достаётся по 2^32 адресов хостов, а сеть получает единую управляемую платформу вместо нынешнего зоопарка из разрозненных сервисов.

История с IPv8 интересна не как новость про новый IP-протокол. Она очень громко показывает, насколько индустрия устала от бесконечного, вязкого и дорогого перехода на IPv6.

Вы открываете YouTube, Twitch или просто обновляете приложение — и, возможно, уже скоро за это придётся платить как за «иностранный трафик».

По обсуждаемым инициативам, после 15 ГБ в месяц каждый дополнительный гигабайт может стоить около 150 рублей — формально для борьбы с VPN.

Звучит просто: VPN = зарубежный сервер = иностранный трафик.
Значит, нужно просто посчитать и ограничить.

Проблема в том, что интернет так не работает.

Тот же Twitch сегодня может отдавать вам видео из локального кэша в вашем городе, а завтра — из Франкфурта. API вашего приложения может находиться в Нидерландах, а сайт с российским доменом — работать через зарубежный CDN.

И в какой-то момент становится непонятно: где вообще проходит граница между «нашим» и «чужим» трафиком?

Я решил разобраться в этом с технической стороны:

- что на самом деле видит провайдер

- почему он не может «заглянуть внутрь» вашего трафика

- как устроены VPN и чем они отличаются (или не отличаются) от обычного HTTPS

- можно ли реально отличить VPN от обычного трафика

- и почему идея считать «иностранные гигабайты» выглядит куда более спорной, чем кажется

И главный вопрос, к которому всё это приводит: можно ли вообще технически корректно реализовать такие ограничения да так, чтобы не сломать половину интернета?

Если коротко — всё чуть сложнее, чем звучит в новостях.

Привет, Хабр! Меня зовут Влад Редров, я старший инженер-программист в отделе разработки компонентов опорной сети 5G в YADRO. Сегодня расскажу про Policy and Charging Control (PCC): будем ставить проблемы, а потом через способы их решения наращивать набор PCC-фич и осознавать логику их работы. Разберем, как ограничивать скорость сессии для каждого мобильного устройства через Session-AMBR и QoS-характеристики, применять QoS-характеристики к разным сервисам, тарифицировать каждый сервис отдельно и еще много всего интересного. Погнали!

Если вы когда-нибудь пытались поднять прокси для Telegram на сервере, то знаете, что такое «мессенджер не грузит».

В этой инструкции я предлагаю рассмотреть подробную, пошаговую установку MTproto, при помощи MTProto Panel и MTProto Node и для VLESS+REALITY используем 3x-ui.

Недавно выяснилось, что довольно легко на смартфоне (Android) передать IP VPS в РКН с учеом следующих вещей:

1. Многие российские сервисы превращаются в филиалы РКН.

2. Приложение на Android может получить список сетевых интерфейсов на устройстве через NetworkInterface/ConnectivityManager. После чего обнаружить IP-адрес путем выполнения сетевого запроса через найденный интерфейс: curl -shttps://ifconfig.me/ip --interface $interface либо найдя запущенный socks5 прокси без авторизации. И от этой проблемы страдают большинство клиентов

Но как обстоят дела на desktop?

Всем привет, расскажу про свою конфигурацию для доступа к своему любимому Youtube и нужным мне сервисам.

Буду излагать максимально лаконично и без всяких ИИ.

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

Всем привет! На связи Дмитрий Федосов, руководитель отдела наступательной безопасности экспертного центра безопасности (PT ESC) Positive Technologies, и Владислав Дриев, ведущий специалист нашего подразделения. Мы развиваем технологии автопентеста в рамках продукта PT Dephaze. Сегодня хотим наглядно показать, как автоматизированный взлом собственной инфраструктуры помогает выявлять реальные векторы атак, которыми злоумышленники могут воспользоваться в любую минуту.

С момента запуска PT Dephaze наша команда провела более 60 «пилотов» в организациях России и не только. Мы проанализировали этот опыт, собрали обратную связь от клиентов и улучшили технологии. В этой статье предлагаем вместе погрузиться в процесс использования нашей системы автопентеста на основании опыта наших пользователей. Разберем результаты и варианты их использования в защите.

Всем привет! 

Если вы хоть раз пытались свести список установленного ПО из разных источников, вы знаете, как это выглядит. Один и тот же продукт может приезжать как MS Office 2019, Microsoft Office Pro, Office 19 x64 или вообще без версии (как вам, например, MS Comp Ivanov?).

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

Мы в Инферит ИТМен как раз занимаемся этими задачами — развиваем систему учета и контроля ИТ-инфраструктуры. Недавно усилили ее в этой части: добавили библиотеку ПО «Призма данных».

— Дед, Gmail опять всё перекрутил. Письма теряются, половина — реклама, интерфейс другой, ничего не понятно. Ты же у нас главный по всяким проводам, придумай что‑нибудь.

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

Начал я, как ни странно, не с железа, а с имени.
Объяснил внуку, что домен — это человеческое имя вместо голых цифр. Ящик vnyuk@ded-v-derevne.ru звучит всё‑таки повеселее, чем vanya2008_mega@какой‑нибудь‑бесплатный‑сервис. Домен зарегистрировали, я зашёл в панель и занялся тем, что обычно никого не волнует, пока всё работает, — настройкой записей, которые говорят остальному миру, куда нести письма.

Рассказывал внуку на пальцах: вот у нас есть «адрес дома» — запись, где написано, на какой IP смотреть, когда кто‑то ищет ded-v-derevne.ru. Есть особая запись для почты — мол, «письма складывать вот сюда, в этот ящик на сервере». Есть ещё строка с перечислением тех, кому вообще можно доверять отправку писем от нашего имени — чтобы спамеры не прикидывались нами. Для него это звучало как какая‑то бюрократия, для меня — как привычная настройка, которой просто давно не занимался.

Мы покажем что конкретно остаётся на iOS и Android после удаления Telegram и Signal, через какие инструменты это находится и сколько времени проходит, прежде чем артефакты начинают исчезать.

Я никогда не понимал, как именно 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;

Теперь у ва