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 разрешен даљински; те четири чињенице разлика су између провереног обухвата и обухвата наде.

Повезани чланци