Savely Krasovsky's blog

Конфиг для выборочного обхода блокировок на базе sing-box

savely@krasovs.ky (Savely Krasovsky) — Mon, 05 Aug 2024 14:49:27 +0200

Заметил, что большинство людей использует L2/L3 TAP/TUN-решения, которые в подавляющем количестве случаев являются перебором. Они часто вызывают проблемы с корпоративными VPN и заставляют постоянно переподключаться, потому что как правило роутят весь трафик через туннель. Обычно для обхода блокировок достаточно обыкновенных SOCKS/HTTP-прокси. Их умеют использовать браузеры и большинство популярных приложений и они обычно не конфликтуют с другими VPN-приложениями, например корпоративными.

Поэтому решил набросать достаточно простой конфиг для популярного прокси-движка sing-box.

Подразумевается, что:

У вас уже есть настроенный сервер, например, с установленным Outline или голым Shadowsocks.
Вы установили sing-box с официального сайта, GitHub или магазина приложений.
Вы можете работать с консолью и в состоянии запустить команду вида sing-box run -c config.json.

Особенности конфига

По умолчанию DNS-запросы уходят на ваш системный DNS-ресолвер, если не определено обратное.

Это достигается за счёт параметров "sniff": true (позволяет сниффить SNI из запросов к прокси) и "domain_strategy": "prefer_ipv4" (позволяет ресолвить IP заранее, через правила, определенные в конфигурации, иначе ресолвинг будет происходить на удаленном сервере).

Если для подключения к прокси-серверу, вы используете домен, то добавьте для него отдельное правило, отправляющее DNS-запрос на системный ресолвер:
```
{
 "domain": "your.server.example.com",
 "server": "local-dns"
}
```
В качестве основного входящего транспорта данный конфиг использует mixed. Это SOCKS/HTTP прокси, который автоматически проставляется в настройки ОС при запуске sing-box. Это поведение можно переопределить, но тогда браузер и другие приложения придется настраивать на работу с прокси вручную, что зачастую может быть полезно.

Этот вход может быть заменён на любой другой, например, на TUN (полезно для работы на мобильных устройствах):
```
{
 "type": "tun",
 "inet4_address": "172.16.0.1/30",
 "auto_route": true,
 "strict_route": true,
 "sniff": true,
 "domain_strategy": "prefer_ipv4"
}
```

В качестве исходящих транспортов этот конфиг использует direct (прямое интернет-соединение) и shadowsocks.

Порядок важен: если правилами не определено обратное, то sing-box пойдет по транспортам сверху вниз, то есть в нашем случае сначала он пойдет напрямую в интернет и лишь затем через Shadowsocks.

Shadowsocks можно заменить на что угодно. Например, на XTLS-Reality:

{
 "type": "vless",
 "tag": "vless-out",
 "server": "your.server.example.com",
 "server_port": 443,
 "uuid": "REDACTED",
 "flow": "xtls-rprx-vision",
 "tls": {
 "enabled": true,
 "server_name": "ya.ru",
 "utls": {
 "enabled": true
 },
 "reality": {
 "enabled": true,
 "public_key": "REDACTED",
 "short_id": "REDACTED"
 }
 }
}

Или WireGuard:

{
 "type": "wireguard",
 "tag": "wireguard-out",
 "server": "REDACTED",
 "server_port": 51820,
 "system_interface": true,
 "local_address": [
 "10.252.0.1/32",
 "2600:xxxx:xxxx:cafe::1/128"
 ],
 "private_key": "REDACTED",
 "peer_public_key": "REDACTED",
 "pre_shared_key": "REDACTED"
}

Наконец блок с правилами. На базе правил проекта Antizapret я создал небольшую утилиту, которая генерирует sing-box-совместимые списки в формате .srs и выкладывает новые версии раз в сутки.

С помощью этого rule_set можно добавить два правила: одно в DNS, другое в роутинг. Первое позволяет ресолвить через шифрованный DNS только заблокированные домены. Второе позволяет роутить через Shadowsocks (или другой транспорт) только заблокированные домены и IP.

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

Таким образом, в большинстве случаев вам совершенно не придется включать-выключать то, что мы называем VPN.

Полный конфиг

{
 "log": {
 "level": "info",
 "timestamp": true
 },
 "dns": {
 "servers": [
 {
 "tag": "local-dns",
 "address": "local",
 "detour": "direct-out"
 },
 {
 "tag": "cloudflare-dns",
 "address": "https://1.1.1.1/dns-query",
 "address_resolver": "local-dns",
 "detour": "shadowsocks-out"
 }
 ],
 "rules": [
 {
 "domain": "your.server.example.com",
 "server": "local-dns"
 },
 {
 "rule_set": "antizapret",
 "server": "cloudflare-dns"
 }
 ]
 },
 "inbounds": [
 {
 "type": "mixed",
 "tag": "mixed-in",
 "listen": "127.0.0.1",
 "listen_port": 1080,
 "set_system_proxy": true,
 "sniff": true,
 "domain_strategy": "prefer_ipv4"
 }
 ],
 "outbounds": [
 {
 "type": "direct",
 "tag": "direct-out"
 },
 {
 "type": "shadowsocks",
 "tag": "shadowsocks-out",
 "server": "your.server.example.com",
 "server_port": 8443,
 "method": "YOUR-METHOD",
 "password": "YOUR-PASSWORD"
 },
 {
 "type": "dns",
 "tag": "dns-out"
 }
 ],
 "route": {
 "rules": [
 {
 "rule_set": "antizapret",
 "outbound": "shadowsocks-out"
 },
 {
 "protocol": "dns",
 "outbound": "dns-out"
 }
 ],
 "rule_set": [
 {
 "tag": "antizapret",
 "type": "remote",
 "format": "binary",
 "url": "https://github.com/savely-krasovsky/antizapret-sing-box/releases/latest/download/antizapret.srs",
 "download_detour": "shadowsocks-out"
 }
 ],
 "auto_detect_interface": true
 },
 "experimental": {
 "cache_file": {
 "enabled": true
 }
 }
}

