Изолируем виртуальную машину от обычной сети, и пускаем трафик через TOR

D2

D2

Администратор
Регистрация
19 Фев 2025
Сообщения
4,380
Реакции
0

Предисловие​

Решил я написать обширную и подробную статью о том, как настроить две виртуальные машины для достижения максимального уровня анонимности и скрытности, при этом весь трафик "рабочей" машины будет проходить через Tor на "роутере". В качестве "роутера" используется Alpine Linux, который мы поднимаем в отдельной виртуалке.
Мы максимально подробно рассмотрим теоретические и практические аспекты, включая настройку iptables (за один-два вызова), конфигурацию Tor (c настройками обфускации, исключения конкретных стран при выборе выходных узлов, перенаправление DNS-трафика) и статическую настройку сетевых параметров в "рабочей" виртуалке, чтобы ничего не указывало на то, что она может принадлежать конкретному человеку.

Статья предназначена для сайта xss.is и ориентирована на вопросы информационной безопасности в ознакомительных целях.

Оглавление​

  1. Введение
  2. Почему архитектура "двух виртуальных машин" повышает анонимность
  3. Обзор инструментов и компонентов
    1. Гипервизор KVM + libvirt (или аналог)
    2. Alpine Linux как минималистичная система для "роутера"
    3. Tor и ключевые аспекты анонимизации
  4. Сетевое устройство и план конфигурации
    1. "Router" - Alpine Linux
    2. "Work" - любая система (Linux/Windows и т.д.)
    3. Статическая настройка IP без DHCP
  5. Установка и первичная настройка Alpine Linux
    1. Процесс установки
    2. Включение IP Forwarding и базовых сетевых сервисов
  6. Настройка статической сети в Alpine Linux
    1. Интерфейсы eth0 (внешний) и eth1 (внутренний)
    2. Пример конфигурации
  7. Установка и базовая настройка Tor в Alpine Linux
    1. Установка через apk
    2. Основной блок настроек torrc
    3. Примеры логов, портов, директорий
  8. Исключение нежелательных выходных узлов (ExcludeNodes, ExcludeExitNodes)
    1. Список стран (в т.ч. Five Eyes) и их коды
    2. Правила и примеры в torrc
  9. Настройка обфускации (obfs4) и использование мостов (Bridges)
    1. Установка tor-plugins-obfs4
    2. Пример секции UseBridges
    3. Где брать мосты
  10. Настройка iptables одним-двумя вызовами
    1. Пример полного скрипта
    2. Перенаправление TCP-трафика и DNS
    3. Сохранение и автозапуск
  11. Настройка "Work" - виртуальной машины
    1. Статические IP-параметры
    2. Проверка доступа
  12. Дополнительные проверки и меры предосторожности
    1. Проверка IP и DNS (ipleak, check.torproject.org)
    2. Логирование Tor
    3. Дополнительная защита
  13. Заключение

1. Введение​

Для большинства людей, которым важно утаивать свое присутствие в сети, одной анонимной сети Tor часто оказывается мало. Во многих случаях нужно минимизировать следы, которые могут косвенно указывать на то, что трафик принадлежит определенному пользователю. Одно из наиболее безопасных решений - использовать физический или виртуальный "маршрутизатор" на отдельной машине, где настроен Tor и соответствующие iptables-правила, а в роли основной "рабочей" системы (где пользователь реально запускает приложения, браузеры и т.д.) выступает другая виртуальная машина.

Смысл заключается в том, что вся внешняя активность "Work" (как браузер, мессенджеры, торренты и так далее) физически (или логически) вынесена в другую машину и уходит в интернет исключительно через специализированный маршрутизатор с Tor. Это значительно повышает анонимность, усложняет деанонимизацию, а также предотвращает случайные утечки реального IP, например, если "Work" VM будет скомпрометирована или неправильно настроена.

В результате вы получите схему, в которой "рабочая" VM изолирована от реальной хост-системы, а ее весь трафик идет только через Tor на "роутере".

2. Почему архитектура "двух виртуальных машин" повышает анонимность​

