লিনাক্সের কোন প্যাকেট পথে প্রক্সি ব্যবহার কার্যকর করা উচিত?
নেটওয়ার্ক প্রক্সি কার্যকরকরণ নিয়ন্ত্রণ যে প্যাকেট পথ শাসন করার কথা সেখানেই রাখুন, শুধু গেটওয়ের সাথে সংযোগ ফিল্টার করার বদলে।
একটি লিনাক্স গেটওয়ে প্রক্সি প্রক্রিয়া চালাতে পারে এবং এর পাশ দিয়ে ট্রাফিকও রাউট করতে পারে। এগুলো একই প্যাকেট পথ নয়।
| সংযোগ | প্রাসঙ্গিক স্থানীয় ভূমিকা |
|---|---|
| ক্লায়েন্ট গেটওয়ের প্রক্সিতে পৌঁছায় | স্থানীয় হোস্টে সম্বোধন করা ট্রাফিক |
| ক্লায়েন্ট গেটওয়ে হয়ে অন্য হোস্টে পৌঁছায় | ফরওয়ার্ড করা ট্রাফিক |
| প্রক্সি একটি ওয়েবসাইট সংযোগ খোলে | স্থানীয় প্রক্রিয়া দ্বারা উৎপন্ন ট্রাফিক |
Netfilter ইনপুট, ফরওয়ার্ড ও আউটপুট পথ আলাদা করে। গেটওয়ের নিজস্ব প্রক্সি শ্রোতার অ্যাক্সেস নিয়ন্ত্রণকারী নিয়ম সেই মেশিন দিয়ে যাওয়া প্রতিটি রাউটেড সংযোগ স্বয়ংক্রিয়ভাবে সীমাবদ্ধ করে না।
কী কার্যকর করতে হবে তা নির্ধারণ করুন
ক্লায়েন্টদের যদি অনুমোদিত প্রক্সি ব্যবহার করতে হয়, তবে নীতিকে তাদের বিকল্প বহির্গামী পথও সম্বোধন করতে হবে, সাথে লক্ষ্যযুক্ত শ্রোতাকে অনুমতি দিতে হবে। পরিচিত প্রক্সি পোর্ট ব্যবহার করছে বলে যেকোনো দূরবর্তী সেবায় সংযোগ অনুমোদন করা, শুধু আপনার প্রক্সি এন্ডপয়েন্ট অনুমোদন করার সমান নয়।
প্রক্সির নিজের পরবর্তী অ্যাক্সেস আলাদা রাখুন। Squid-এর ক্ষেত্রে, বহির্গামী অনুমতি প্রয়োগের আগে স্থানীয় সকেট মালিকানা LAN ব্যবহারকারীর পরিচয় থেকে আলাদা করুন। প্রক্সি থেকে সব কার্যকর বহির্গামী সংযোগ অস্বীকার করলে প্রয়োজনীয় পথ অনুপলব্ধ হয়ে যাবে। ব্যবস্থাপনা ট্রাফিক, নাম সমাধান এবং সমর্থিত অ-ওয়েব ক্রিয়াকলাপও স্থাপনার নীতিতে সচেতনভাবে বিবেচনা করা দরকার।
প্রোটোকলের পরিধি গুরুত্বপূর্ণ। TCP নিয়ম নিজে থেকে UDP ট্রাফিক বর্ণনা করে না, QUIC সহ। ট্রাফিক বাধা দেওয়া আরেকটি নকশা; একটি স্পষ্ট HTTPS প্রক্সি ওয়েবসাইট সেশন ডিক্রিপ্ট না করেই CONNECT দিতে পারে।
নিয়মসমষ্টি সম্পাদনার আগে অভীষ্ট সংযোগগুলোর মানচিত্র তৈরি করুন। ব্রাউজার পছন্দ অংশগ্রহণকারী ক্লায়েন্টদের জন্য পথ বেছে নেয়। নেটওয়ার্ক কার্যকরকরণ নির্ধারণ করে অন্য কোন পথ সফল হতে পারে। কোনোটিই কেবল প্রক্সিতে একটি সফল লগইন থেকে অনুমান করা উচিত নয়।