# Radicle: обмеження витоків пірингового трафіку

> Вже не вперше забуваю і повторно задовбую розробників цим питанням. Тому вирішив написати нотатку для себе та інших. Матеріал в процесі тестування, фінальний аудит трафіку ще не проводився.

Radicle, як й інші P2P платформи (за поодинокими виключеннями типу I2PSnark, опцій фільтрації мережі в i2pd чи Alfis DNS) має властивість розсилати та приймати конекти з різних мереж. Через це мене банить провайдер VPN, згідно свого DPI вважаючи, що я качаю торенти.

Отже, в Radicle (щонайменше v1.6.0-61) немає ніяких спеціальних інструментів фільтрації. Навіть якщо ви з'єднаєтесь з єдиним вузлом через Yggdrasil - ваша нода неодмінно отримає від нього "солянку" IPv6 адрес на клірнет (які той, в свою чергу, "нахапав" з інших вузлів) і спробує з'єднатись з ними на етапі `rad sync`.

В торент-клієнтах, така між-пірингова комунікація звичайно відбувається засобами PEX, який достатньо вимкнути (хоча й клієнт/бібліотека librqbit такої опції не має і там рішення полягає в так званих блок-списках Bittorrent). Тут же мені порадили користуватись засобами проксі або обмеженнями systemd.

* зауважу, що я пробував для себе варіант з `node.peers.type` = `static`, але це не вирішує проблему.

## Обмеження засобами проксі

В Radicle є декілька різновидів конфігурації проксі:
=> https://radicle.xyz/guides/user#configuring-radicle-in-mixed-mode

вони вказуються у файлі `~/.radicle/config.json`:

1. `node.proxy` - глобальний застосовується до всього трафіку, тому його можна використовувати у зв'язкці з наприклад privoxy, маршрутизуючи трафік згідно хосту HTTP, або sqiud засобами ACL.
2. `node.onion` - ці правила застосовуються виключно до адрес прихованих сервісів, тому нам не підходять
3. `node.i2p` - поки не реалізований, але рух в цьому напрямку відбувається (утім, дивитись пункт #2)
=> https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/patches/ec8bf7a23c4f1df9f4c548bc07ba234b0ad08c25 Прогрес інтеграції сокетів I2P

Оскільки на сервері вже є налаштована інфраструктура, для себе я використовуватиму такий віддалений варіант, бо він дозволяє не пускати Tor локально і не чекати на ініціалізацію. Для себе, ви можете налаштувати локальний проксі, виключивши з інструкцій дозволи фаєрволу для ::1/127.0.0.1.

### gost

gost (Go Simple Tunnel) - це мінімалістичний але потужний інструмент проксування, який вміє не тільки різні протоколи, але й дозволяє будувати складні маршрути:
=> https://github.com/ginuerzh/gost

У випадку Radicle, який працює лише з SOCKS, потрібно зробити наступне:

``` bash
git clone https://github.com/ginuerzh/gost.git
cd gost/cmd/gost
go build
```
* зробив також локальне дзеркало: `rad:zMyXJ4mwSYQ2ng4CMqEkWrnVc7h2`
* якщо планується запуск з systemd, бінарник `gost/cmd/gost/gost` з правами `chmod +x` копіюється до `/usr/local/share/bin/gost`

Проксі можна запускати використовуючи файл конфігурації:
``` bash
gost -C /path/to/config.json
```
=> https://raw.githubusercontent.com/ginuerzh/gost/refs/heads/master/.config/gost.json стандартний приклад

Але я перевірив роботу на прикладі аргументів командного рядка. Конфігурація аргументів передбачає маршрутизацію на три мережі: Tor, Yggdrasil та Mycelium - останні дві йтимуть за відповідним діапазоном "напряму", через так званий `bypass`:

``` bash
gost -L "socks5://[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]:8119?bypass=0200::/7,0400::/7" \
     -F "socks5://[::1]:9150"
```
* порт 9150 - це роутер Arti, у вас може бути класичний 9050
* можливо, для резольву білих адрес в Tor, доведеться окремо вказати `?dns=xxx:53` (див. `/etc/resolv.conf`)

Для запуску системного сервісу, мною використовується наступний пресет:

``` /etc/systemd/system/gost.service
#/etc/systemd/system/gost.service
[Unit]
Wants=network.target
After=network.target

[Service]
User=gost
Group=gost

Type=simple
ExecStart=/usr/local/bin/gost \
    -L "socks5://[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]:8119?bypass=0200::/7,0400::/7" \
    -F "socks5://[::1]:9150"

StandardOutput=file:///home/gost/debug.log
StandardError=file:///home/gost/error.log

[Install]
WantedBy=multi-user.target
```

Окремо дозволив себе в iptables:

``` bash
ufw allow from xxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx \
            to 202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148 port 8119
```
* `xxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx` - адреса клієнта `radicle-node`

Додавши наступні рядки до `~/.radicle/config.json` і перезавантаживши клієнтський вузол, я можу з'єднуватись з усіма вузлами мереж, доступних на сервері:

``` ~/.radicle/config.json
"node": {
    "proxy": "http://[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]:8119"
}
```

## Обмеження засобами systemd

=> https://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html IP Accounting and Access Lists with systemd

## Обмеження засобами контейнеризації та віртуалізації

=> linux-isolation-from-direct-internet-connections-based-on-qemu-virtual-machine-manager-with-vsock.gmi Ізоляція Linux від прямих Інтернет з'єднань на базі QEMU / Virtual Machine Manager з VSOCK

## Дивіться також

=> filter-outgoing-connections-with-ufw.gmi Обмеження вихідних з'єднань на Інтернет з ufw
=> arti-onion-router-with-tor-connection-over-yggdrasil.gmi Встановлення Onion-роутера Arti з підключенням до мережі Tor через Yggdrasil