Главный фактор, влияющий на анонимность, - это как раз изоляция. Если пользователь запускает Tor прямо на хостовой системе, велик риск, что какая-то часть трафика (допустим, системные обновления, служебные процессы, неожиданные фоновые службы) может пойти в обход Tor. Также потенциальные уязвимости или неправильные настройки способны привести к тому, что реальный IP "засветится".

Если же создать отдельную, достаточно минималистичную машину, работающую как маршрутизатор, и там поднять Tor (с дополнительными правилами iptables для "прозрачного" прокси, UDP/TCP, DNSPort и т.д.), то весь трафик "Work" физически (или виртуально) проходит только через этот узел и не может "проскочить" напрямую в Интернет. Кроме того, если "Work" пострадает от заражения вредоносным ПО или будет атакован, злоумышленник не сможет так легко изменить глобальные настройки сети, потому что они находятся на другом уровне (другой машине).

3. Обзор инструментов и компонентов​

3.1 Гипервизор KVM + libvirt (или аналог)​

В мире Linux одним из самых популярных средств виртуализации является связка KVM/QEMU + libvirt. Она предоставляет удобные инструменты:
  • "virt-manager" - графический менеджер для управления виртуалками;
  • "virsh" - CLI-инструмент с широкими возможностями;
  • "qemu/kvm" - виртуализатор, обеспечивающий высокую производительность.
Однако можно использовать и VirtualBox, VMWare, Hyper-V или Proxmox - ключевой момент здесь в том, чтобы уметь настроить две виртуальные машины с нужным типом сетей (одна - выходит в интернет, другая - смотрит в "роутер").

3.2 Alpine Linux как минималистичная система для "роутера"​

Alpine Linux - это легковесный дистрибутив, в котором нет systemd, он использует OpenRC, а пакетный менеджер apk. Размер образа крайне мал, что делает его идеальным для поднятия в качестве "маршрутизатора". При этом он содержит все основные пакеты, нужные для настройки маршрутизации и Tor (iptables, nftables, tor, obfs4proxy и т.д.).

3.3 Tor и ключевые аспекты анонимизации​

Tor ("The Onion Router") - это сеть добровольных узлов, через которые проксируется трафик в зашифрованном виде. Пройти от клиента к серверу нужно через три (или более) узла (Guard, Middle, Exit), что помогает скрыть реальный IP отправителя. Дополнительно можно:
  • Использовать obfs4 (мосты и обфускацию) для обхода блокировок.
  • Исключать определенные страны или сети (ExcludeNodes, ExcludeExitNodes) для повышения конфиденциальности или пропуска трафика только через "дружественные" регионы.
  • Перенаправлять DNS-запросы через Tor, используя DNSPort, чтобы не было утечек.

4. Сетевое устройство и план конфигурации​

В классической конфигурации у нас есть две виртуальные машины:
  1. "Router" (Alpine Linux) - c двумя сетевыми интерфейсами:
    • eth0 - подключен к внешней сети (NAT или bridge, в зависимости от того, как настроено на хосте), чтобы иметь выход в интернет.
    • eth1 - "внутренняя" сеть (виртуальный свитч, выделенный в libvirt/VirtualBox), где Alpine Linux будет иметь IP, например, 192.168.55.1 (статический).
      На этом "Router" мы запускаем Tor и iptables, чтобы проксировать весь трафик от других машин в этой сети через Tor.
  2. "Work" (любая ОС) - c одним интерфейсом:
    • eth0 (или ens3 и т.п.), который подключен к той же внутренней сети, где гейтвей - 192.168.55.1. На "Work" вручную прописываем статические адреса, например 192.168.55.10, маска 255.255.255.0, шлюз 192.168.55.1, DNS тоже 192.168.55.1 (если хотим маршрутизировать все запросы DNS через Tor).
Таким образом, "Work" не имеет прямого выхода в Интернет - он может ходить только через Alpine Linux. IP Forwarding включен, а iptables на Alpine перенаправляет любой TCP/UDP*-трафик (DNS) в Tor-прокси-порты (9040, 53 и т.д.).
* UDP трафик проходит только от DNS на порт Tor'а, так как Tor работает только с TCP трафиком.

