XTLS/Xray-core - инструмент для обхода цензуры с открытым исходным кодом. Он хорошо известен в Китае своими новыми и практичными концептуальными технологиями, а также создателем RPRX, который однажды исчез и, как считалось, сбежал. К таким технологиям относятся VLESS, XTLS-Vision, XUDP... О какой-то из них вы точно слышали или использовали.

С момента как в Китае началось внедрение новой системы цензурирование: белый список SNI (Server name indication), все инструменты обхода на основе TLS до появления REALITY и ShadowTLS, подключаемые напрямую или через транзит или CDN, стали недоступны.

Ранее широкое внимание привлек инструмент обхода ShadowTLS. Однако в то время ShadowTLS все еще находился в версии v1 с неполной кодовой базой и слабой устойчивостью к цензуре. Позже в Reality появилась возможность обходить цензуру на основе белого списка SNI, и он был интегрирован со зрелым инструментом обхода Xray-core.

Так как же REALITY обходит эту цензурную стратегию? Как понять ее детали с технической точки зрения? Эти два вопроса будут в центре внимания этой статьи. Интерпретируя исходный код REALITY, мы разберемся с конкретной реализацией REALITY для читателей.

Что такое белый список SNI? В чем связь между SNI и TLS?

Вы, возможно, знаете, что широко используемый протокол безопасности прикладного уровня, основа HTTPS, протокол TLS, имеет свой собственный «процесс рукопожатия» при инициировании соединения.

TLS был «гибридной системой шифрования» с момента разработки его первой версии. Это означает, что TLS использует как асимметричные, так и симметричные алгоритмы шифрования. Симметричные алгоритмы шифрования требуют, чтобы обе стороны имели абсолютно одинаковый ключ, а накладные расходы на шифрование и дешифрование низкие. В то время как асимметричное шифрование требует только обмена открытым ключом в своих соответствующих парах ключей, но требует проверки того, что открытый ключ не был заменен или подделан при обмене ключами, что привело к появлению механизма цифрового сертификата. Кроме того, накладные расходы на асимметричное шифрование и дешифрование высоки. Поэтому TLS использует асимметричное шифрование для передачи ключа, используемого для симметричного шифрования, и для того, чтобы обменять открытый ключ, используемый для асимметричного шифрования, родился механизм рукопожатия TLS.

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

Помните то блаженное время, когда для доступа к любому ресурсу хватало простого WireGuard до сервера в Германии? Я тоже помню. Но эта эпоха закончилась. Недавно я заметил, что мой верный VPN стал лагать, рвать соединение и вести себя так, будто его кто‑то целенаправленно «душит». Это был тот самый момент, когда я понял: игра изменилась. Системы глубокого анализа трафика (DPI) стали умнее, и мой трафик для них был как на ладони.

Это стало моим личным вызовом. Я отправился в путешествие по миру современных средств обхода блокировок, наступил на множество граблей (чего только стоит осознание, что «двойное шифрование» — это миф!), но в итоге нашел свое сокровище — рабочую и относительно устойчивую схему на базе VLESS+Reality и Multi‑hop.

Эта статья — не «серебряная пуля». Это честный, подробный и, надеюсь, полезный гайд по постройке сложной VPN‑цепочки. Мы разберем ее архитектуру, честно поговорим о рисках и соберем все по шагам.

Просили нас тут рассказать про протокол технологию XHTTP в контексте XRay, VLESS и прочих. Просили — рассказываем!

Для начала немного истории. Классическое использование VLESS и подобных прокси‑протоколов (в том числе с использование XTLS‑Reality) предполагает подключение клиента напрямую к прокси‑серверу, который крутится на каком‑нибудь VPS. Однако во многих странах (и в России тоже) под блокировки (или замедления) начали попадать подсети популярных хостеров целиком, а в других странах цензоры начали отслеживать подключения к «одиночным» адресам с большим объемом трафика. Поэтому еще с давних времен обдумывались и проверялись идеи подключения к прокси‑серверам через CDN (сети доставки контента). Чаще всего для этого использовался websocket‑транспорт, но у этого варианта есть два больших недостатка: у него есть один характерный признак (не буду указывать его тут, чтобы не облегчать работу РКН), а во‑вторых, число CDN, которые поддерживают проксирование вебсокетов, не так уж велико, и хотелось бы иметь возможность проксироваться и через те, что не умеют.

Поэтому сначала в известном проекте Tor для бриджей (мостов) придумали транспорт meek, который позволял передавать данные с помощью многочисленные запросов‑ответов по HTTP, и таким образом позволял подключаться к мостам (прокси) через любые CDN. Чуть позже этот же транспорт реализовали в ненадолго воскресшем из мертвых V2Ray. Но у meek есть два очень существенных недостатка, которые вытекают из его принципа работы: скорость работы очень низкая (по сути дела у нас полудуплексная передача и огромный оверхед на постоянные запросы‑ответы), и из‑за огромного количества GET/POST‑запросов каждую секунду, бесплатные CDN довольно быстро могут нас выгнать на мороз, а платные — выкатить солидный счет.

Я уже написал тут много статей на тему установки и настройки прокси‑серверов XRay с недетектируемыми протоколами Shadowsocks-2022, VLESS (с XTLS), и т. п. И один из очень часто поднимаемых в комментариях вопросов звучит так: можно ли с использованием XRay как‑то организовать проброс портов или получать доступ к внутренностям корпоративной сети? Можно, и сейчас я расскажу как.

Итак, что же можно сделать с помощью реверс‑проксирования?

Можно получать доступ к каким‑либо сервисам на хосте за NAT'ом или строгим фаерволом, и даже более того — можно получать доступ к сервисам на других устройствах в локальной сети, к которой имеет доступ этот самый хост за NAT'ом файерволом.

Можно маршрутизировать весь (или некоторый в зависимости от настроенных правил) трафик на хост за NAT'ом или фаерволом и выпускать его оттуда в Интернет.
Например, вы проживаете за границей, хотите оплачивать счета за ЖКХ вашей недвижимости оставшейся России, но сервис оплаты не пускает вас с забугорных IP и не пускает вас с IP‑адресов даже российских VPS‑хостеров. Тогда можно поставить у кого‑нибудь из друзей или родственников в РФ преднастроенный роутер или одноплатник типа Raspberry Pi, который подключится к вашему прокси‑серверу, а вы, в свою очередь, через прокси‑сервер сможете достучаться до этого роутера/р‑пишки и выйти через него во внешний интернет как обычный пользователь, находящийся в России — и всем ресурсам будет виден IP‑адрес российского домашнего интернет‑провайдера.

Можно выборочно пробрасывать порты, например, все подключения на 80 порт прокси‑сервера будут переадресовываться на 80 (или любой другой) порт «изолированного» хоста или еще куда‑то дальше.

Можно даже в теории соорудить псевдо‑VPN, чтобы подключенные клиенты прокси‑сервера могли достукиваться друг до друга.

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

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

Данная статья является доработанной текстовой версией одноименного доклада с конференции C++ CoreHard Autumn 2016, которая проходила в Минске в октябре прошлого года. Желание сделать эту статью возникло под впечатлением о том, что в мире C++ разработчики как бы делятся на два больших и не пересекающихся лагеря. В первом лагере находятся матерые спецы, которые все видели, все знают и все умеют, за плечами у которых десятки собственноручно написанных реализаций Модели Акторов, внутрях у которых хитрые, конечно же самостоятельно сделанные, lock-free очереди и state-of-the-art механизмы обслуживания сообщений. Такие проффи сами часами могут рассказывать про тонкости многопоточного программирования (только почему-то редко это делают). Во втором лагере — зеленые новички, которых волею судьбы занесло в мир C++, которые пока слабо представляют себе различия между unique_ptr и shared_ptr, про шаблоны только слышали, а в области многопоточности имеют поверхностное впечатление только о std::thread, std::mutex и, может быть, std::condition_variable. Для людей из первого лагеря я вряд ли что-нибудь интересное расскажу, а вот разработчикам из второго лагеря попробую вкратце рассказать о том, что Модель Акторов в C++ — это нормально. И что есть ряд готовых инструментов, на примере которых можно увидеть, что же это такое.

В мае 2025 года профессор университета прикладных наук в Санкт-Пёльтене (Австрия) Макс Шлерет опубликовал чёткое научное доказательство, что сильный ИИ логически и математически невозможен из-за фундаментального ограничения — барьера бесконечного выбора (Infinite Choice Barrier, ICB), экспоненциального роста энтропии при увеличении неопределённости.

Однако к доводам профессора никто не прислушался. Мир продолжает готовиться к «революционным переменам», которые почему-то преподносятся как неизбежные.

Большие изменения произойдут в трудовых ресурсах, энергопотреблении и финансовых капиталах. Это эффекты первого порядка. А потом якобы начнётся «фундаментальная трансформация мировой экономики», четвёртая промышленная революция.

Надоело каждый раз лезть в терминал, чтобы скачать видео с YouTube? Мне тоже. Поэтому я сделал нормальный GUI для yt-dlp - без лишних кнопок, с современным интерфейсом и чтобы просто работал. Код на GitHub, готовая сборка тоже есть.

Зачем вообще это делать?

Да, yt-dlp крутой - качает с кучи сайтов, быстрый, надёжный. Но блин, каждый раз набирать команды в консоли - это не для всех. Особенно когда нужно быстро скачать что-то и не париться с параметрами.

Посмотрел на существующие GUI - одни выглядят как из 2005 года, другие напичканы настройками, которые 99% пользователей никогда не трогают. Захотелось сделать что-то простое: вставил ссылку, выбрал качество, скачал. Всё.

Что хотел получить:

Простоту - минимум кликов от ссылки до файла

Нормальный вид - тёмная тема, без уродских кнопок из 90-х

Скорость - никаких тормозов и зависаний

Работает везде - Windows точно, остальные ОС в планах

Не требует установки - скачал exe и пользуешься

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

Моя собственная схема — домашний сервер за WireGuard-эндпоинтом — уже не раз демонстрировала странности: внезапные падения скорости, потеря UDP-пакетов (особенно в мобильных сетях). Всё вроде работает, но как-то не так: туннель подключается, но затем «виснет» или показывает подозрительно низкую пропускную способность. В таких случаях надёжным обходным путём становится туннелирование TCP-трафика через SOCKS5-прокси, например, поверх SSH.

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

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

Дженерики (или generics) существуют во многих языках, таких как Java, C#, и Rust, но для Go это относительно новая фича, введенная в версии 1.18 в 2022 году.

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

Go представила предложение по введению дженериков, которое после долгих обсуждений и тестирований было реализовано в версии 1.18. Это был ответ на просьбу сообщества. + к карме

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

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

Как в Golang логирование поживает? Рассмотрим этот вопрос в статье.

Рассмотрим основные библиотеки и подходы.

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Anatomy of Channels in Go" автора Uday Hiwarale.

Что такое каналы?

Канал — это объект связи, с помощью которого горутины обмениваются данными. Технически это конвейер (или труба), откуда можно считывать или помещать данные. То есть одна горутина может отправить данные в канал, а другая — считать помещенные в этот канал данные.

Создание канала

Go для создания канала предоставляет ключевое слово chan. Канал может передавать данные только одного типа, данные других типов через это канал передавать невозможно.

Недавно мне впервые довелось создавать полностью интернационализированное (i18n) и локализированное (L10n) веб-приложение, в котором я задействоал набор пакетов Go golang.org/x/text. Я обнаружил, что пакеты и инструменты, собранные в golang.org/x/text, невероятно полезны и очень хорошо спроектированы. Однако мне было довольно сложно понять, как объединить все это вместе в реальном приложении.

В этом руководстве я постараюсь объяснить, как вы можете использовать golang.org/x/text для работы с переводами в вашем приложении.

Каждый раз, нажимая кнопку «Connect» в очередном VPN-приложении, я ловил себя на мысли: а что там, под капотом? Как эта магия на самом деле работает на уровне Android? Вокруг сотни готовых решений, но простое пользовательское любопытство переросло в профессиональное: мне захотелось не просто использовать, а понять. Понять, какие подводные камни скрывает VpnService, как реализовать весь цикл от авторизации до поднятия защищённого туннеля и что на этом пути может пойти не так.

Эта статья — мой личный "бортовой журнал". Я не претендую на создание самого безопасного решения, это скорее история о пути, граблях и открытиях для тех, кто тоже решит заглянуть под капот VPN-технологий на Android.

Так родилась идея этого проекта — создать свой, пусть и простой, VPN-клиент. Это не попытка сделать коммерческий продукт, а скорее исследовательское погружение, мой личный "челлендж" и способ разложить всё по полочкам.

Привет, Хабр! В данной статье хочу разобрать auditd - полезный инструмент аудита в Linux, который записывает каждое действие, а скрипт превратит логи в читаемые отчёты и алерты.

Linux-сервер без мониторинга активности пользователей — как дом с открытыми окнами. Проблемы, которые помогает решить auditd:

• Несанкционированный доступ (кто и когда использовать, например, sudo)
• Подозрительные команды (rm -rf, изменение прав, доступ к каким-либо файлам)
• Расследование инцидентов (кто что натыкал перед падением сервера)
• Соответствие корпоративным стандартам (возможно, ИБ требует логирования действий или вы любите контроль)

Решение: auditd + Python-скрипт для анализа и алертов.

HOST1: ip link add grelan type gretap  local <IP1> remote <IP2>
HOST1: ip link set grelan up
HOST1: iptables -I INPUT -p gre -s <IP2> -j ACCEPT
HOST2: ip link add grelan type gretap local <IP2> remote <IP1>
HOST2: ip link set grelan up
HOST2: iptables -I INPUT -p gre -s <IP1> -j ACCEPT