Содержание:

Сразу честно: сделать так, чтобы тебя “никто никогда не вычислит”, в реальном интернете нельзя. Можно только уменьшить часть очевидных следов и правильно направить трафик. В сериале это показано как чит-код, в жизни всё сложнее: утечки DNS, особенности приложений, неверные настройки, и банально ошибки пользователя.

Ниже разберём практичный и контролируемый способ на linux: прокси-цепочки через ProxyChains (в связке с Tor), плюс что проверить, чтобы не получить неожиданно “не тот” IP.

Что именно даёт “прокси-цепочка” в Linux

Прокси - это посредник между твоим приложением и сайтом. А ProxyChains - инструмент, который заставляет программы ходить “через” список прокси, вместо прямого соединения в сеть.

Вариант “как у Mr. Robot” чаще всего сводится к такому набору:
- Tor для маршрутизации (цепочка узлов Tor),
- ProxyChains, чтобы оборачивать приложения и запускать их “через прокси”.

Важно: Tor - это анонимизация трафика, а не гарантия “конфиденциальности всего навсегда”. Выходной узел Tor может видеть содержимое трафика на уровне, который зависит от протокола (например, HTTP vs HTTPS).

Подготовка: что поставить (и чем это отличается в разных дистрибутивах)

Для начала нужен ProxyChains-ng.

1) Установочные пакеты и сборка ProxyChains-ng

На Debian/Ubuntu-подобных системах (работает и в linux-контекстах, включая производные):

sudo apt-get update
sudo apt-get install -y git gcc make

sudo apt-get remove -y proxychains

git clone https://github.com/rofl0r/proxychains-ng.git
cd proxychains-ng/

./configure --prefix=/usr --sysconfdir=/etc
make
sudo make install
sudo make install-config

После установки обычно появляется конфиг /etc/proxychains.conf и команда proxychains4.

2) Установить Tor (если вы хотите именно связку “Tor + прокси-цепочки”)

sudo apt-get install -y tor
sudo systemctl enable tor --now

Проверка, что Tor жив:

sudo systemctl status tor --no-pager

Настройка ProxyChains: приводим конфиг в рабочее состояние

Открываем конфиг:

sudo nano /etc/proxychains.conf

1) Уберите Tor из прокси-цепочки (если она там по умолчанию)

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

Комментировать строки, начинающиеся с socks5/http (в зависимости от файла) - ключевое правило: не оставляйте конкурирующие варианты без понимания, что делает конфиг.

2) Включите “динамическую цепочку”, если вы хотите меньше падений из-за недоступных прокси

В некоторых инструкциях рекомендуют отключить strict_chain и включить dynamic_chain. Смысл: соединение пытается собрать цепочку так, чтобы не умереть на первом “мертвом звене”.

В proxychains.conf ищите параметры вроде:
- strict_chain
- dynamic_chain

Если есть возможность - используйте конфиг, где цепочка не обязана быть идеально “строгой”.

3) Добавьте прокси в конец файла

Дальше пример добавления прокси-сервера (формат зависит от типа прокси). В общем виде:
- http IP PORT
или
- socks5 IP PORT

Пример записи:

[ProxyList]
http 31.209.96.50 57482

Смысл простой: ProxyChains будет пытаться использовать этот прокси как часть цепочки.

Если ваша цель именно Tor, то часто вместо “случайного прокси” используют Tor-сокет локально (через стандартные порты Tor). Но так как в конфиге зависит от того, что у вас уже включено/закомментировано, важнее добиться корректной финальной схемы, чем слепо копировать строки.

Как запускать приложения через прокси-цепочки

Проверим, какой IP виден снаружи. Для HTTP-запроса:

proxychains4 wget -qO- eth0.me

Для браузера (если он запускается через процессы, которые корректно оборачиваются):

proxychains4 firefox

Если вы видите “тот же IP, что без ProxyChains” - значит:
- либо приложение обходит ProxyChains,
- либо в конфиге не тот тип прокси,
- либо цепочка не собирается и вы всё равно получаете прямой маршрут (нужно смотреть режим strict/dynamic и поведение в логах/выводе).

Tor + DNS утечки: почему “вроде настроил”, а всё равно палишься

Даже если трафик уходит через Tor, система может делать DNS-запросы так, что они “уходят мимо” ожиданий. Это не всегда заметно визуально.

Минимальная практика проверки:
- проверить IP через внешний сервис (мы выше сделали),
- проверить утечки DNS отдельным тестом на утечки DNS (в интернете есть проверочные страницы, но метод общий: сравнить, чей DNS резолвинг видит “внешний мир”).

Если DNS уходит “не туда”, то один из самых дешёвых способов стабилизировать ситуацию - заставить резолвинг проходить через ту же прокси-схему, но это уже сильно зависит от того, как настроены конкретные приложения и библиотечный стек.

Самые частые “поломки”, из-за которых не открываются страницы

По сути, люди сталкиваются с одним из этих сценариев:

Проблема: “Unable to connect”, а в AnonSurf/других режимах работает

Чаще всего причина в том, что:
- прокси-сервер недоступен или нестабилен,
- в цепочке неверный тип прокси (http vs socks),
- порт закрыт,
- конфиг строгий, и цепочка рвётся из-за одного “мертвого звена”,
- приложение использует другой путь в сеть (обходит ProxyChains).

Проблема: “медленно”

ProxyChains добавляет задержку, а Tor - ещё больше. Это нормальное следствие многосегментной маршрутизации.

Что именно сравнивать: “как у Mr. Robot” vs реальность

Компонент Зачем в схеме Что реально может пойти не так Проверка
proxychains4 заставить приложение идти через прокси приложение обходит обёртку; конфиг не собрал цепочку proxychains4 wget -qO- eth0.me
Tor маршрутизация трафика через узлы неверные настройки локальных прокси/порядка цепочки check.torproject.org (если доступно)
DNS резолвинг влияет на утечки DNS может резолвить “мимо” утечки DNS отдельными тестами
HTTP/HTTPS HTTPS защищает контент от простого чтения с HTTP всё видно иначе смотреть, что URL начинается с https

Практичный итог: “сколько слоёв нужно” (а не “чем больше, тем лучше”)

Если цель бытовая (например, скрыть часть следов/изменить видимый маршрут), часто достаточно:
- нормальной связки Tor (или хотя бы одного адекватного туннеля),
- корректной обёртки трафика для конкретных приложений,
- проверок IP и базовых утечек.

Добавление “тонны бесплатных прокси” обычно ухудшает всё сразу: скорость, стабильность и вероятность ошибок в конфиге. Плюс качество прокси в открытых списках часто такое, что цепочка просто не работает стабильно.

Мини-чеклист перед тем как считать, что всё “как в фильме”

  • Запускаете приложение через proxychains4 и видите, что внешний IP меняется.
  • Сайт открывается, а не падает в “Unable to connect”.
  • Tor действительно включён как служба (если он в схеме).
  • Понимаете, какие строки в /etc/proxychains.conf активны.
  • Не игнорируете DNS (хотя бы базовой проверкой).

Ссылки на авторитетные источники

  • Tor Project (документация и проверка работы): https://www.torproject.org/
  • ProxyChains-ng (репозиторий): https://github.com/rofl0r/proxychains-ng