Dante SOCKS على loopback لخدمة HTTPS تعمل عبر WireGuard فقط

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

يفترض المثال أن Dante 1.4.x مثبت كنسخة مخصصة ومدارة على محطة عمل Linux موثوقة، مع ترك حساب الخدمة وسجل التكوين الذي توفره الحزمة في مكانهما. تملك محطة العمل 10.77.0.2 على واجهة WireGuard الخاصة بها، وتصل إلى 10.60.0.20:443 عبر ذلك النفق، والاسم الصحيح للخدمة هو app.corp.example.

الخطوة 1: اربط المستمع بواجهة loopback فقط

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

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

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

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

الخطوة 2: اكتب قاعدتين لا واحدة

يمنح مرجع التكوين لنوعي القاعدة وظيفتين مختلفتين. تقبل قاعدة العميل اتصالا بالمستمع على loopback، ووجهتها هي عنوان المستمع نفسه. وتسمح قاعدة SOCKS بالاتصال التالي المطلوب إلى المضيف والمنفذ المعتمدين. تحجب الطلبات غير المطابقة افتراضيا، ولهذا تبدو القاعدة المفقودة مطابقة لمسار معطوب.

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

الخطوة 3: تحقق من المسار من المصدر الصحيح

external يختار عنوان مصدر صادر؛ وهو لا يثبت مسار WireGuard. بحث للقراءة فقط عن المصدر والوجهة في المثال:

ip -4 route get 10.60.0.20 from 10.77.0.2

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

قاوم إغراء إضافة مسار افتراضي حتى ينجح البحث. منفذ الوسيط موجود على محطة العمل هذه فقط؛ وتغيير المسار الافتراضي للمضيف لإنشائه يقلب التصميم كله.

الخطوة 4: اختبر بالهوية المقصودة

بعد أن يتحقق المالك من التكوين المثبت ويشغل النسخة عبر مدير الخدمة، يكون الطلب التوضيحي:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

مع socks5h، ينفذ Dante تحليل الوجهة، لكن Dante يعمل على محطة العمل هذه، لذا الإعداد لا يرسل DNS إلى الطرف البعيد من النفق من تلقاء نفسه. يجب أن يعيد المحلل المعتمد الذي يستخدمه Dante العنوان المسموح لذلك الاسم. قائمة عدم الوسيط الفارغة تمنع استثناء موروثا من تجاوز SOCKS بهدوء.

احتفظ بالتحقق من اسم مضيف HTTPS والشهادة في الاختبار، ثم افحص المستمع الفعلي وتأكد من نصفي العقد: نجاح الطلب المسموح وفشل وجهة مستبعدة. تحقق أيضا من بقاء أوامر التمرير غير المدعومة مرفوضة، لأن هذا المقتطف يسمح بأمر SOCKS CONNECT عبر TCP ولا شيء يشبه نفق UDP عاما أو نفقا لكامل الجهاز.

الخطوة 5: قرر ما يحدث عندما يسقط النفق

اختبر فقدان النفق وإعادة تشغيل النسخة قبل أن تسمي هذا إنتاجا. المشرف الذي يشغل Dante بعد WireGuard لا ينشئ توجيها مغلقا عند الفشل، ولا ينشئ DNS مغلقا عند الفشل أيضا؛ يجب فرض كليهما عبر مالك الشبكة. راقب ما يفعله التطبيق عندما يكون النفق معطلا: الخطأ النظيف نتيجة جيدة، والتراجع الصامت إلى محلل عام ليس كذلك.

نسق التحديثات إذا تغير عنوان النفق المربوط، لأن external مثبت عليه. عندما لا تعود الحاجة إلى الترتيب، أزل هذه النسخة وإعداد الوسيط في التطبيق معا، واترك مسار WireGuard لمن يملكه.