5. Установка и первичная настройка Alpine Linux​

5.1 Процесс установки​

Скачиваем образ Alpine Linux (последний релиз) с сайта https://alpinelinux.org/downloads/ и подключаем его к виртуальной машине "Router". Запускаем VM, в консоли вводим:
Bash: Скопировать в буфер обмена
setup-alpine
Далее следуем диалогу (раскладка клавиатуры, таймзона, имя хоста, зеркала репозиториев и т.д.). В конце нас спросят, установить ли систему на диск - выбираем "y" и указываем, на какой диск (обычно /dev/vda или /dev/sda в виртуалках).

Перезагружаемся после завершения установки.

5.2 Включение IP Forwarding и базовых сетевых сервисов​

После установки входим под root (пароль, который указывали при настройке) и редактируем "/etc/sysctl.conf", добавляя строку:
net.ipv4.ip_forward=1
Далее применяем:
Bash: Скопировать в буфер обмена
sysctl -p
Теперь трафик может форвардиться через нашу Alpine VM.
Также стоит установить iptables:
Bash: Скопировать в буфер обмена
Код: 
apk update
apk add iptables
(либо nftables, если предпочитаете более современный инструмент).

6. Настройка статической сети в Alpine Linux​

6.1 Интерфейсы eth0 (внешний) и eth1 (внутренний)​

Предположим, что eth0 получает IP через DHCP от хостовой NAT/Bridge-сети, и в этом нет ничего плохого. Но для eth1 нам нужна статическая конфигурация, чтобы быть гейтвеем для "Work".
Редактируем файл "/etc/network/interfaces" (или "/etc/network/interfaces.d/eth1" - в зависимости от версии Alpine и используемой конфигурации).
Пример (в простейшем виде):
Код: Скопировать в буфер обмена
Код: 
auto eth1
    iface eth1
    inet static
    address 192.168.55.1
    netmask 255.255.255.0
Сохраняем и перезапускаем:
Bash: Скопировать в буфер обмена
/etc/init.d/networking restart
Проверяем, что адрес установился:
Bash: Скопировать в буфер обмена
ip addr show dev eth1
Если все корректно, видим "inet 192.168.55.1/24".

6.2 Пример конфигурации​

Если у вас более новая версия, может быть "udhcpc" по умолчанию на eth0. Для eth1 главное - прописать статический IP, как выше, а затем проверить маршруты:
Bash: Скопировать в буфер обмена
ip route show
Внешний маршрут по умолчанию будет на eth0, а никакого маршрута на eth1 не нужно, поскольку это локальная сеть.

7. Установка и базовая настройка Tor в Alpine Linux​

7.1 Установка через apk​

Далее устанавливаем Tor:
Bash: Скопировать в буфер обмена
apk add tor
По умолчанию в Alpine должен быть пакет "tor", который включает основные бинарники и конфигурационные файлы.

7.2 Основной блок настроек torrc​

Файл "/etc/tor/torrc" (иногда в старых версиях "/etc/tor/torrc.sample") можно отредактировать. Для удобства, чтобы все данные Tor хранились в нестандартной директории (например, "/xssrouter/tor/share/tor"), мы можем в torrc прописать:
Код: Скопировать в буфер обмена
DataDirectory /xssrouter/tor/share/tor
Создадим папку, если нужно:
Bash: Скопировать в буфер обмена
Код: 
mkdir -p /xssrouter/tor/share/tor
chown -R tor:tor /xssrouter/tor/share/tor
chmod 700 /xssrouter/tor/share/tor

Теперь посмотрим на пример конфигурации (адаптируем под свои нужды). Ниже представлен расширенный вариант, который включает:
  • SocksPort 0.0.0.0:9050 - слушать на всех интерфейсах, порт 9050 (простой SOCKS5).
  • DNSPort 0.0.0.0:53 - слушать на порту 53 для DNS.
  • TransPort 0.0.0.0:9040 - транспарентный прокси.
  • ControlPort 127.0.0.1:9051 - контрольный порт (доступен только локально).
  • VirtualAddrNetworkIPv4 10.70.0.0/16 - для сопоставления .onion доменов при AutomapHostsOnResolve.
  • AutomapHostsOnResolve 1 - автоматически мапить такие домены в диапазон VirtualAddrNetwork.
  • Логирование (Log notice /var/log/tor.log и Log err /var/log/tor.error.log).
  • Отключенная строка для Socks5Proxy, если вдруг нужно использовать внешний SOCKS для Tor.
