দুটি ক্লায়েন্ট গ্রুপ, একটি সার্ভার: নীতিটি কোথায় প্রয়োগ করবেন
সাবনেট গ্রুপগুলোকে লেবেল করে, আলাদা করে না। কোন ফরওয়ার্ডিং পথ নিয়মটির মালিক তা ঠিক করুন, তারপর বাস্তবায়নকে যে ম্যাট্রিক্স মানতে হবে তা লিখুন।
দুটি ক্লায়েন্ট গ্রুপকে আলাদা সাবনেটে রাখা বিচ্ছিন্নতার মতো দেখায়, কিন্তু তা নয়। ঠিকানাগুলো বলে প্যাকেটটি কোথা থেকে আসছে বলে মনে হয়, আর অনুমতি হলো সিদ্ধান্ত যা যে ফরওয়ার্ড করে সে নেয়। এই প্রশ্নের উত্তর মাস্ক নয়, কনফিগারেশন দেয়, তাই কোনো নিয়ম লেখার আগে কোন উপাদান পিয়ার ট্রাফিক ফরওয়ার্ড করে তা ঠিক করুন।
সাবনেট একটি লেবেল, নিয়ম নয়
প্রতি গ্রুপে একটি পুল দিলে আপনি পড়ার উপযোগী ঠিকানা পান, আর কিছুই না। যে ক্লায়েন্ট অতিরিক্ত রুট গ্রহণ করে সে পৌঁছানোর ক্ষমতা পেয়েছে, আর পৌঁছানো অনুমতি নয়। কথা বলার অনুমতি ফরওয়ার্ডিং সিদ্ধান্তে থাকে, যা সার্ভার কীভাবে কনফিগার হয়েছে তার ওপর নির্ভর করে ডেমন বা কার্নেলে থাকতে পারে।
ঠিকানার মালিকানাই প্রিফিক্সকে গ্রুপ নির্বাচক হিসেবে ব্যবহারযোগ্য করে। প্রতিটি প্রমাণিত পরিচয়কে একটি পূর্বানুমেয় ঠিকানা বা পরিসরে মিলতে হয়, আর কয়েকটি ডিভাইস একটি ক্রেডেনশিয়াল ও একটি বরাদ্দ ভাগ করলেই সেই মিলন ব্যর্থ হয়। উৎস প্রিফিক্সের ওপর নির্ভর করার আগে পরিচয় ও সমবর্তিতা নিষ্পত্তি করুন, কারণ কোন মেশিন কল করছে তা অনুমান করা নীতি সবচেয়ে খারাপ মুহূর্তে ভুলটিকে অনুমতি দেয়।
পিয়ার ট্রাফিক বহনকারী পথটি বেছে নিন
যখন ডেমন নিজের প্রক্রিয়ার ভেতরে পিয়ার প্যাকেট ফরওয়ার্ড করে, সেই প্যাকেটগুলো কখনো হোস্টের ফরওয়ার্ডিং হুকে পৌঁছায় না, তাই কার্নেলের নিয়ম সেগুলো দেখতে পারে না। সেই অভ্যন্তরীণ ফরওয়ার্ডিং বন্ধ করুন, কার্নেলই ফরওয়ার্ডিং বিন্দু হয়ে যায়, যেখানে সাধারণ ফরওয়ার্ড নিয়ম প্রযোজ্য।
# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chainঅফলোড করা ডেটা চ্যানেল ও পণ্য-পরিচালিত সার্ভার নিজেদের প্রয়োগ মডেল প্রকাশ করে, তাই কমিউনিটি আচরণ ধরে নেওয়ার বদলে আপনি কোনটি চালাচ্ছেন তা নিশ্চিত করুন। যে ব্যর্থতা এড়ানো উচিত তা হলো এমন নিয়ম যা পর্যালোচনায় সঠিক দেখায় কিন্তু চলার সময় কখনো জিজ্ঞাসা করা হয় না।
নিয়ম লেখার আগে ম্যাট্রিক্স লিখুন
ছোট ম্যাট্রিক্স নিয়মের সেটের চেয়ে সহজে পর্যালোচনা করা যায়, আর এটি সেই চুক্তি যা বাস্তবায়নকে পূরণ করতে হবে: একই গ্রুপের পিয়ার অনুমোদিত, আড়াআড়ি গ্রুপের পিয়ার নিষিদ্ধ, দুই গ্রুপেরই একটি নামকরা ভাগ করা সেবায় অনুমতি, বাকি সব নিষিদ্ধ। ফায়ারওয়াল এডিটর খোলার আগে ওই চারটি লাইন লিখুন। যে পর্যালোচক নিয়মের সিনট্যাক্স পড়েন না তিনিও ম্যাট্রিক্স যাচাই করতে পারেন। তখন বাস্তবায়নকে কেবল লাইনগুলোর সঙ্গে মিলতে হবে।
| Source | Destination | Decision |
|---|---|---|
| Group A address | Another Group A address | Allow |
| Group A address | A Group B address | Deny |
| Either group | The shared internal service | Allow |
| Either group | Anything not listed | Deny |
লেখার সময় তিনটি গন্তব্য শ্রেণি আলাদা রাখুন। VPN হোস্টে একটি সেবা স্থানীয় ইনপুট, অন্য ক্লায়েন্ট পিয়ার ট্রানজিট, আর গেটওয়ের পেছনের মেশিন ভিন্ন ফরওয়ার্ড পথ। একটি উদার নিয়ম দুর্ঘটনাক্রমে তিনটিই দিতে পারে, আর এভাবেই গ্রুপ নীতি বাড়তি ধাপসহ সমতল নেটওয়ার্কে পরিণত হয়। প্রতিটি সারির পাশে শ্রেণি লিখুন যাতে উদ্দেশ্যটি পরের সম্পাদনাতেও টিকে থাকে।
নিয়মগুলো যেখানে টিকে থাকে সেখানে রাখুন
সিদ্ধান্তগুলো যেখানে ফায়ারওয়ালের বাকি অংশ রক্ষণাবেক্ষণ করা হয় সেখানেই যোগ করুন, এমন কোনো অনুমতিদায়ক নিয়মের আগে যা অন্যথায় সেগুলো গিলে ফেলত। নিয়মের ক্রম নীতির অংশ, আর বিস্তৃত অনুমতির পরে রাখা সঠিক নিয়ম কিছুই প্রয়োগ করে না। পরিবর্তনের আগে ও পরে নিয়মের নম্বর টুকে রাখুন। যে নীতি এডিটরে আছে কিন্তু চলমান নিয়মের সেটে নেই তা নিয়ন্ত্রণ নয়, পরিকল্পনা।
নীতি বদলালে ইতিমধ্যে থাকা ফ্লোগুলোর কী হবে তা ঠিক করুন, কারণ পরিবর্তনের আগে খোলা সেশন পরে চলতে থাকতে পারে। বহিষ্কৃত সদস্যকে সঙ্গে সঙ্গে প্রবেশ হারাতে হলে, সংযোগ নিজে থেকে বন্ধ হওয়ার অপেক্ষা না করে সেই অবস্থা বন্ধ করার উপায় নিয়মের সেটে থাকা দরকার।
যে ব্যবস্থা ফায়ারওয়ালের বাকি অংশের মালিক তার মাধ্যমেই নিয়মগুলো স্থায়ী করুন, আর সেগুলোর পাশে ম্যাট্রিক্স লিপিবদ্ধ করুন। অনুল্লিখিত নীতি পরের ঘটনার সময় স্মৃতি থেকে আবার উৎপন্ন হয়, সাধারণত তাড়াহুড়ো করা কারও দ্বারা।
উভয় দিক থেকে প্রমাণ করুন
প্রতিটি গ্রুপের একটি ক্লায়েন্ট থেকে একই গ্রুপের পৌঁছানো, গ্রুপের মধ্যে ব্যর্থতা ও ভাগ করা সেবা পরীক্ষা করুন। এক ক্লায়েন্ট থেকে একক পরীক্ষা ম্যাট্রিক্সের অর্ধেক প্রমাণ করে, আর যে অর্ধেক বাদ পড়ে তা সাধারণত ভুলটি। নিষেধের দিকটি দুবার পুনরাবৃত্তি করুন, কারণ ক্যাশে করা সেশন প্রয়োগের ভুল লুকাতে পারে। কোন জোড়া পরীক্ষা করেছেন তা লিখুন যাতে পরের ব্যক্তি তা পুনরাবৃত্তি না করে।
টানেল IPv6 বহন করলে সেই পরিবহনেই পরীক্ষাটি পুনরাবৃত্তি করুন, আর সাধারণ অ্যাপ্লিকেশন প্রমাণীকরণ চালু রাখুন। উৎস প্রিফিক্স কোনো অ্যাকাউন্ট নয়, তাই নেটওয়ার্ক নীতি পেরোনো মানে এই নয় যে সেবার কলকারীকে বিশ্বাস করা উচিত।