إضافة مصادقة باسم المستخدم إلى Dante

في Dante 1.4.4، تسمح قواعد العميل بالاتصال قبل تفاوض SOCKS، بينما تحدد قواعد SOCKS الطلبات المصادَق عليها التي يجوز لها المتابعة. وقد يظل الاتصال من مصدر مسموح مطالبًا باسم مستخدم في المرحلة الثانية.

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

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

استخدم حساب الخدمة الفعلي قليل الصلاحيات المثبّت لـDante. أنشئ أو اختر حساب عميل مخوّلًا ومتوافقًا مع خلفية مصادقة اسم المستخدم؛ هوية الخدمة وتسجيل دخول العميل دوران مختلفان.

أبقِ حدود الطلبات

بعد قاعدة العميل الضيقة الموجودة، اشترط الحساب على مسار SOCKS المسموح:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

العناوين واسم الحساب قيم توضيحية. يسمح هذا بمصدر واحد ووجهة واحدة وأمر واحد والمستخدم المصادَق عليه المحدد. لا تستبدل هذا الحد بمصادر غير مقيدة لمجرد إضافة كلمة مرور.

يجب أن تتفق إعدادات الطريقة العامة والخاصة بالقاعدة. ابحث عن قاعدة قديمة لا تسمح إلا بـnone بقيت من إعداد يعتمد على المصدر وحده. واحتفظ أيضًا بقيود المستمع والجدار الناري المقصودة.

اختبر التفاوض والوصول كلًا على حدة

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

التفاوض الفرعي لاسم المستخدم وكلمة المرور الذي يحدده RFC 1929 لا يشفّر كلمة المرور. ولا تحمي جلسة HTTPS لاحقة مع الوجهة تبادل البروكسي السابق. استخدم مسارًا محميًا على نحو مناسب بين العميل والخادم.

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