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 ৰ পিছৰ নিয়ম আৰু প্ৰমাণীকৰণ কেশ্ব পৰীক্ষা কৰক। পাছৱৰ্ড সলনি কৰিলে ভুল নীতিত আৰম্ভ হোৱা সেৱা ঠিক কৰিব নোৱাৰে। একেদৰে ডেমনৰ অপাৰেটিং চিস্টেম একাউণ্ট সলনি কৰিলে প্ৰক্সি ব্যৱহাৰকাৰী সৃষ্টি নহয়।