Dante SOCKS عبر VPN: نفق كامل مقابل التوجيه بالمصدر

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

تصميمان بنطاقي ضرر مختلفين

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

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

هذا الضيق هو أيضًا القيد: لا يعمل التصميم إلا إذا كانت حزم الوكيل الصادرة تحمل ذلك العنوان فعلًا.

ماذا يفعل إعداد external في Dante

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

المستمع مسألة منفصلة. أبقِ internal مقيدًا بالعملاء الذين ينبغي أن يستخدموا الوكيل، واطلب المصادقة، وأغلق المنفذ بجدار ناري، لأن المستمع المفتوح ليس ميزة في خروج VPN.

تأكد من أن العنوان المهيأ ينتمي فعلًا إلى النفق داخل فضاء أسماء الشبكة الخاص بالوكيل.

بناء الجدول المختار بالمصدر

لعنوان TUN هو 10.90.0.2/24 مع نظير يمكن الوصول إليه عند 10.90.0.1، ورقم جدول لا يستخدمه شيء آخر، يبدو الترتيب هكذا:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

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

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

أين تتسرب قاعدة المصدر

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

DNS هو التسرب الآخر. مقبس المُحلّل لا يستخدم بالضرورة مصدر بيانات الاتصال الخارجي للوكيل، لذا قد تخرج عمليات البحث عن الأسماء عبر WAN. اختبر التحليل بشكل منفصل عن إنشاء الاتصال، وقرر ما إذا كانت تلك النتيجة مقبولة.

يحتاج IPv6 إلى قواعده ومساره الخاصة، لأن ترتيب IPv4 لا يثبت شيئًا عنه.

اختر حسب الفشل الذي يمكنك تحمله

اختر النفق الكامل عندما يجب حماية المضيف ككل ويمكنك صيانة قائمة الاستثناءات. اختر التوجيه القائم على المصدر عندما يجب أن يحتفظ المضيف بمساره وأن تُعاد توجيه خدمة واحدة فقط. كلاهما مشروع؛ والخطأ هو اختيار أحدهما ثم اختباره كأنه الآخر.

أيًا كان اختيارك، تحقق من الجانبين: طلب عبر الوكيل وطلب مباشر من المضيف، مع تسجيل عنوان الخروج الملاحظ لكل منهما.

إذا سقط النفق، فقرر مسبقًا هل ينبغي أن يفشل الوكيل أم يتراجع، ودع جدول التوجيه يعبّر عن ذلك القرار.