اشتراط تسجيل الدخول في خدمتي 3proxy لكل من HTTP وSOCKS

تعريف مستخدم ليس كامل إعداد تسجيل الدخول في 3proxy. تحتاج الخدمة أيضًا إلى طريقة مصادقة وإلى قاعدة وصول تستخدمها. والترتيب مهم لأن إعدادات الخدمة تُطبَّق أثناء معالجة الإعدادات.

مثال محلي فقط لخدمتين هو:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

يشرح مرجع الإعدادات users وauth strong وأوامر الخدمة. يخزّن CL كلمة المرور في هذا المثال كنص صريح. احمِ الملف واختر صيغة مدعومة لتخزين بيانات الاعتماد تناسب النشر.

يحتاج العميل إلى تبادل تسجيل الدخول الصحيح

تتوقع خدمة HTTP مصادقة وكيل HTTP. وتحتاج خدمة SOCKS إلى عميل يدعم مصادقة SOCKS5 باسم المستخدم وكلمة المرور. ولا يستطيع عميل SOCKS4 تقديم هذا التبادل لمجرد أنه يصل إلى منفذ الاستماع نفسه.

كلمة strong اسم لوضع مصادقة، وليست ضمانًا لنقل مشفَّر. احمِ المسار من العميل إلى الوكيل عند الحاجة. ويبقى HTTPS إلى الوجهة والتشفير إلى الوكيل قرارين منفصلين.

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

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