Итоговый пример torrc может выглядеть так:
Код: Скопировать в буфер обмена
Код: 
SocksPort 0.0.0.0:9050
DNSPort 0.0.0.0:53
TransPort 0.0.0.0:9040
ControlPort 127.0.0.1:9051

Если хотим, можем раскомментировать и указать прокси, через который Tor будет ходить:
Код: Скопировать в буфер обмена
Код: 
...
Socks5Proxy 127.0.0.1:9998

VirtualAddrNetworkIPv4 10.70.0.0/16
AutomapHostsOnResolve 1

Log notice file /var/log/tor.log
Log err file /var/log/tor.error.log

DataDirectory /xssrouter/tor/share/tor
Таким образом, Tor будет принимать запросы на TransPort (9040) - мы будем перенаправлять туда весь TCP-трафик пользователей; DNS будет слушать на 53; а SOCKSPort может использоваться отдельно, если нам нужно подключаться через SOCKS (например, для локальных приложений на самом "Router").

8. Исключение нежелательных выходных узлов (ExcludeNodes, ExcludeExitNodes)​

8.1 Список стран и их коды​

Tor позволяет указать, какие ноды мы хотим исключить при выборе выхода. Это делается с помощью директив:
  • ExcludeNodes {xx},{yy},{zz}
  • ExcludeExitNodes {xx},{yy},{zz}
где xx, yy, zz - это коды стран в фигурных скобках.

Пользователи часто исключают так называемые "Five Eyes" страны (США (us), Австралия (au), Канада (ca), Новая Зеландия (nz), Великобритания (gb)). Нередко добавляют также некоторые другие государства по соображениям конфиденциальности, например, Францию (fr). В примере к этому списку добавлены также Аргентина (ar) и Иран (ir), но это лишь пример - каждый пользователь может модифицировать по своим нуждам.

8.2 Правила и примеры в torrc​

Чтобы в torrc исключить эти страны из цепочки нодов, нужно добавить строки:
Код: Скопировать в буфер обмена
Код: 
ExcludeNodes {us},{au},{ca},{nz},{gb},{fr},{ar},{ir}
ExcludeExitNodes {us},{au},{ca},{nz},{gb},{fr},{ar},{ir}

Можно добавлять сколько угодно стран, ориентируясь на список кодов (двухбуквенные идентификаторы). В результате Tor будет стараться не использовать узлы, попадающие под эти регионы (и при выборе выходного узла, и при выборе промежуточных узлов).
Однако следует понимать, что подобные жесткие фильтры могут уменьшить число доступных нод и повлиять на стабильность/скорость подключения.

После завершения редактирования torrc можете проверить его:
Bash: Скопировать в буфер обмена
tor --verify-config

9. Настройка обфускации (obfs4) и использование мостов (Bridges)​

9.1 Установка tor-plugins-obfs4​

В Alpine я привык ставить плагин obfs4 из исходников:
Bash: Скопировать в буфер обмена
Код: 
# ставим пакеты для сборки
apk add \
    build-base \
    libevent-dev \
    openssl-dev \
    zlib-dev \
    xz \
    automake \
    autoconf \
    libtool \
    libffi-dev \
    go \
    git

wget "https://github.com/Yawning/obfs4/archive/refs/tags/obfs4proxy-0.0.14.tar.gz"
tar -xzf "obfs4proxy-0.0.14.tar.gz"
cd "obfs4-obfs4proxy-0.0.14/obfs4proxy"
go build
# перемещаем скомпилированный файл в /bin/
mv obfs4proxy /bin/
chmod +x /bin/obfs4proxy
# теперь можно проверить версию, чтобы понять что всё ок
obfs4proxy -version
Это позволит использовать "ClientTransportPlugin obfs4".

