Squid প্যারেন্টের জন্য আলাদা লগইন তথ্য দিন

আপনার Squid পরিষেবায় ব্যবহারকারীর লগইন ও প্যারেন্টে Squid-এর লগইন আলাদা তথ্য ব্যবহার করে। প্যারেন্ট অন্য অপারেটরের হতে পারে বা আলাদা অ্যাকাউন্ট ডেটাবেস ব্যবহার করতে পারে। ক্লায়েন্টের পাসওয়ার্ড গ্রহণ করার অর্থ তা আপস্ট্রিমে পাঠাতে হবে এমন ধরে নেবেন না।

Squid 6.13 প্যারেন্টের সংজ্ঞায় স্থির লগইন যোগ করতে পারে:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly

ওপরের ঠিকানা ও পাসওয়ার্ড নথির উদাহরণ। ভুল করে দ্বিতীয় peer তৈরি না করে বর্তমান প্যারেন্ট সংজ্ঞায় লগইন যোগ করুন। কোন অনুরোধে এই প্যারেন্ট ব্যবহার করতেই হবে তা ঠিক করার আলাদা রাউটিং নীতি রাখুন।

অ্যাকাউন্টের পরিসর আলাদা রাখুন

ডাউনস্ট্রিম auth_param সেটিং আপনার Squid ইনস্ট্যান্সের ক্লায়েন্ট যাচাই করে। peer-এর login বিকল্প অন্য হপের জন্য লগইন তথ্য দেয়। একটি বদলালে অন্যটি নিজে থেকে আপডেট হয় না।

প্যারেন্টের নথিভুক্ত প্রমাণীকরণ চাহিদা মেনে চলুন। এই লাইন সংযোগভিত্তিক সব প্রমাণীকরণ পদ্ধতির সম্পূর্ণ কনফিগারেশন নয়। প্যারেন্ট NTLM বা Negotiate চাইলে এই ঘরের পাসওয়ার্ড বারবার না বদলে সমর্থিত peer বিন্যাস যাচাই করুন।

Squid-এ PASS ও PASSTHRU-এর মতো লগইন তথ্য পাঠানোর বিকল্পও আছে। এগুলোর অর্থ বিশেষ আপস্ট্রিম অ্যাকাউন্ট থেকে আলাদা এবং ক্লায়েন্টের প্রমাণীকরণ তথ্য peer-এর কাছে প্রকাশ করতে পারে। নকশায় আলাদা অ্যাকাউন্ট থাকলে সংক্ষিপ্ত পথ হিসেবে এগুলো বাছবেন না।

কনফিগারেশন রক্ষা করুন ও সঠিক হপ পরীক্ষা করুন

স্থির গোপন তথ্য কনফিগারেশনে থাকে। ফাইল ও ব্যাকআপের প্রবেশাধিকার সীমিত করুন এবং parser বা debug আউটপুট ভাগ করার আগে সংবেদনশীল তথ্য সরান। বিকল্পটির নিজস্ব escaping নিয়ম আছে: নথি URL escapes অনুমোদন করে এবং সরাসরি শতাংশ চিহ্ন দুবার লিখতে বলে।

ক্লায়েন্ট প্রমাণীকরণ সফল হলেও ফরোয়ার্ড অনুরোধ প্যারেন্টে ব্যর্থ হলে সেই আপস্ট্রিম আদানপ্রদান ও অ্যাকাউন্ট দেখুন। ক্লায়েন্ট–Squid ও Squid–প্যারেন্ট পরিবহন সুরক্ষাও আলাদা রাখুন; প্রথম সংযোগ এনক্রিপ্ট করলে দ্বিতীয়টি নিজে থেকে সুরক্ষিত হয় না।