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 کے بعد کے قواعد اور تصدیق کیش کا جائزہ لیں۔ پاس ورڈ بدلنا غلط پالیسی کے تحت شروع ہونے والی سروس کو درست نہیں کر سکتا۔ اسی طرح، ڈیمون کا آپریٹنگ سسٹم اکاؤنٹ بدلنا پراکسی صارف نہیں بناتا۔