9.2 Пример секции UseBridges​

Если в вашей стране Tor заблокирован или вы хотите дополнительно скрыть сам факт использования Tor, можно включить обфускацию. Для этого в torrc дописываем:
Код: Скопировать в буфер обмена
Код: 
UseBridges 1
ClientTransportPlugin obfs4 exec /bin/obfs4proxy managed

(путь "/bin/obfs4proxy" - это пример; вы можете указать, где именно лежит бинарник obfs4proxy)

Далее, чтобы задать конкретные мосты, нужно получить их. Обычно можно отправить запрос на адрес bridges@torproject.org (в теле письма "get transport obfs4"), либо воспользоваться сервисом https://bridges.torproject.org/options. Ну или есть удобный телеграм бот [@]GetBridgesBot В ответ вы получите строки вида:
Bridge obfs4 185.220.101.17:... <фингерпринт> cert=XXXX iat-mode=0
Каждую строку вставляем в torrc:
Код: Скопировать в буфер обмена
Код: 
Bridge obfs4 185.xxx.xxx.xxx:XXXX 59.....XXXX cert=p9L6XXXX iat-mode=0
Bridge obfs4 78.xxx.xxx.xxx:YYYY B8.....XXXX cert=61xl3nF07SsgXXXX iat-mode=2