Пример конфига VLESS + Reality + сервера Youtube

Полный конфиг

{
 "log": {
 "level": "info",
 "timestamp": true
 },
 "dns": {
 "servers": [
 {
 "tag": "local-dns",
 "address": "local",
 "detour": "direct-out"
 },
 {
 "tag": "cloudflare-dns",
 "address": "https://1.1.1.1/dns-query",
 "address_resolver": "local-dns",
 "detour": "vless-out"
 }
 ],
 "rules": [
 {
 "domain": "your.server.example.com",
 "server": "local-dns"
 },
 {
 "rule_set": "antizapret",
 "server": "cloudflare-dns"
 }
 ]
 },
 "inbounds": [
 {
 "type": "tun",
 "inet4_address": "172.16.0.1/30",
 "auto_route": true,
 "strict_route": true,
 "sniff": true,
 "domain_strategy": "prefer_ipv4"
 }
 ],
 "outbounds": [
 {
 "type": "direct",
 "tag": "direct-out"
 },
 {
 "type": "vless",
 "tag": "vless-out",
 "server": "your.server.example.com",
 "server_port": 443,
 "uuid": "YOUR_UUID",
 "flow": "xtls-rprx-vision",
 "tls": {
 "enabled": true,
 "server_name": "ya.ru",
 "utls": {
 "enabled": true
 },
 "reality": {
 "enabled": true,
 "public_key": "YOUR_PUBLIC_KEY",
 "short_id": "YOUR_SHORT_ID"
 }
 }
 },
 {
 "type": "dns",
 "tag": "dns-out"
 }
 ],
 "route": {
 "rules": [
 {
 "rule_set": "antizapret",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".youtube.com",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".googlevideo.com",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".nhacmp3youtube.com",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".1e100.net",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".ytimg.com",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".youtu.be",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".google.com",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".gvt1.com",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".googleusercontent.com",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".googleapis.com",
 "outbound": "vless-out"
 },
 {
 "domain_suffix": ".gstatic.com",
 "outbound": "vless-out"
 },
 {
 "protocol": "dns",
 "outbound": "dns-out"
 }
 ],
 "rule_set": [
 {
 "type": "remote",
 "tag": "antizapret",
 "format": "binary",
 "url": "https://github.com/savely-krasovsky/antizapret-sing-box/releases/latest/download/antizapret.srs",
 "download_detour": "vless-out"
 }
 ],
 "auto_detect_interface": true
 },
 "experimental": {
 "cache_file": {
 "enabled": true
 }
 }
}

Simple Waybar module that checks Arch Linux system updates

savely@krasovs.ky (Savely Krasovsky) — Sun, 07 May 2023 11:45:20 +0300

I’ve released simple but yet effective module for the Waybar that checks Arch Linux system updates. There are some features that I think you would like.

Features

Sends notifications about updates.
Supports GNU gettext localization (contribute new po-files!)
Checks updates from AUR using Aurweb RPC, so works independently.
Shows updates in the tooltip.
Supports two states: pending-updates and updated to use different icons or hide module.
Uses infinite loop to supply Waybar JSON updates.
Configurable interval between checks.

You can easily install it from AUR: yay -S waybar-updates

I use it with this config:

"custom/pacman": {
 "format": "{icon}{}",
 "return-type": "json",
 "format-icons": {
 "pending-updates": " ",
 "updated": ""
 },
 "exec-if": "which waybar-updates",
 "exec": "waybar-updates"
}

In that case you will also need Nerd fonts (I personally use ttf-jetbrains-mono-nerd).

I’ve also added lite blinking effect to it:

@keyframes blink-update {
 to {
 background-color: dodgerblue;
 }
}

#custom-pacman {
 animation-timing-function: linear;
 animation-iteration-count: infinite;
 animation-direction: alternate;
}
#custom-pacman.pending-updates {
 animation-name: blink-update;
 animation-duration: 3s;
}

Screenshots

There should have been a video here but your browser does not seem to support it.

If you like it, please consider to give it a star!

Flipper Zero: writing and debugging in CLion

savely@krasovs.ky (Savely Krasovsky) — Tue, 01 Nov 2022 00:00:00 +0000

A while ago I got my own Flipper Zero and immediately tried to write own simple application. Unfortunately they officially support only one editor — VS Code.

I like JetBrains products and use them every day: from GoLand and PhpStorm to Rider and PyCharm. So why would I don’t use CLion to write and debug Flipper Zero’s apps?

