Що ProxyChains перехоплює, а що залишає в спокої

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 віддалено; ці чотири факти й є різниця між перевіреним охопленням і охопленням надії.