ما الذي يعترضه 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، وابقِه منفصلًا عن اعتراض المكتبة. الاعتراض أداة توافق لبرنامج محدد، وليس مفتاح إيقاف. سجّل البرنامج والأمر الدقيق ومنفذ الوسيط الذي ظهر في التتبّع وهل حُلّل DNS عن بُعد؛ تلك الحقائق الأربع هي الفرق بين نطاق مُتحقَّق منه ونطاق مأمول.