CLion is a cross-platform IDE for C and C++ from JetBrains. And while it does support some features for embedded development, there are still some caveats, especially with debugging.

Setup core functionality

CLion syntax highlighting and autocomplete engine works out of the box only with CMake, but it supports compilation database, which fbt can generate. So to start:

Clone Flipper Zero firmware repo:

git clone --recursive https://github.com/flipperdevices/flipperzero-firmware.git

Build firmware, FAPs and create compile database:
```
./fbt
./fbt faps
./fbt firmware_cdb
```
Copy compile_commands.json from build/latest to the project root.
Open this file with CLion.
Go and find compile_commands.json file at build/latest again, then click right mouse button and choose Load Compilation Database Project.
Remove compile_commands.json from the project root.
Go to File -> Settings -> Build, Execution, Deployment -> Toolchains and create toolkit:
- C Compiler: toolchain/x86_64-linux/bin/arm-none-eabi-gcc
- С++ Compiler: toolchain/x86_64-linux/bin/arm-none-eabi-g++
- Debugger: toolchain/x86_64-linux/bin/arm-none-eabi-gdb-py
It should try to sync a project at Build tab successfully.

Possible problems and their solutions

CLion does not understand ccache.

Solution 1: remove ccache from system and regenerate compilation database.

Solution 2: just remove it from file:
```
cd built/target
sed -i 's/ccache\ //g' compile_commands.json
```

CLion cannot find stdlib.

Solution 1: Launch CLion under fbt environment:

source scripts/toolchain/fbtenv.sh
gtk-launch jetbrains-clion.desktop

Solution 2: Replace path to compiler with absolute ones:

cd built/target
sed -i 's/arm-none-eabi-gcc/\/home\/user\/documents\/flipperzero-firmware\/toolchain\/x86_64-linux\/bin\/arm-none-eabi-gсс/g' compile_commands.json

Solution 3: Install the latest arm-none-eabi toolkit with your system package manager:

sudo pacman -S arm-none-eabi-gcc arm-none-eabi-gdb arm-none-eabi-newlib

After this troubleshooting CLion should work as expected: highlighting and autocompleting your code.

Setup debugging

Go to Run Configuration and create your own with type Remote Debug:
- Pick debugger from toolchain you created before.
- Fill 'target remote' args with content from output of ./fbt get_blackmagic
- Point to symbol file: build/latest/firmware.elf

Create a .gdbinit file with this content in the project directory:

set confirm off
set trace-commands on
define target remote
target extended-remote $arg0
set mem inaccessible-by-default off
source debug/flipperapps.py
fap-set-debug-elf-root build/latest/.extapps
end

Then create a .gdbinit file in your home directory:
```
set auto-load safe-path /path/to/your/project
```

Before first debug session you have to attach Flipper Zero:

toolchain/x86_64-linux/bin/arm-none-eabi-gdb-py -q -ex "target remote `./fbt get_blackmagic`" -ex "monitor swdp_scan" -ex "attach 1" -ex "quit" build/latest/firmware.elf

Now you can set breakpoints and try to debug using the configuration you create. Ensure that your debugger connects successfully, otherwise try to reboot Flipper and start again from step 4.
(Optionally) After successful session of debug you can edit your debug configuration and add in “Before launch” block “External tool” to automate step 4.

UPD: 10 november 2022

Guide has been updated after patches from Flipper Devices team! Now it should work with fewer tricks.

UPD: 25 april 2023

Roman Beltiukov has pointed out in the comments about fap-set-debug-elf-root build/latest/.extapps needed to be added to the project’s .gdbinit to debug fapps.

Telegram Web App bot: разбор и аспекты безопасности

savely@krasovs.ky (Savely Krasovsky) — Tue, 14 Jun 2022 15:01:43 +0300

С релизом нового обновления Telegram у многих возникли вопросы как правильно наладить общение бот <-> Telegram, бот <-> бэкенд и сделать это безопасно. Для начала давайте проясним какие способы активации Telegram решил предоставить пользователю:

Через кнопку меню, которую можно настроить у @BotFather.
Через inline-кнопку.
Через keyboard-кнопку.
Через меню вложений.

Кнопка меню, inline-кнопка

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

{
 "query_id": "str",
 "user": {
 "id": 1,
 "is_bot": false,
 "first_name": "Pavel",
 "last_name": "Durov",
 "username": "durov",
 "language_code": "ru",
 "photo_url": "https://telegram.org/durov.jpg"
 },
 "auth_date": 1655210062,
 "hash": "7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069"
}

Проблема в том, что официальная документация хоть и предупреждает, но не особо объясняет зачем валидировать поле initData на сервере бота.

TL;DR

Без валидации:

Мэллори: Привет Боб, я Алиса, дай мне информацию о балансе и сделай перевод на имя Мэллори.

Боб: Пожалуйста, Алиса, всё готово.

С валидацией:

Мэллори: Привет Боб, я Алиса, дай мне информацию о балансе и сделай перевод на имя Мэллори.

Боб: Предоставьте, пожалуйста, валидную подпись Алисы.

Мэллори разводит руками

То есть нужно это затем, чтобы произвести безопасную аутентификацию (проверку подлинности запроса) и авторизацию (понять, что к боту пришла именно Алиса, а не Мэллори).

