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 له لارې حل شو که نه ولیکئ؛ همدا څلور حقایق د تصدیق شوې ساحې او د هیله ساحې ترمنځ توپیر دی۔