mirror of
https://codeberg.org/postscriptum/devzone.org.ua.git
synced 2026-02-19 14:12:39 +00:00
286 lines
No EOL
18 KiB
Markdown
286 lines
No EOL
18 KiB
Markdown
# Встановлення Onion-роутера Arti з підключенням до мережі Tor через Yggdrasil
|
||
|
||
[Arti](https://gitlab.torproject.org/tpo/core/arti) - це сучасна реалізація Onion-роутера мережі [Tor](https://uk.wikipedia.org/wiki/Tor) мовою [Rust](https://uk.wikipedia.org/wiki/Rust_(мова_програмування)).
|
||
|
||
Нижче інструкція зі встановлення та налаштування його проксі-сервера з підключенням до мережі через [Yggdrasil](https://devzone.org.ua/post/yggdrasil-mereza-z-detsentralizovanym-routynhom) (у якості VPN). При відповідному налаштуванні клієнтів, це дозволяє приховати факт користування мережею Tor а також підвищує конфіденційність всередині неї, адже вхідні вузли Tor бачитимуть IP адресу провайдера моста (bridge), а міст - бачитиме IPv6 мережі Yggdrasil (до якої в свою чергу, можна підключитися через інші мережі)
|
||
|
||
## Збірка з вихідного коду
|
||
|
||
При першій збірці програми на Rust, потрібно [встановити середовище розробки](https://devzone.org.ua/post/vstanovlennia-ostannyoyi-versiyi-rust-v-linux). Після чого, забираємо початковий код усіх компонентів Arti та компілюємо його з Сargo:
|
||
|
||
``` bash
|
||
git clone https://gitlab.torproject.org/tpo/core/arti.git
|
||
cd arti
|
||
cargo build -p arti --release
|
||
sudo install target/release/arti /usr/local/bin/arti
|
||
```
|
||
* тут ми встановлюємо тільки компонент `arti` та ставимо його в системну теку для подальшого запуску з systemd; по аналогії можна встановити й інші компоненти (з теки `target/release`) та налаштувати для них сервіси або ж зібрати тільки потрібний нам `-p arti`
|
||
* після виконання команди `install` поточну теку `arti` можна видалити, щоб звільнити простір
|
||
* якщо планується [публікація сайту (onion service)](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/OnionService.md), збірка виконується з аргументом `--features=onion-service-service`
|
||
|
||
## Конфігурація
|
||
|
||
Тут все просто: на сайті є готовий [приклад файлу конфігурації](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/crates/arti/src/arti-example-config.toml) з детальними коментарями до кожної опції. Для підключення до мережі Tor засобами Yggdrasil - достатньо лише вказати потрібні мости, наприклад з [цього списку](https://yggdrasil-network.github.io/services.html#tor-bridges).
|
||
|
||
У своїй конфігурації, я також явно вказав атрибут `enabled`, щоб використовувати для підключення тільки мости зі списку bridges:
|
||
|
||
``` config.toml
|
||
# Bridges (for anticensorship support)
|
||
[bridges]
|
||
|
||
# Should we use configured bridges?
|
||
# If set to false, we will ignore the configured bridges.
|
||
# If set to "auto", we will use any bridges that are configured.
|
||
# If set to true, bridges must be configured and will be used.
|
||
enabled = "true"
|
||
|
||
bridges = [
|
||
"[218:4feb:a509:9db2:2b34:6e7e:e071:5dee]:1991 F805F6B4E5E203EFE2A7FFB1E5042AFE8BD986B4",
|
||
"[220:f022:cd6c:22a9:5285:79e2:2e19:b66a]:1991 6580023D474DD3C06920027530C3B5E39B89DC03",
|
||
"[219:a32f:307b:8372:25d3:e1d0:c8fb:d2f6]:1991 49A53936AF2895A1612603AAA3C1CF8A01830157",
|
||
"[200:ba50:4b2c:8dc9:9529:38de:5677:57a0]:7918 79F9F7CBD0E2A4458F11B7874008D783BCF5C523",
|
||
]
|
||
```
|
||
* [перевірити статус мостів](https://metrics.torproject.org/rs.html)
|
||
|
||
### Мости obfs4
|
||
|
||
В списках мостів бувають і такі, що підтримують обфускацію [obfs4](https://github.com/Yawning/obfs4):
|
||
|
||
``` config.toml
|
||
bridges = [
|
||
"obfs4 [219:a32f:307b:8372:25d3:e1d0:c8fb:d2f6]:1992 49A53936AF2895A1612603AAA3C1CF8A01830157 cert=uVXUO414i8rmHt58SMvdiR0KDxVX7NLmQqLEnINtZxc3g/2B6X+VLLfLZl2m+Mvk6McMHQ iat-mode=0",
|
||
"obfs4 [220:f022:cd6c:22a9:5285:79e2:2e19:b66a]:1992 6580023D474DD3C06920027530C3B5E39B89DC03 cert=pSt9XZ3p/3oxi9knlK4jQY8LFSWZn4hl/PplgnMY5Lra3VaZMbP7F4tuorDV2vXhm8qEAQ iat-mode=0",
|
||
"obfs4 [218:4feb:a509:9db2:2b34:6e7e:e071:5dee]:1992 F805F6B4E5E203EFE2A7FFB1E5042AFE8BD986B4 cert=0GcjnEnZ0rJ8/nfxo4ZSkjMZ0fqHSrvj/MdwEtbbuzx8qgqFTaqHTuWelGw2MxJ5wW2QaQ iat-mode=0",
|
||
"obfs4 [200:ba50:4b2c:8dc9:9529:38de:5677:57a0]:7917 79F9F7CBD0E2A4458F11B7874008D783BCF5C523 cert=3ues7AA498O9YrQ1wsdWyz3/n3YBXN88wXP8mppkE0lTw1YB6FSlDMkm3Ry6jXlj0phzMg iat-mode=0",
|
||
]
|
||
```
|
||
|
||
Щоб використовувати рядки вище, потрібно додатково розкоментувати:
|
||
|
||
``` config.toml
|
||
[[bridges.transports]]
|
||
protocols = ["obfs4"]
|
||
path = "/usr/bin/obfs4proxy"
|
||
```
|
||
|
||
Якщо бекенд `obfs4proxy` не встановлено:
|
||
|
||
``` bash
|
||
sudo dnf install obfs4
|
||
which obfs4proxy
|
||
```
|
||
|
||
Перевіряємо транспортний протокол:
|
||
|
||
``` bash
|
||
ps aux | grep obfs4
|
||
```
|
||
|
||
Тепер можна перезапустити роутер Arti та спробувати підключитись.
|
||
|
||
### Віддалений сервер
|
||
|
||
З міркувань безпеки, в конфігурації сокету, можна зустріти наступне повідомлення:
|
||
|
||
> \# Set up the Arti program to run as a proxy.\
|
||
> [proxy]\
|
||
> \# Default port to use when listening to SOCKS connections. We always\
|
||
> \# listen on localhost.
|
||
|
||
В репозиторії можна знайти [пропозиції](https://gitlab.torproject.org/tpo/core/arti/-/issues/1636) реалізувати сповіщення з безпеки, при використанні хостів відмінних від `localhost`. Але бувають ситуації, коли проксі працює на локальному роутері, що відносно безпечно: адже до нього матимуть доступ тільки пристрої локальної мережі; або на віддаленому сервері з відповідним правилом фаєрвол.
|
||
|
||
Перечитавши реалізацію парсера цієї опції, вияснив, що вона таки підтримує вибіркові хости, при чому можна вказати декілька (вектором). Для цього, потрібно вказати хост і порт "рядком" з лапками, у форматі адреси сокета:
|
||
|
||
```
|
||
socks_listen = "xxx.xxx.xxx.xxx:9150"
|
||
```
|
||
|
||
Якби навіть цієї опції не було, я все одно обійшов би обмеження "без-програмним" рецептом. Наприклад, зовнішнім проксі на базі Nginx:
|
||
|
||
``` /etc/nginx/nginx.conf
|
||
stream {
|
||
server {
|
||
listen a.a.a.a:9150;
|
||
proxy_pass b.b.b.b:9150;
|
||
}
|
||
}
|
||
```
|
||
* `a.a.a.a` - сервер Nginx
|
||
* `b.b.b.b` - сервер Arti
|
||
|
||
Порт на "зовнішньому" хості потрібно обов'язково обмежити засобами iptables, дозволивши потрібний явно (а краще - використовуючи й не стандартний порт)
|
||
|
||
``` bash
|
||
ufw allow from a.a.a.a to b.b.b.b port 9150 proto tcp
|
||
```
|
||
* `a.a.a.a` - хост клієнта
|
||
* `b.b.b.b` - хост сервера
|
||
|
||
Для подальшого запуску з systemd, користувача створив наступним чином:
|
||
|
||
``` bash
|
||
sudo useradd -m arti
|
||
```
|
||
* тобто, з домашньою текою, де роутер зберігатиме дані сесії за замочуванням - використовуючи змінні оточення `${ARTI_CACHE}` і `${ARTI_LOCAL_DATA}`
|
||
|
||
### Локальний хост
|
||
|
||
Я довго думав, яким чином організувати багато-користувацький простір, щоб не конфліктували між собою сесії при запуску через системний сервіс. Взагалі, роутер розрахований на запуск від поточного системного користувача з подальшим зберіганням даних сесії в його домашній теці. Утім, я хочу обмежити доступ цього експериментального софту до моїх персональних даних в робочому середовищі.
|
||
|
||
Можливо, це не правильно, але оскільки сервіс один, я організував профіль роутера наступним чином:
|
||
|
||
``` bash
|
||
useradd -s /usr/sbin/nologin -Mr arti
|
||
```
|
||
* створюється прихований системний користувач `arti` без домашньої теки
|
||
|
||
Тепер знадобляться дві нові теки:
|
||
|
||
``` bash
|
||
sudo mkdir /var/lib/arti
|
||
sudo mkdir /var/log/arti
|
||
```
|
||
|
||
На які потрібно дати права:
|
||
|
||
``` bash
|
||
sudo chown arti:arti -R /var/lib/arti
|
||
sudo chown arti:arti -R /var/log/arti
|
||
```
|
||
|
||
У файлі конфігурації, вказуємо:
|
||
|
||
``` config.toml
|
||
[storage]
|
||
state_dir = "/var/lib/arti/state"
|
||
cache_dir = "/var/lib/arti/cache"
|
||
port_info_file = "/var/lib/arti/public/port_info.json"
|
||
```
|
||
* варто звернути увагу на всі змінні оточення (які починаються на `$`) але мені вистачило перевизначення тільки вказаних
|
||
|
||
Оскільки користувача відмічено як `nologin`, для запуску службових команд (наприклад, отримання домену `.onion`) від його імені, використовується такий підхід:
|
||
|
||
``` bash
|
||
su arti -s /bin/bash \
|
||
-c 'arti hss -c /path/to/config.toml --nickname allum-cepa onion-address'
|
||
```
|
||
* `allum-cepa` - це назва умовного кейсу `[onion_services."allum-cepa"]` в `config.toml`
|
||
|
||
### Системний сервіс
|
||
|
||
Приклад конфігурації для Debian є в [репозиторії](https://gitlab.torproject.org/tpo/core/arti/-/blob/main/debian/systemd/arti.service):
|
||
|
||
``` /etc/systemd/system/arti.service
|
||
[Unit]
|
||
Description=System Tor Service (Arti)
|
||
After=network.target
|
||
Wants=network.target
|
||
|
||
[Service]
|
||
Type=simple
|
||
|
||
User=arti
|
||
Group=arti
|
||
|
||
ExecStart=/usr/local/bin/arti --config /path/to/config.toml -l warn proxy
|
||
ExecReload=/bin/kill -HUP ${MAINPID}
|
||
|
||
KillSignal=SIGINT
|
||
LimitNOFILE=16384
|
||
|
||
NoNewPrivileges=yes
|
||
PrivateTmp=yes
|
||
PrivateDevices=yes
|
||
ProtectHome=yes
|
||
ProtectSystem=full
|
||
ReadOnlyDirectories=/
|
||
ReadWriteDirectories=-/var/lib/arti
|
||
ReadWriteDirectories=-/var/log/arti
|
||
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
|
||
|
||
# StandardOutput=file:///path/to/debug.log
|
||
# StandardError=file:///path/to/error.log
|
||
|
||
[Install]
|
||
WantedBy=multi-user.target
|
||
```
|
||
* вказати актуальний шлях `/path/to/config.toml` - це може бути домашня тека або простір `/etc`
|
||
|
||
Керування:
|
||
|
||
* `sudo systemctl restart arti` - (пере)запустити сервер:
|
||
* `sudo systemctl enable arti` - авто-запуск при старті системи
|
||
* `systemctl status arti` - перевірити статус служби
|
||
|
||
## Підключення клієнтських застосунків
|
||
|
||
В клієнтах IRC, браузерах та інших застосунках - достатньо вказати (SOCKS5) хост/порт проксі-сервера Arti, стандартно:
|
||
|
||
* `127.0.0.1:9150`
|
||
* `[::1]:9150`
|
||
* або `хост:порт` віддаленого сервера з файлу конфігурації (`socks_listen`)
|
||
|
||
### Налаштування браузера засобами PAC
|
||
|
||
Якщо метою користування Tor є анонімізація, то для фільтрації прямих з'єднань на Інтернет зручно встановити окремий браузер, вказавши в ньому єдиний проксі. Або/і скористатись маршрутизацією [PAC](https://en.wikipedia.org/wiki/Proxy_auto-config). Вона дозволяє гнучко налаштовувати потрібні правила для окремих URL засобами JS. Варіант налаштування PAC у браузерах сімейства FireFox - описував на [прикладі налаштувань проксі-сервера Yggstack](https://devzone.org.ua/post/bezpechnyy-perehliad-saytiv-yggdrasil-z-yggstack).
|
||
|
||
Таким чином, вдається уникнути ідентифікації користувача Tor (або іншого проксі) в ареалах, де використання такого може бути заборонено. Наприклад, шляхом вбудованого на сайт зображення, файлу скриптів або стилів у код на сайті.
|
||
|
||
Утім, описаний вище спосіб запобігає лише одному способу виявлення з поміж багатьох. В цьому плані, браузер Tor - є більш привабливим, адже включає з коробки й інші засоби маскування відбитків пальців: динамічний розміру екрану, шрифти, політику cookies, JS, заголовків HTTP тощо.
|
||
|
||
### Ізоляція середовища
|
||
|
||
Для більш фундаментальної ізоляції застосунків від спроби зловмисником спровокувати прямий запит в Інтерент, дивіться наступні матеріали:
|
||
* [Ізоляція Linux від прямих Інтернет з'єднань на базі QEMU / Virtual Machine Manager з VSOCK](https://devzone.org.ua/post/izoliatsiia-linux-vid-priamykh-internet-zyednan-na-bazi-qemu-virtual-machine-manager-i-vsock)
|
||
* [Обмеження вихідних з'єднань на Інтернет з ufw](https://devzone.org.ua/post/obmezennia-vykhidnykh-zyednan-na-internet-z-ufw)
|
||
|
||
Описані вище рішення дозволяють безпечно користуватись застосунками, які від початку не розроблялись з метою приватності: більшість клієнтів BitTorrent, криптографічних гаманців, та інші, що працюють за принципом Peer-to-Peer і реалізують технології DNS та PEX.
|
||
|
||
## Тестування з'єднань
|
||
|
||
Перевірити роботу роутера можна запустивши його в терміналі з аргументом відлагодження:
|
||
|
||
``` bash
|
||
arti --config /path/to/config.toml --log-level debug proxy
|
||
```
|
||
|
||
Перевірити активні порти:
|
||
|
||
``` bash
|
||
netstat -tulpn | grep arti
|
||
```
|
||
|
||
Підключитись до потрібного вузла:
|
||
|
||
``` bash
|
||
curl --socks5-hostname 127.0.0.1:9150 -I http://acetonemadzhxzi2e5tomavam6xpucdfwn2g35vrsz6izgaxv5bmuhad.onion/index.html
|
||
```
|
||
|
||
### Контроль витоків трафіку
|
||
|
||
Реалізації журналів я не довіряю і додатково перевіряю трафік графічною утилітою [Etherape](https://etherape.sourceforge.io):
|
||
|
||
``` bash
|
||
apt install etherape
|
||
sudo etherape
|
||
```
|
||
|
||
## Діагностика проблем
|
||
|
||
Якщо ви змінили мости і вони виявились не робочими - не поспішайте шукати нові. З коробки, Arti кешує попередні налаштування.
|
||
|
||
Переглядаючи журнал в режимі як мінімум `INFO`, можна побачити повідомлення:
|
||
|
||
> INFO arti::subcommands::proxy: Sufficiently bootstrapped; proxy now functional.
|
||
> WARN tor_dirmgr::bootstrap: error while downloading error=error: Problem downloading directory object: Error while getting a circuit: Tried to find or build a tunnel 6 times, but all attempts failed
|
||
|
||
Тому я вирішив проблему скидання кешу видаленням директорії профілю:
|
||
|
||
``` bash
|
||
rm -rf /home/arti/.local/share/arti
|
||
```
|
||
* у вас цей шлях може різнитися, в залежності від способу запуску роутера
|
||
* дана тека може містити ключі доменів `.onion`, тому краще видалити тільки `cache` і `state`
|
||
|
||
Ймовірно, існує спосіб вимкнення кешування у файлі конфігурації (наприклад, оперуючи `cache_dir` і `state_dir`) але це сповільнить запуск роутера. Сподіваюсь, дана незручність є тимчасовістю версії `1.9.0`, адже проєкт Arti - все ще перебуває в розробці. |