وكيل SOCKS5 لـ OpenVPN: نفق TCP أم تمرير التطبيقات عبر الوكيل؟

الشبكات التي تسمح فقط بالخروج عبر وكيل هي المكان الذي يموت فيه ملف تعريف كان يعمل فجأة. عنوان الوكيل هو أقل متغير مثير للاهتمام في ذلك الفشل. ما يحسم كل شيء هو شكل حركة المرور التي سيمررها الوكيل، لأن هذه الوكلاء تمرر مجرى بايتات ونفق UDP ليس كذلك. هذا يترك بنيتين، وكلتاهما تنهار في مواضع مختلفة.

قيد واحد يحسم التصميم

يحدد SOCKS5 بالفعل نمط اقتران UDP. ومع ذلك فإن دعم الوكيل في عميل OpenVPN مبني حول المجاري: socks-proxy موثق لملفات تعريف TCP، ووكيل HTTP CONNECT ليس لديه أي مسار لحزم البيانات على الإطلاق. سطر واحد من التوثيق يحسم البنية قبل أن تلمس ملف إعدادات.

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

الخيار أ: حوّل النفق إلى مجرى

يتطلب هذا خادماً لديه مستمع TCP، وملف تعريف عميل يسمي الوكيل. الجزءان مطلوبان، والجانب الخادم هو الذي ينساه الناس:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

استبدل السطر الأخير بـ http-proxy proxy.internal 8080 عندما يتحدث الوكيل HTTP، وأضف ملف بيانات اعتماد إذا طلبه. يجب أن يكون الوكيل مستعداً لتنفيذ CONNECT إلى منفذ VPN الخاص بك، ويجب أن يجيب الخادم على TCP؛ والمستمع المخصص لـ UDP فقط يتجاهل المحاولة. اختيار 443 خطوة عملية، لأن كثيراً من الشبكات المقيدة تسمح به ولا تسمح بغيره تقريباً.

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

الخيار ب: اترك النفق كما هو

عندما يجب أن يبقى النفق على UDP، فالنفق ليس مكان إعداد أي شيء. بدلاً من ذلك يعاد توجيه TCP الصادر من التطبيقات إلى مستمع SOCKS محلي، ولا تعرف التطبيقات أبداً أن وكيلاً موجود. على لينكس يكون ذلك عادةً redsocks بالإضافة إلى قاعدة NAT REDIRECT في جدول nat.

TCP فقط، مرة أخرى. وكيل HTTP فقط مثل privoxy لا يستطيع تمرير بروتوكولات عشوائية، وهذا التصميم لا يضيف أي دعم لحزم البيانات للتطبيقات أيضاً.

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

أين يفشل كل خيار

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

يفشل الخيار ب مع أي شيء يحتاج حزم بيانات، ومع البروتوكولات التي لا يفهمها الوكيل، وبهدوء على المضيفين الذين توجد فيهم قاعدة إعادة التوجيه لكن التوجيه يمرر الحركة من جانبها.

لا يغير أي من الخيارين متطلبات الجهاز. ما زالت الحزم تحتاج عقدة TUN أو TAP قبل أن توجهها النواة، لذا ما زالت العملية تحتاج إذناً على /dev/net/tun. الغلاف يغير ما يحدث بعد فتح تلك العقدة، لا ما إذا كنت تحتاج إليها.

إثبات أي مسار بنيت

انظر إلى المقابس لا إلى أيقونة شريط النظام. يجب أن تحتفظ عملية VPN باتصال قائم بعنوان الوكيل، ويجب أن يكون الوكيل قد سجل الهدف الذي طُلب الوصول إليه:

ss -tnp | grep openvpn

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

دوّن النقل والوكيل القابل في مكان دائم. عندما يفشل الملف نفسه على شبكة أخرى، تستبعد تلك الملاحظة الوكيل أو تؤكده في ثوانٍ.