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 سیشن اس پہلے پراکسی تبادلے کو محفوظ نہیں کرتا۔ کلائنٹ سے سرور تک مناسب طور پر محفوظ راستہ استعمال کریں۔

کامیاب کنفیگریشن جانچ نحو اور شناختوں کی تصدیق کرتی ہے، اکاؤنٹ ڈیٹابیس یا نیٹ ورک راستے کی نہیں۔ سرور لاگز میں دیکھیں کہ حقیقی آزمائش کس مرحلے پر رد ہوئی۔

متعلقہ مضامین