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-এর পরের নিয়ম এবং প্রমাণীকরণ ক্যাশ পরীক্ষা করুন। পাসওয়ার্ড বদলালে ভুল নীতিতে চালু হওয়া সেবা ঠিক হয় না। একইভাবে ডেমনটির অপারেটিং সিস্টেম অ্যাকাউন্ট বদলালে প্রক্সি ব্যবহারকারী তৈরি হয় না।