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