9.3 Где брать мосты​

  • Официальный сайт Tor (https://bridges.torproject.org/options)
  • Электронная почта bridges@torproject.org (письмо с текстом "get transport obfs4")
  • Телеграм бот [@]GetBridgesBot
  • Различные форумы, чаты, сообщества (иногда выкладывают приватные мосты)
  • Поднять свой мост (в статье описывать не буду, а то будет многа текста)

10. Настройка iptables одним-двумя вызовами​

Теперь нам нужно сделать так, чтобы любой трафик, приходящий от "Work" VM (сети 192.168.55.0/24), автоматически заворачивался на TransPort Tor (9040), а DNS-запросы - на DNSPort (53).

Отметим, что TransPort слушает 9040, а DNSPort (по примеру выше) - 53. Но! Мы должны аккуратно перенаправлять весь трафик с "Work" (TCP) на 9040, а все DNS (UDP/53 и TCP/53) - тоже на 53 (где уже Tor).

В iptables реализуем это следующим образом:
  1. Включаем маскарадинг (если нужно, чтобы "Router" смог выходить в Интернет через eth0 от имени локальных IP).
  2. Создаем пользовательскую цепочку "xssrouter".
  3. Перенаправляем весь исходящий TCP и DNS от 192.168.55.0/24 на порты Tor.
Пример полного скрипта (допустим, мы напишем его в /etc/iptables.xss и потом выполним одной командой):
Bash: Скопировать в буфер обмена
Код: 
#!/bin/sh

# Чистим все цепочки
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

# Включаем NAT (если нужно выходить в интернет под IP Router)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Создаем новую цепочку xssrouter
iptables -t nat -N xssrouter

# Прозрачный прокси:
# - перенаправляем TCP на 9040
# - перенаправляем UDP/53 и TCP/53 на 53 (DNSPort Tor)
iptables -t nat -A PREROUTING -s 192.168.55.0/24 -j xssrouter
iptables -t nat -A xssrouter -p tcp -j REDIRECT --to-ports 9040
iptables -t nat -A xssrouter -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A xssrouter -p tcp --dport 53 -j REDIRECT --to-ports 53

# Фильтр: разрешаем форвард в локальную сеть
iptables -A FORWARD -s 192.168.55.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.55.0/24 -j ACCEPT

# Разрешаем всё на INPUT и OUTPUT (по желанию можно ужесточать)
iptables -P INPUT ACCEPT
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
Допустим, мы сохранили этот скрипт. Выполним одной командой:
Bash: Скопировать в буфер обмена
chmod +x /etc/iptables.xss && /etc/iptables.xss
(Так же в Alpine есть свой механизм сохранения: "rc-service iptables save" и т.д. - смотрите документацию.)

11. Настройка "Work" - виртуальной машины​

11.1 Статические IP-параметры​

В "Work" VM (будь то Linux, Windows или что-то еще), нужно явно прописать в настройках сети:
  • IP: 192.168.55.10 (например)
  • Mask: 255.255.255.0
  • Gateway: 192.168.55.1 (адрес "Router")
  • DNS: 192.168.55.1 (чтобы все DNS-запросы уходили на Alpine, а Alpine будет отправлять их в Tor DNSPort)
В Linux это можно сделать через /etc/network/interfaces или /etc/netplan/*.yaml, nmcli либо другое (см документацию дистрибутива).
Например для /etc/network/interfaces:
Код: Скопировать в буфер обмена
Код: 
auto eth0
    iface eth0
    inet static
    address 192.168.55.10
    netmask 255.255.255.0
    gateway 192.168.55.1
    dns-nameservers 192.168.55.1

В Windows - через "Центр управления сетями" -> "Изменение параметров адаптера" -> "Свойства" -> "IPv4" -> "Использовать следующий IP-адрес". (если ошибся, поправьте. Крайне редко использую WIndows)

11.2 Проверка доступа​

После того как все сохранено, перезапускаем "Work" или сетевой интерфейс. Пробуем:
ping 192.168.55.1
Если ответ есть - отлично, связь с "Router" работает.
Чтобы проверить, идет ли трафик в Интернет, попробуйте открыть в браузере check.torproject.org. Если появляется страница Tor с сообщением об использовании Tor, значит, вы действительно в сети Tor.

12. Дополнительные проверки и меры предосторожности​

12.1 Проверка IP и DNS (ipleak, check.torproject.org)​

Для убедительности стоит посетить сайты типа https://ipleak.net/ (можно другие, их полно), которые проверяют не только ваш IP-адрес, но и DNS. Если все верно настроено, сайт должен отображать, что вы выходите через Tor-узел, а DNS-запросы тоже идут через Tor exit, а не "пробиваются" напрямую к DNS провайдера.

12.2 Логирование Tor​

В нашем torrc указан лог:
Код: Скопировать в буфер обмена
Код: 
Log notice file /var/log/tor.log
Log err file /var/log/tor.error.log

Мониторинг tor.log поможет понять, как формируются цепочки, нет ли проблем, не блокируются ли ваши мосты, нет ли ошибок. Если вы используете obfs4, обратите внимание, что при неправильных данных мостов, Tor может не запуститься.

12.3 Дополнительная защита​

  • Старайтесь не хранить никаких личных данных на "Work" VM, если задача - сохранить полную анонимность.
  • Изолируйте "Router" VM и не устанавливайте туда лишние пакеты.
  • При необходимости используйте шифрованные тома (LUKS, VeraCrypt) для виртуального диска.
  • Отключите всякие потенциальные источники утечек на "Work": WebRTC в браузере, автообновления приложений, и т.д. (по желанию)

13. Заключение​

Архитектура с двумя виртуальными машинами - одна как Alpine Linux-роутер (Tor + iptables), а другая как "Work" - существенно усиливает конфиденциальность. Все запросы, включая DNS, проходят через Tor, а благодаря iptables мы исключаем любые прямые соединения в Интернет. При корректной настройке, "Work" VM не знает о реальном физическом интерфейсе и всегда "видит" только внутреннюю сеть 192.168.55.0/24, а внешний доступ возможен лишь через Alpine Tor.

Важно помнить, что нет 100%-гарантий анонимности: любая ошибка или неосторожное действие (например, открытие личных аккаунтов, публикация уникальной информации, указание контактных данных) может свести на нет усилия по сокрытию личности. Но чисто технически подобная схема - одно из самых грамотных решений для обеспечения высокого уровня приватности и минимизации риска утечек реального IP.

Удачи в настройке и безопасной работе!
Так как статья писалась долго, она может содержать ошибки.
Если нашли ошибки в статье, то пожалуйста уведомите меня, я исправлю их.

Статья специально для xss.is
Автор: keklick1337
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу