ProxyChains-NG не создаёт туннель. Он предварительно загружает библиотеку, которая подменяет сетевые вызовы libc внутри единственной программы, которую запускает, поэтому граница — это вызов в процессе, а не маршрут для всего устройства. Именно это различие определяет, что на самом деле доказывает успешный тест. Работающий curl через цепочку подтверждает один перехваченный вызов, а не то, что разрешение имён, UDP или каждый дочерний процесс пошли тем же путём. Инструкция ниже проверяет покрытие в три шага, а затем перечисляет то, чего перехват не достигает.

Как предварительная загрузка доходит до соединения

При запуске программа-запускатор помещает libproxychains в LD_PRELOAD, а затем выполняет целевую программу. Библиотека разрешает настоящие символы libc и подменяет их своими версиями функций, таких как connect и getaddrinfo. Вызовы, проходящие через эти символы, переписываются на SOCKS- или HTTP-прокси из файла конфигурации. Вызовы, идущие другим путём, никогда не встречают перехват, и поэтому гарантия действует для каждого вызова, а не для всей машины.

Участвуют только динамически скомпонованные программы, а setuid-бинарники при безопасном выполнении полностью игнорируют предварительную загрузку. Дочерние процессы наследуют окружение, но только пока запускатор удерживает его на месте.

Убедитесь, что библиотека загружена в этот процесс

Запустите запрос и осмотрите живой процесс, а не оболочку, которая его запустила. Файл maps показывает каждый разделяемый объект, отображённый в процессе в этот момент.

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

Совпадение подтверждает наличие перехваченной библиотеки, что необходимо, но недостаточно. Пустой результат обычно означает, что вы осмотрели другой процесс, например браузер, передавший URL экземпляру, запущенному до запускатора. Прежде чем гоняться за чем-то ещё, проверьте с помощью ldd, что бинарник скомпонован динамически, поскольку статическая сборка вообще не может загрузить предварительную загрузку. Затем прочитайте список прокси в конфигурации, которую запускатор действительно использовал, потому что устаревший путь или закрытый порт дают работающий перехват без работающей цепочки.

Отслеживайте соединения, покидающие процесс

Наличие библиотеки не доказывает, что каждый вызов был переписан, поэтому следите за системными вызовами. Запустите один запрос под трассировщиком и прочитайте, куда на самом деле ушли сокеты.

strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -u

Трасса должна показывать только соединения к вашей конечной точке прокси, а порт должен соответствовать записи в файле конфигурации. Если адреса назначения целевого сайта появляются в трассе напрямую, этот вызов обошёл перехват, и это именно та находка, которую вы искали. Сравните номера портов со списком прокси, а не доверяйте имени файла, потому что оставшаяся конфигурация из другого проекта — частая причина тихого прямого доступа. Сохраните трассу для акта приёмки; это занимает секунды и снимает споры о покрытии.

Решите, что перехват покрыть не может

проект proxychains-ng ограничивает перенаправление протоколом TCP и предупреждает, что скрипты, фоновые процессы и загруженные модули могут вести себя иначе, чем основная программа. UDP и ICMP находятся вне механизма, поэтому всё, что на них полагается, нуждается в собственном поддерживаемом пути. DNS следует настройке proxy_dns и поведению собственного распознавателя приложения, а значит, один успешный HTTPS-запрос ничего не говорит о разрешении имён. Оставьте и проверку сертификатов там, где ей место: доступ к серверу через прокси не причина отключать проверки подлинности.

Если прямой откат должен быть невозможен, используйте границу принуждения, которая управляет самим трафиком, например сетевое пространство имён, правила брандмауэра или VPN, и держите её отдельно от библиотечного перехвата. Перехват — это инструмент совместимости для конкретной программы, а не kill switch. Запишите программу, точную команду, порт прокси, увиденный в трассе, и то, разрешался ли DNS удалённо; эти четыре факта и есть разница между проверенным охватом и охватом надежды.

Похожие статьи