Без этой валидации бот сможет предоставлять критически важную информацию (например, вы делаете онлайн-банкинг в боте) просто по ID пользователя Telegram.

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

Валидация, к слову, не совсем тривиальная. Разработчики Telegram, как обычно, не поленились и вместо проверенного стандарта JSON Web Token (JWT), реализовали свой собственный велосипед, да ещё и на базе обычного HMAC-SHA256 (то есть HS256 будь у нас JWT-токен). В результате initData представляет собой URL-encoded строку query-параметров. Для корректной валидации которой требуется следующая цепочка шагов:

Декодируем строку, используя URL-encoding (важно, иначе значение с ключом user останется не декодированным).
Полученные пары ключ-значения сортируем в алфавитном порядке.
Исключаем ключ hash
Из полученных пар составляем тело вида: auth_date=<auth_date>\nquery_id=<query_id>\nuser=<user>. Важно сохранить значение с ключом user в чистом JSON.
Берем хэш от токена вашего бота с помощью алгоритма HMAC-SHA256 с ключом WebAppData.
Берем хэш от полученного в шаге 4 тела с помощью того же алгоритма, а в качестве ключа используем хэш, полученный ранее в виде последовательности байтов (а не hex-репрезентации!).
Преобразуем полученный хэш в hex-строку и сравниваем со значением ключа hash.

По аналогии с JWT, если валидация прошла успешно, пользователя можно считать аутентифицированным и переходить к авторизации с помощью предоставленного payload (в нашем случае это id в объекте user).

Говоря о query_id, который мы получаем в initData. Используя это поле, мы можем создать в чате сообщение с ботом от имени пользователя с бейджем via @your_bot. Для этого потребуется вызвать метод answerWebAppQuery.

+ может использоваться для приложений любой сложности
+ initData по факту является полноценным stateless-токеном по типу JWT
+ позволяет создавать сообщения от имени пользователя в чате с ботом с бейджем via @your_bot

- требуется собственный бэкенд для веб-части для валидации initData и работы с пользователем

Keyboard-кнопка

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

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

Однако при использовании этого способа появляется возможность использовать метод Telegram.WebApp.sendData(), который позволяет отправить сообщение боту напрямую, а тот предоставит его вам через long-polling или вебхуки. Стоит учесть, что после успешного выполнения веб-окно автоматически закроется, а бот отрапортует сервисным сообщением Вы успешно передали данные боту кнопкой «Test button».

Поэтому Telegram позиционирует этот способ как удобный способ сделать гибкую веб-форму ввода с полями типа date picker. Вернуть значения формы можно с помощью метода Telegram.WebApp.sendData().

Нужно понимать, что в JS-файле этот метод является лишь прослойкой, само значение, переданное в sendData() отправляются далее через MTProto-метод sendWebAppData. Методы MTProto невозможно использовать без авторизации в Telegram, поэтому тут мессенджер берет безопасность полностью на себя.

В этом заключается плюс этого метода.

+ удобно для заполнения сравнительно простых форм ввода
+ наличие собственного бэкенда для Web-части не требуется

- initData не приходит, возможность авторизовать пользователя на своём бэкенде (даже если он есть) отсутствует
- отправить информацию боту можно только 1 раз

Кнопка в меню вложений

Есть также четвертый способ, который технически не отличается от первого и второго (только дополнительными полями в initData), но в этом случае бот добавляется в меню вложений.

К сожалению эта возможность пока что доступна только для тех, кто участвует в рекламной платформе Telegram и, следовательно, внёс залог 2 миллиона евро. Поэтому пока что говорить тут особо не о чем. Из известных мне публичных ботов такую интеграцию использует @wallet.

Основной плюс — возможность использовать бота не только в личной переписке с ботом. Например, вышеупомянутый @wallet позволяет отправить любому собеседнику сообщение с информацией о переводе, собеседнику остается лишь нажать и получить свой перевод.

+ плюсы первых двух способов
+ возможность использовать бота в переписке с человеком
+ новый интуитивный механизм использования ботов Telegram

- минусы первых двух способов
- необходимо стать крупным рекламодателем на площадке Telegram

Ещё более изощренный обход блокировок с помощью Shadowsocks + V2Ray + Cloudflare

savely@krasovs.ky (Savely Krasovsky) — Sat, 19 Mar 2022 00:00:00 +0000

В прошлой статье я разобрал вариант с Cloak, однако меня не устроила умеренная сложность конфигурации клиентской части, а также меньшая популярность и, следовательно, развитие проекта по сравнению с V2Ray.

Использование Cloudflare в описанном ниже способе позволило повысить пропускную способность канала. На Нидерландском сервере я получил в районе 450 мегабит через Cloudflare, вместо 250-300 напрямую с Cloak.

План

Весь трафик завернуть на Cloudflare, который отправит его к нам на VPS. Сдобрить обфускацией от V2Ray и сам сервер спрятать под видом совершенно безобидного ресурса.


На практике это будет выглядеть как-то так

Ингредиенты

VPS в Европе.
Домен в любой зоне (желательно не .ru/.su/.рф)
Аккаунт на Cloudflare.
shadowsocks-rust.
v2ray-plugin (лучше использовать форк, там свежий v2ray-core).
HTTP-сервер, nginx в нашем случае.
SSL-сертификат полученный от Let’s Encrypt или непосредственно Cloudflare.

