VPN عبر Tor: فحص النقل أولًا

يعني نهج Tor أولًا أن عميل VPN يجلس خلف وكيل SOCKS، لذا يُبنى النفق نفسه عبر Tor وتخرج حركة التطبيقات من نقطة نهاية VPN. هذا ترتيب محدد واحد، وهو ليس ما يبنيه معظم الناس. فتح متصفح Tor إلى جانب عميل VPN عادي لا يجبر أيًا من البرنامجين على استخدام مسار الآخر.

اعمل على الفحوص بالترتيب. كل فحص يقرر ما إذا كان التالي يستحق البدء.

أي ترتيب تبني فعلًا

يُخلط بين ترتيبين في المحادثة نفسها. ترتيب Tor أولًا يعني أن عميل VPN يصل إلى خادمه عبر وكيل SOCKS، لذا يُبنى النفق فوق Tor. ترتيب VPN أولًا يعني أن حركة Tor تخرج عبر النفق، وهو ما يبنيه معظم الناس بالخطأ ثم يصفونه بأنه الترتيب الآخر. الأول يركز حدود إعادة التوجيه عند مشغل VPN، والثاني يركزها عند مدخل Tor ومخرجه. لا أحد منهما هو ما تحصل عليه من فتح التطبيقين معًا في الوقت نفسه.

اكتب أي الترتيبين تحتاجه المهمة قبل تهيئة أي شيء، لأن الاثنين يتطلبان إعدادات برمجية مختلفة ويفشلان في مواضع مختلفة. الترتيب الموصوف خطأً يرسلك لتصحيح الطبقة الخاطئة لمدة ساعة. كل ما يلي يفترض Tor أولًا.

افحص النقل قبل أي شيء آخر

واجهة SOCKS في Tor تحمل تدفقات TCP ولا توفر ارتباط UDP عامًا. VPN الذي يكون نقله UDP لا يمكنه التعامل مع ذلك الوكيل كواجهة شبكة عادية، ولا يغير أي إعداد في العميل ما يقبله الوكيل ليمرره. WireGuard في شكله المعتاد هو الضحية الواضحة. ملف تعريف OpenVPN في وضع TCP هو الحل الشائع، وما زال يجب إخباره صراحةً باستخدام الوكيل.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

تأكد من أن الوكيل يستمع ويمكنه حمل طلب HTTPS عادي واحد قبل أن تصحح نفقًا عبره. إذا فشل الطلب العادي، فلن ينجح عميل VPN أبدًا ولن تخبرك سجلاته بالسبب.

أعد كتابة خريطة المراقب

يمكن لمدخل Tor أن يرى المصدر الذي يتصل بـ Tor ما لم يغيّره شيء قبله، لذا تتعلم تلك القفزة عنوانك. يتلقى مزود VPN اتصالًا قادمًا من جهة Tor لكنه قد يعرف مع ذلك حسابًا أو سجل دفع أو بيانات اعتماد أرسلتها داخل النفق. الوجهات التي تُبلغ عبر VPN ترى مخرجه بدلًا من مخرج Tor، وذلك يركز حدود إعادة التوجيه النهائية عند مشغل واحد.

كما لا يعيد إنشاء مسار موزع إلى كل وجهة. يبني متصفح Tor دائرة جديدة لكل موقع؛ أما VPN المحمول عبر Tor فيبني نفقًا واحدًا، وكل موقع خلفه يتشارك تلك النقطة الطرفية. عامل الفرق كحقيقة تصميمية لا كقيد يجب التخلص منه.

عدّ طبقات الفشل عندما ينكسر

الإعداد المعطل فيه أربع طبقات مستقلة على الأقل: اتصال SOCKS، ومصافحة TLS مع خادم VPN، ومصافحة VPN نفسها، ثم التوجيه أو تحليل الأسماء داخل النفق. كل طبقة تفشل بعَرَض مختلف وتحتاج إصلاحًا مختلفًا. تخفيف فحوص الشهادات لأن النفق لا ينهض هو التشخيص الخاطئ الكلاسيكي، ويحوّل مشكلة نقل إلى مشكلة أمنية.

سجّل أول طبقة تفشل وتوقف عندها. رفض الوكيل ومفتاح مرفوض ليسا اختلافين للحدث نفسه.

توقف إذا كان نموذج التهديد يحتاج دفاعات متصفح Tor

توجيه تطبيقات عشوائية عبر VPN محمول بواسطة Tor لا يمنح تلك التطبيقات ميزات البصمة والعزل في متصفح Tor. تبقى حساباتها ومعرّفاتها وسلوكها الشبكي الخاص ذات صلة، والنفق لا يطبّع أيًا منها. إذا كان الهدف متصفحًا يندمج مع مستخدمين آخرين، فهذا الترتيب لا يوفره.

يحذر مشروع Tor نفسه من تركيبات لا يستطيع المستخدمون تهيئتها بشكل صحيح، وهذا التركيب ينطبق على معظم الناس. إنه تصميم مقصود لنموذج تهديد ضيق، وليس طريقًا مختصرًا إلى حركة مجهولة على مستوى الجهاز بأكمله.