Анонимная среда для работы в интернете на Tor и Shadowsocks
Почему обычные схемы дают сбой
Для доступа к интернету через Tor обычно используют один из двух подходов. Первый - Tor Browser напрямую. Второй - VPN или Shadowsocks. Однако у каждого варианта есть существенный недостаток.
Tor Browser обеспечивает анонимность, но выходные узлы сети Tor известны и публикуются в открытом доступе. Из-за этого сайты за Cloudflare часто показывают CAPTCHA, некоторые сервисы возвращают ошибку Access Denied, а отдельные площадки принудительно разрывают соединение. Формально пользователь скрыт, но работать в интернете становится сложно.
VPN и Shadowsocks решают проблему блокировок, однако доверие просто переносится на другого участника. Интернет-провайдер видит подключение к конкретному VPS, а владелец сервера получает реальный IP-адрес пользователя и может наблюдать за проходящим через него трафиком. В итоге один оператор способен сопоставить личность и сетевую активность.
Задача безопасной схемы - разделить эту информацию между несколькими независимыми звеньями. Провайдер не должен понимать, какие сайты посещаются, сервер Shadowsocks не должен видеть реальный адрес пользователя, а конечная площадка не должна определять, что соединение установлено через Tor.
Почему важен порядок соединений
В распространённой конфигурации сначала запускают Shadowsocks, а затем поверх него Tor:
Shadowsocks → Tor
Такая последовательность скрывает Tor от провайдера, но не решает всех проблем. Провайдер видит подключение к VPS, оператор VPS знает настоящий IP-адрес клиента, а сайт получает адрес Tor-выхода и может заблокировать его.
В более подходящем варианте цепочка строится наоборот:
Tor → Shadowsocks
В этом случае интернет-провайдер наблюдает соединение с obfs4-мостом - внешне это выглядит как поток данных без явных признаков Tor. Входной мост знает адрес пользователя, но не видит конечный ресурс. Выходной узел Tor устанавливает связь с VPS, однако не получает реальный IP клиента. Оператор Shadowsocks видит подключение от Tor exit, а не от пользователя. Сайт получает обычный IP хостинга и не может напрямую определить использование Tor.
Таким образом, ни один отдельный участник не располагает полной картиной:
| Участник | Что видит | Чего не знает |
|---|---|---|
| Интернет-провайдер | Зашифрованное подключение к неизвестному адресу | Какие сайты посещаются и какие DNS-запросы выполняются |
| Tor-мост | Реальный IP пользователя | Конечный пункт назначения |
| Выходной узел Tor | Соединение с VPS | Личность пользователя |
| Оператор VPS | Tor exit и зашифрованный поток | Реальный адрес клиента |
| Сайт | IP обычного хостинга | Использование Tor и личность посетителя |
Для сетевой деанонимизации потребуется сопоставлять журналы как минимум двух независимых участников. Это возможно, но существенно сложнее, чем получить всю информацию из логов одного VPN-сервиса.
Из чего состоит окружение
Для сборки такой конфигурации можно использовать CLI-инструмент на Bash, условно названный `irondome`. Он разворачивает изолированную сетевую среду на Linux-машине и, что особенно важно, не позволяет приложениям обойти заданную цепочку.
Маршрутизация выполняется на уровне ядра Linux. `sing-box` создаёт TUN-интерфейс `iron0`, через который проходят пакеты из анонимной среды. Конфигурация генерируется при запуске и сохраняется во временном каталоге:
```text
/run/iron-dome/sing-box.json
```
Пользовательским приложениям не требуется отдельно задавать прокси. Они работают через прозрачный маршрут, а сетевой стек перенаправляет трафик в нужное виртуальное устройство.
DNS нельзя оставлять без защиты
Одна из наиболее распространённых ошибок в подобных системах - защищать основной трафик, но забывать о DNS. В результате сайты открываются через туннель, а запросы доменных имён отправляются напрямую провайдеру.
Даже если IP-адрес пользователя не раскрывается, оператор связи получает подробный список посещённых доменов и время каждого обращения. По такой последовательности нередко можно восстановить профиль активности.
Для предотвращения утечки используется перехват DNS-запросов на 53-м порту. Компонент `hijack-dns` принимает такие обращения и отправляет их через DoH внутрь той же сетевой цепочки. В конфигурации DNS-запросу назначается отдельный маршрут, например через `outline-socks`.
Дополнительно стоит учитывать приложения, которые используют собственные DNS-службы, DoH или DoT. Их необходимо либо принудительно направлять через общий туннель, либо запрещать отдельными правилами. Иначе программа может обойти системный резолвер.
Почему UDP блокируется
В конфигурации может присутствовать правило:
```json
{"network": "udp", "action": "reject"}
```
Оно выглядит жёстким, но выполняет важную функцию. UDP через SOCKS5 поддерживается неполно: часть приложений либо не сможет передать такие пакеты, либо отправит их напрямую через физический интерфейс. Второй вариант недопустим с точки зрения защиты от утечек.
Поэтому UDP полностью отбрасывается. Современные браузеры после этого не используют QUIC и переходят на TCP. Некоторые страницы могут загружаться немного медленнее, зато риск неконтролируемого обхода туннеля снижается.
Отдельным исключением обычно являются DNS-запросы, если они специально перехватываются и обрабатываются внутри защищённого маршрута.
Ограничение по UID
Маршрутизировать всю операционную систему через анонимную цепочку не всегда удобно. Обновления, рабочие SSH-подключения и обычные системные процессы могут начать работать медленно или конфликтовать с правилами маршрутизации.
Поэтому границу среды задают через `include_uid`. В туннель попадает не вся машина, а только процессы определённого пользователя. Остальная система продолжает использовать стандартное подключение.
Практический вариант - создать отдельную учётную запись для браузера и других приложений, которым требуется анонимный доступ. При необходимости в список можно добавить и UID 0, однако это увеличивает область воздействия и требует особой осторожности.
Защита от обхода TUN
Одной только настройки маршрута недостаточно. Некоторые программы умеют самостоятельно выбирать сетевой интерфейс или создавать собственные сокеты. Чтобы они не вышли в интернет напрямую, используется параметр:
```text
strict_route: true
```
Он запрещает приложениям обходить TUN-интерфейс и привязываться к физической сетевой карте. Даже намеренная попытка отправить пакет через другой маршрут должна завершаться отказом.
Здесь важно различать две задачи. Прозрачный маршрут отвечает за корректное прохождение трафика через нужные узлы. Механизм блокировки гарантирует, что при ошибке или попытке обхода пакет не уйдёт наружу.
Что происходит при сбое
Без аварийной блокировки система может неожиданно перейти на обычное подключение. Например, Tor остановился, `ss-local` завершился, `sing-box` не смог запуститься или пользователь отключил один из сервисов. Приложение продолжит работу, но уже с реальным IP-адресом.
Поэтому применяется принцип fail-closed: при отказе любого ключевого компонента трафик должен блокироваться, а не переключаться на прямой маршрут.
Защитные правила должны закрывать как минимум следующие сценарии:
- остановка Tor;
- падение локального клиента Shadowsocks;
- сбой `sing-box`;
- исчезновение TUN-интерфейса;
- попытка приложения выбрать физический интерфейс;
- ручное отключение сетевого сервиса;
- перезапуск системы до полного запуска цепочки.
Полезно проверять не только доступность интернета, но и состояние каждого элемента. Если браузер перестал открывать страницы после остановки Tor, это хороший признак: система заблокировала соединение. Если сайты продолжают загружаться, нужно искать утечку.
Значение MTU
В двойном туннеле данные получают дополнительную служебную нагрузку. Обфускация, SOCKS5, Tor и виртуальный интерфейс уменьшают доступный размер полезного пакета. Поэтому значение MTU приходится подбирать экспериментально.
В качестве отправной точки можно использовать MTU 1200. На отдельных мостах его потребуется уменьшить ещё сильнее.
Проблема слишком большого MTU проявляется неочевидно: TCP-соединение устанавливается, небольшие страницы открываются, но крупные ответы зависают или исчезают без понятной ошибки. Это связано с фрагментацией и некорректной обработкой Path MTU Discovery внутри нескольких туннелей.
Проверять параметр нужно на реальных сценариях: загрузка больших файлов, открытие тяжёлых страниц, длительные соединения и передача данных через разные сайты.
Как пользоваться средой
На хостовой системе можно оставить обычный браузер и рабочие приложения. Для анонимной активности запускается браузер от выделенного пользователя внутри настроенной среды. Желательно не смешивать личные аккаунты, рабочие сессии и анонимные действия в одном профиле.
Также важно помнить о браузерных отпечатках. Tor-маршрут сам по себе не делает пользователя неузнаваемым, если он устанавливает редкие расширения, меняет размеры окна, включает нестандартные шрифты или авторизуется в личных аккаунтах.
Такая архитектура снижает риск сетевой корреляции и утечек, но не отменяет базовые правила цифровой гигиены. Она не защищает от вредоносных программ, компрометации самой операционной системы, ошибок пользователя или анализа поведения на сайтах.
Основная цена решения - задержка. Трафик проходит через Tor, а затем через дополнительный сервер, поэтому отклик становится заметно медленнее. Для интерактивной работы это обычно терпимо, но видеозвонки, игры и передача больших объёмов данных могут оказаться неудобными.
Главное преимущество схемы - не абсолютная невидимость, а разделение доверия. Провайдер, Tor-узлы, оператор VPS и конечный сайт видят только отдельные фрагменты маршрута. При правильно настроенной DNS-защите, запрете обхода TUN и аварийной блокировке ни один из них не получает всю информацию сразу.