Рецепт

Ставим в систему shadowsocks-rust и v2ray-plugin, сконфигурировать их легко вот таким конфигом в /etc/shadowsocks-rust/v2ray.json:

{
 "server": "localhost",
 "server_port": 8443,
 "method": "chacha20-ietf-poly1305",
 "password": "yourpass",
 "plugin": "v2ray-plugin",
 "plugin_opts": "server"
}

Создаём для Shadowsocks systemd-сервис по аналогии с прошлой статьёй (пункты 5-7).
Получаем сертификат через certbot или через Cloudflare. Детально расписывать не буду, инструкций в интернете масса.
Ставим nginx, заводим следующий конфиг в /etc/nginx/sites-available/v2ray:

server {
listen 80;
server_name _;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name yourdomain.wtf;
ssl_certificate /etc/letsencrypt/live/yourdomain.wtf/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.wtf/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/yourdomain.wtf/chain.pem;
# Здесь можно проксировать запросы на какой-нибудь весёлый сайт
location / {
proxy_pass https://innocent.domain.lol;
}
# Локацию можно сделать длинной, чтобы её никто не смог угадать.
location /v2ray {
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_http_version 1.1;
proxy_buffering off;
proxy_redirect off;
proxy_pass http://localhost:8443/;
}
}

Не забудьте сделать symlink и перезагрузить nginx:

# ln -s /etc/nginx/sites-available/v2ray /etc/nginx/sites-enabled/v2ray
# systemctl reload nginx

Заходим в Cloudflare в раздел DNS, создаём A-запись, указывающую на ваш сервер, оставляем Proxy включенным.
В разделе SSL/TLS включаем режим Full (strict), минимальную версию TLS можно повысить до 1.2/1.3 в зависимости от поддержки актуальных протоколов вашими устройствами.
Наконец настроим клиент:

{
 "server": "yourdomain.wtf",
 "server_port": 443,
 "method": "chacha20-ietf-poly1305",
 "password": "yourpass",
 "plugin": "v2ray-plugin",
 "plugin_opts": "tls;host=yourdomain.wtf;path=/v2ray",
 "local_address": "localhost",
 "local_port": 1080
}

Обход блокировок с помощью Shadowsocks + Cloak

savely@krasovs.ky (Savely Krasovsky) — Tue, 08 Mar 2022 00:00:00 +0000

В свете последних событий и угрозы наступления пресловутого Чебурнета нам видимо придётся прибегнуть к китайскому опыту обхода блокировок. На мой взгляд связка Shadowsocks + Cloak позволяет довольно элегантно замаскировать весь трафик под обычные HTTPS-соединения к ресурсу, который не заблокирован в стране (например Яндекс).

Используя Raspberry Pi 4B, заказанную у известного хостера, я получил около 450 мегабит на загрузку и 550 на отдачу. Эта скорость вероятно ограничена производительностью непосредственно Raspberry, с нормальным x86-сервером результаты должны быть даже лучше.

Собственно инструкция

Скачиваем последние версии shadowsocks-rust и Cloak из раздела релизов. Кладём их, например, в /usr/local/bin. Ниже лишь пример, ваш сервер может иметь другую архитектуру.

$ curl -LO https://github.com/shadowsocks/shadowsocks-rust/releases/download/v1.14.1/shadowsocks-v1.14.1.x86_64-unknown-linux-gnu.tar.xz
$ curl -LO https://github.com/cbeuw/Cloak/releases/download/v2.5.5/ck-client-linux-amd64-v2.5.5
$ tar -xvf shadowsocks-v1.14.1.x86_64-unknown-linux-gnu.tar.xz
$ sudo mv ss* /usr/local/bin
$ sudo mv ck-client-linux-amd64-v2.5.5 /usr/local/bin/ck-client

Конфигурируем сервер shadowsocks примерно следующим образом:

# nano /etc/shadowsocks-rust/cloak.json

{
 "server": "localhost",
 "server_port": 8388,
 "method": "chacha20-ietf-poly1305",
 "password": "yourpass",
 "timeout": 7200,
 "nofile": 10240,
 "plugin": "ck-server",
 "plugin_opts": "/etc/shadowsocks-rust/ckserver.json"
}

Генерируем с помощью ck-server UID и пару ключей, записываем их куда-нибудь:

$ ck-server -u
$ ck-server -key

Конфигурируем сервер Cloak примерно следующим образом, используем значения, полученные ранее:

# nano /etc/shadowsocks-rust/ckserver.json

{
 "RedirAddr": "www.yandex.ru",
 "BindAddr": [":443",":80"],
 "ProxyBook": {
 "shadowsocks": [
 "tcp",
 "localhost:8388"
 ]
 },
 "PrivateKey": "privkey_from_previous_step",
 "BypassUID": ["uid_from_previous_step"]
}

В качестве меры безопасности режем права. К сожалению на ckserver.json нельзя накинуть 0600, иначе процесс не сможет прочитать файл, однако основной пароль будет надёжно защищён.

# chmod 0644 /etc/shadowsocks-rust/ckserver.json
# chmod 0600 /etc/shadowsocks-rust/cloak.json

Создаём безопасный systemd-сервис для Shadowsocks (Cloak будет запускаться сам, как плагин):

