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

Но кое о чем мы не поговорили. Во второй статье я вскользь упомянул самую передовую и недетектируемую технологию обхода блокировок под названием XTLS-Reality, и пришло время рассказать о ней поподробнее, а именно - как настроить клиент и сервер для нее.

Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XTLS-Reality гораздо проще, чем описанные ранее варианты - после предыдущих статей я получил довольно много комментариев типа "А что так сложно, нужен домен, нужны сертификаты, и куча всего" - теперь все будет гораздо проще.

В предыдущей статье “Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria и все-все-все” я рассказывал про прокси-протоколы. Теперь настало время рассказать про клиенты: консольные, GUI для десктопа и для мобильных платформ. 

Надеюсь, что эта статья вам окажется полезной, потому что, как выяснилось, найти хороший клиент даже для тех же V2Ray/XRay в наше время не так-то просто. Потому что большая часть того, что находится при поиске в интернете “в лоб” и даже в списках типа Awesome V2Ray - или уже неподдерживаемое, или довольно кривое, или не умеющее в актуальные версии и фичи (например, XTLS и uTLS), а самые жемчужины прячутся где-нибудь в глубинах Github’а и сторов.

Предыдущие статьи серии:

Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria и все-все-все
Программы-клиенты для протоколов недетектируемого обхода блокировок сайтов: V2Ray/XRay, Clash, Sing-Box, и другие

С протоколами разобрались, с клиентами разобрались, теперь наконец-то настало время рассказать о том, как же настроить свой личный прокси-сервер с современными протоколами для обхода блокировок. Мы будем настраивать сервер на базе XRay (который является форком известного V2Ray, и еще я немного упомяну Sing-Box) с протоколами Shadowsocks-2022 и VLESS с транспортом XTLS-Vision и фейковым веб-сайтом для защиты от выявления. И в качестве запасного варианта на том же сервере мы настроим fallback на VLESS+Websockets, чтобы была возможность работать через CDN типа Cloudflare, если вдруг IP-адрес вашего сервера попадет под блокировку. В конце я приведу настройки десктопных и мобильных клиентов для подключения ко всему этому.

В последнее время нам почти каждый день рассказывают в новостях, какие очередные вершины покорили языковые нейросетки, и почему они уже через месяц совершенно точно оставят лично вас без работы. При этом мало кто понимает — а как вообще нейросети вроде ChatGPT работают внутри? Так вот, устраивайтесь поудобнее: в этой статье мы наконец объясним всё так, чтобы понял даже шестилетний гуманитарий!

Подробный рассказ о том, как я свой дом и сад сделал умными. С фото, техническими деталями, стоимостями и выводами на будущее.

В прошлый статье остановились на том что, мы собрали MikroTik в единую сеть, обойдя NAT с помощью "облачного" сервера. Далее, в данной статье, мы настроим связность между нашими площадками, да так чтобы казалось, как будто мы их подключили прямым кабелем (L2). Мы должны получить L2VPN.

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

Про текстовые игры написано довольно много как на Хабре, так и на просторах интернета. Это один из самых первых жанров интерактивных развлечений с использованием ЭВМ и даже без него (просьба поделиться опытом НЕэлектронных текстовых игр в комментариях).

В данной статье я хочу мимолетом задеть вопрос истории и нынешней "полужизни" жанра текстовых игр, пофантазировать на тему будущего данного жанра, привести примеры текстовых игр, которые сейчас пользуются популярностью и подсказать об абсолютно новом переосмыслении старого инструмента для создания текстовых игр, о котором вы 99% не знаете. И все, конечно, исключительно на базе личного опыта.

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

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

Вступительное слово

Traefik — это обратный прокси-сервер с открытым исходным кодом, обеспечивающий простую работу с микросервисами и/или просто контейнерами с вашими приложениями.

Обратный прокси-сервер (reverse proxy, реверс-прокси) служит для ретрансляции запросов из внешней сети к каким-либо серверам/сервисам внутренней сети (например веб-сервера, БД или файловые хранилища) и позволяет:

• обеспечить сокрытие структуры внутренней сети и подробностей о находящейся в ней сервисах;
• осуществлять балансировку нагрузки (load balancing) между экземплярами одного и того же сервиса или серверами с одинаковыми задачами;
• обеспечить зашифрованное (HTTPS) соединение между клиентом и любым сервисом, в таком случае SSL сессия создается между клиентом и прокси, а между прокси и сервисом во внутренней сети устанавливается незашифрованное HTTP соединение, если сервис поддерживает HTTPS то можно организовать зашифрованное соединение и во внутренней сети;
• организовать контроль доступа к сервисам (аутентификацию клиента), а также установить файрвол (брандмауэр).

В статье будет описываться использование Traefik в Docker в качестве реверс-прокси для других контейнеров Docker, а также не контейнеризированных сервисов.