# nano /etc/systemd/system/shadowsocks-rust-server@.service

[Unit]
Description=Shadowsocks-Rust Server Service
After=network.target
Wants=network-online.target

[Service]
Type=simple
DynamicUser=yes
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
LoadCredential=%i.json:/etc/shadowsocks-rust/%i.json
ExecStart=/usr/local/bin/ssservice server --log-without-time -c ${CREDENTIALS_DIRECTORY}/%i.json

[Install]
WantedBy=multi-user.target

Включаем и запускаем сервис shadowsocks:

# systemctl daemon-reload
# systemctl enable shadowsocks-rust-server@cloak.service
# systemctl start shadowsocks-rust-server@cloak.service

Наконец конфигурируем клиент Cloak на хосте (им может быть ПК, Мак, смартфон):

{
 "server": "yourdomain.wtf",
 "server_port": 443,
 "method": "chacha20-ietf-poly1305",
 "password": "yourpass",
 "plugin": "ck-client",
 "plugin_opts": "UID=uid_from_previous_step;ProxyMethod=shadowsocks;PublicKey=pubkey_from_previous_step;EncryptionMethod=plain;ServerName=www.yandex.ru;AlternativeNames=mail.ru,vk.com",
 "local_address": "localhost",
 "local_port": 1080
}

Дополнительные советы

Firewall

Если есть файрволл, то необходимо открыть на нём два порта: 80 и 443.

Удобный URI для передачи настроек

Также для удобства можно сделать URI, который позволяет передавать быстро всю конфигурацию в виде одной строчки:

ss:// + base64encode("chacha20-ietf-poly1305:yourpass") + @yourdomain.org:443?plugin= + urlencode("ck-client;UID=uid_from_previous_step;ProxyMethod=shadowsocks;PublicKey=pubkey_from_previous_step;EncryptionMethod=plain;ServerName=www.yandex.ru;AlternativeNames=mail.ru,vk.com")

Другими словами финальный URI будет выглядеть так:

ss://Y2hhY2hhMjAtaWV0Zi1wb2x5MTMwNTp5b3VycGFzcw@yourdomain.org:443?plugin=ck-client%3BUID%3Duid_from_previous_step%3BProxyMethod%3Dshadowsocks%3BPublicKey%3Dpubkey_from_previous_step%3BEncryptionMethod%3Dplain%3BServerName%3Dwww.yandex.ru%3BAlternativeNames%3Dmail.ru%2Cvk.com

Этот URI поддерживается многими приложениями, включая Shadowrocket на iOS. Покупайте, кстати, пока ещё можно.

Хостинг настроек

Сообществом был принят стандарт SIP008, который позволяет автоматически скачивать настройки с помощью JSON-файла, размещённого на веб-сервере. Структура файла выглядит примерно так:

{
 "version": 1,
 "servers": [
 {
 "id": "27b8a625-4f4b-4428-9f0f-8a2317db7c79",
 "remarks": "Name of the server",
 "server": "yourdomain.wtf",
 "server_port": 443,
 "method": "chacha20-ietf-poly1305",
 "password": "yourpass",
 "plugin": "ck-client",
 "plugin_opts": "UID=uid_from_previous_step;ProxyMethod=shadowsocks;PublicKey=pubkey_from_previous_step;EncryptionMethod=plain;ServerName=www.yandex.ru;AlternativeNames=mail.ru,vk.com"
 }
 ]
}

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

Wireguard's AllowedIPs calculator

savely@krasovs.ky (Savely Krasovsky) — Sun, 04 Jul 2021 00:00:00 +0000

As you possibly know Wireguard hasn’t something like “DisallowedIPs” parameter to exclude some networks from allowed ones. Of course technically AllowedIPs is enough, but I am tired to calculate it by hand, so created this simple calculator:

Update: I am using small Golang HTTP-server to quickly calculate results and at first I tried ipaddr due to its similarity to the Python ipaddress. But it has a little problem, in my case it caused an infinite loop that led to DoS and finally to panic. Better use the brilliant netaddr developed by Brad Fitzpatrick and the Tailscale team (their blogpost with motivation)

Update 2: I realized that this is a great case to use WASM!

Update 3: For some reason I didn’t publish source code right after this blog post was written. In 2023, I thought I lost it forever, but randomly found it in my backup files. WASM sources here. HTTP API mini server sources are probably still lost :(

Simple Certificate Authority: how-to

savely@krasovs.ky (Savely Krasovsky) — Tue, 11 May 2021 00:00:00 +0000

This post is just an example of how to create a simple CA and issue a TLS certificate. I will deliberately not give any explanations, because the Internet has been full of them for a long time.

It also frustrates me that people like to just copy and paste configurations and don’t realize that tons of parameters are just not needed for their needs. In my case I tried to keep it as simple as possible.

So create three files:

ca.cnf:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
# You can remove this if you don't use non-ASCII symbols
utf8 = yes

[req_distinguished_name]
C = RU
CN = "Savely Krasovsky's CA"

[v3_req]
keyUsage = digitalSignature

tls.cnf:

[req]
distinguished_name = req_distinguished_name
prompt = no
utf8 = yes

[req_distinguished_name]
C = RU
CN = "Savely Krasovsky's LAN"

tls.ext:

keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = home.local
DNS.2 = *.home.local

Now execute this:

# Generate CA cert
openssl ecparam -name prime256v1 -genkey -out ca.key
openssl req -new -key ca.key -config ca.cnf -out ca.csr
openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt

# Generate TLS cert
openssl ecparam -name prime256v1 -genkey -out tls.key
openssl req -new -key tls.key -config tls.cnf -out tls.csr
openssl x509 -req -in tls.csr -CA ca.crt -CAkey ca.key -out tls.crt -days 365 -extfile tls.ext

Of course, you can create not only TLS certs, this is just the simplest case. Play with the tls.ext (especially keyUsage and extendedKeyUsage parameters) file to issue another certificate.

For example this is mTLS compatible client cert:

personal.cnf:

[req]
distinguished_name = req_distinguished_name
prompt = no
utf8 = yes

[req_distinguished_name]
C = RU
CN = "Savely Krasovsky's LAN"

personal.ext:

keyUsage = critical,digitalSignature
extendedKeyUsage = clientAuth
subjectKeyIdentifier = hash

Generation:

openssl ecparam -name prime256v1 -genkey -out personal.key
openssl req -new -key personal.key -config personal.cnf -out personal.csr
openssl x509 -req -in personal.csr -CA ca.crt -CAkey ca.key -out personal.crt -days 365 -extfile personal.ext
# Convert to convenient PKCS#12 certificate there key and cert itself are combined
openssl pkcs12 -export -out personal.pfx -inkey personal.key -in personal.crt

Checkpoint SNX adventure: isolating the proprietary in it own box

savely@krasovs.ky (Savely Krasovsky) — Mon, 26 Apr 2021 00:00:00 +0000

My company uses Checkpoint products as a VPN solution. In case of Windows and macOS there is Checkpoint Endpoint Security. In case of Linux we have to use whatever called Checkpoint SSL Network Extender or just Checkpoint SNX.

As far as I got, it encapsulates traffic into HTTPS connection between you and VPN gateway and provides TUN interface. Sounds okay on paper, right?

But as you know, proprietary software has something in common: the quality of Linux support generally sucks. Checkpoint SNX is not an exception.

Just read their support page. The distros they consider relevant in 2021: Ubuntu 17.04, Fedora 18, openSUSE 12.2. Okay, cool.

The shitty quality of Linux solution itself wasn’t the main reason to isolate it. Gateways like this are pushing settings from the server including routes, usually there is no way to somehow reconfigure this.

In my case, the company decided that split tunneling isn’t secure. It means while I am connected and trying to reach corporate resources, I cannot reach the Internet without corporate proxy and vice versa.

So I had an idea: it would be nice to just share Checkpoint VPN connection with other computers.

Particularly I wanted to:

Completely isolate Checkpoint SNX inside Linux VM.
Use WireGuard tunnels to share VPN connection.
At client-side use only one simple route: 10.0.0.0/8.

Why WireGuard? I could just use IP forwarding and NAT tweaks, but it would only work within a particular LAN and I would have to create and delete route and change DNS servers every time manually.

Let’s get started.

Install Checkpoint SNX

You can download SNX installer from your company’s VPN portal:

$ curl https://example.org/SNX/INSTALL/snx_install.sh -o snx_install.sh
# OR
$ curl https://example.org/sslvpn/SNX/INSTALL/snx_install.sh -o snx_install.sh

There is also a way to install the latest version from Checkpoint site, but I don’t recommend it, your company could use different version.

While the first part of script is just a bash script, the second part contains an archive with the binaries. The binaries are x86 (not x86-64), so you need to enable multiarch and install dependencies.

# ldd /usr/bin/snx
...
libX11.so.6 => /usr/lib32/libX11.so.6
libpam.so.0 => /usr/lib32/libpam.so.0 (0xf7d3d000)
libstdc++.so.5 => /usr/lib32/libstdc++.so.5 (0xf7c5c000)
...

So you need to install three libraries: libX11, libpam, libstdc++. In various distros you need to use various names, but you can easily google it.

Finally, just install it:

$ chmod +x snx_install.sh
$ sudo ./snx_install.sh

Back to your browser and try to connect using the portal. A while back you needed a browser that supports NPAPI to launch Java-applet, but currently it seems like Checkpoint SNX uses the new mechanism. That’s why most probably a webpage will ask you to install whatever called cshell, but not csh, you will have to download another script cshell_install.sh.

Important

Before installation install OpenJRE, in my case only the latest 15.0 worked well.

$ chmod +x cshell_install.sh
$ sudo ./cshell_install.sh

In case of any errors probably you have a wrong OpenJRE version. Fortunately you can test it even after failed installation process:

$ java -jar /usr/bin/cshell/CShell.jar

Note

Scrips are idempotent, so you can run them indefinitely until getting a fix

After successful installation of snx and cshell there is another step: this jar-file runs HTTPS-server at localhost:14186, but installer fails to make certificate trusted. There are two ways to fix it:

Add /usr/bin/cshell/cert/CShell_Certificate.crt as trusted (preferred)
Just go to the localhost:14186 in your favourite browser and mark it as trusted.

Now try to reconnect again. Everything should now work.

WireGuard tunnel

I don’t want to tell here how WireGuard works. I will just provide an example of working configs:

Peer A (VM with SNX):

[Interface]
PrivateKey = ... # ABC
ListenPort = 51820
Address = 192.168.128.1/24

# Host PC
[Peer]
PublicKey = ... # XYZ' public key
AllowedIPs = 192.168.128.2/32

# You add here another peers:
#
# Mobile phone
# [Peer]
# PublicKey = DEF
# AllowedIPs = 192.168.128.3/32

Peer B (PC with which I want to share):

[Interface]
PrivateKey = ... # XYZ
Address = 192.168.128.2/32
DNS = DNS1, DNS2 # found out you VPN DNS server and hard code them here

[Peer]
PublicKey = ... # ABC's public key
AllowedIPs = 10.0.0.0/8
Endpoint = 192.168.1.8:51820 # Use an IP of your bridged VM

On both sides enable peers. You can test tunnel simply pinging thought it:

# from device to VM with SNX
$ ping 192.168.128.2

Firewall

Of course without proper firewall setup, an SNX connection won’t share. I will use modern nftables.

/etc/nftables.conf:

#!/usr/bin/nft -f
# ipv4/ipv6 Simple & Safe Firewall
# you can find examples in /usr/share/nftables/

flush ruleset

table inet filter {
 chain input {
 type filter hook input priority 0; policy drop;

 # allow established/related connections
 ct state {established, related} accept

 # early drop of invalid connections
 ct state invalid drop

 # allow from loopback
 iifname lo accept

 # allow icmp
 ip protocol icmp accept
 meta l4proto ipv6-icmp accept

 # allow wireguard
 udp dport 51820 accept

 # everything else
 reject with icmpx type port-unreachable
 }

 chain forward {
 type filter hook forward priority 0; policy drop;

 ct state {established, related} accept
 ct state invalid drop

 # allow forwarding from wireguard interface to snx one
 iifname wg0 oifname tunsnx ct state new accept
 }

 chain output {
 type filter hook output priority 0; policy accept;
 }
}

table inet nat {
 chain postrouting {
 type nat hook postrouting priority srcnat;
 }
}

Note

Don’t forget to enable IP forwarding:

net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1

To share SNX connection you will have to configure SNAT dynamically after connection (and disconnection). I will use systemd oneshot-service to do this.

/etc/systemd/system/snx-firewall.service:

[Unit]
Description=Checkpoint SNX firewall tweaker
BindsTo=sys-subsystem-net-devices-tunsnx.device
After=sys-subsystem-net-devices-tunsnx.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/root/bin/snx_add_rule.sh
ExecStop=/root/bin/snx_flush_chain.sh

[Install]
WantedBy=sys-subsystem-net-devices-tunsnx.device

The mix of BindsTo and RemainsAfterExit allows us to trigger ExecStart and ExecStop at the right time, when connection starts and when connection stops.

As you could see above, service also requires two scripts:

/root/bin/snx_add_rule.sh:

#!/bin/bash

GATEWAY=$(ip -o -4 addr show tunsnx | awk '{printf $4}')
nft add rule inet nat postrouting oifname "tunsnx" ip daddr 10.0.0.0/8 snat ip to $GATEWAY
echo "nftables rule added"

/root/bin/snx_flush_chain.sh:

#!/bin/bash

nft flush chain inet nat postrouting
echo "nftables flushed"

This is where all the magic is going on. Simple masquerading doesn’t help in this case. Reconnect you SNX and try to open corporate resource. Works? Cool!

Feel free to leave comments below the post.

UPDATE: I can also recommend removing default cshell autostart (from ~/.config/autostart/cshell.desktop) because it’s not reliable and setup user systemd service:

[Unit]
Description=Checkpoint SNX CShell
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
Environment=DISPLAY=:0
WorkingDirectory=/usr/bin/cshell
# Should work for JRE 16+
ExecStart=/usr/bin/java --add-exports java.base/sun.net.spi=ALL-UNNAMED -jar CShell.jar /tmp/cshell.fifo
ExecStop=/bin/kill -15 $MAINPID
SuccessExitStatus=143
Restart=on-failure

[Install]
WantedBy=default.target

UPDATE 2: Rui Ribeiro from comments suggested much nicer method using chroot, check it!

Savely Krasovsky's blog

Конфиг для выборочного обхода блокировок на базе sing-box

Подразумевается, что:

Особенности конфига

Полный конфиг

Пример конфига VLESS + Reality + сервера Youtube

Simple Waybar module that checks Arch Linux system updates

Features

Screenshots

Flipper Zero: writing and debugging in CLion

Setup core functionality

Possible problems and their solutions

Setup debugging

Telegram Web App bot: разбор и аспекты безопасности

Кнопка меню, inline-кнопка

Keyboard-кнопка

Кнопка в меню вложений

Ещё более изощренный обход блокировок с помощью Shadowsocks + V2Ray + Cloudflare

План

Ингредиенты

Рецепт

Рекомендации

Обход блокировок с помощью Shadowsocks + Cloak

Собственно инструкция

Дополнительные советы

Firewall

Удобный URI для передачи настроек

Хостинг настроек

Wireguard's AllowedIPs calculator

Simple Certificate Authority: how-to

Checkpoint SNX adventure: isolating the proprietary in it own box

Install Checkpoint SNX

WireGuard tunnel

Firewall