দুটি /24-এর বদলে একটি /23: আলোচনায় কী বদলায়

দুটি পাশাপাশি /24 পরিপাটিভাবে একটি /23-এ মিলে যায়, আর এই পরিপাটি গণিত মানুষকে বোঝায় যে পরিবর্তনটি নিছক সাজসজ্জা। এটি ঠিকানা নিয়ে গণিত, আর টানেল গুরুত্ব দেয় সিলেক্টরকে, যা নেটওয়ার্কের বর্ণনা নয় বরং আলোচনার একটি প্রস্তাব। ছোট লাইনটি একই ট্রাফিক সুরক্ষিত রাখতে পারে, পরিকল্পনার চেয়ে বেশি সুরক্ষিত করতে পারে, বা এর অর্ধেক ঢাকতে ব্যর্থ হতে পারে — নির্ভর করে দুই পক্ষ কী গ্রহণ করতে রাজি তার উপর। ইনস্টল করা ফলাফল পড়াই এই তিনটির মধ্যে কোনটি ঘটেছে তা জানার একমাত্র উপায়।

তিনটি তথ্য যা মানুষ একটিতে মিলিয়ে ফেলে

ঠিকানা-সমষ্টি বলে কোন হোস্টগুলো সুরক্ষিত করার কথা। দলবদ্ধকরণ বলে ওই ঠিকানাগুলো কীভাবে প্রস্তাব করা হয়: একটি সিলেক্টর বা কয়েকটি, একটি অ্যাসোসিয়েশনে বা তার বেশি। আলোচিত ফলাফল বলে দুই পক্ষ আসলে কী ইনস্টল করেছে, এবং তা প্রথম দুটির যেকোনোটির চেয়ে সংকীর্ণ হতে পারে।

পরিবর্তনের নথিতে সেগুলো আলাদাভাবে লিখুন। এক লাইন কনফিগারেশন প্রায়ই তিনটি ভিন্ন উত্তর লুকিয়ে রাখে। যে পর্যালোচক সেগুলো আলাদা করতে পারেন না, তিনিও পরিবর্তনটি অনুমোদন করতে পারেন না।

আপনার সমষ্টি নিয়ে উত্তরদাতা কী করতে পারে

একটি IKEv2 উত্তরদাতা প্রস্তাবিত সিলেক্টর জোড়াকে যে উপসেটটি সে গ্রহণ করতে রাজি তাতে সংকুচিত করতে পারে, এবং গ্রহণযোগ্য কিছু না থাকলে প্রস্তাবটি সরাসরি প্রত্যাখ্যান করতে পারে। সে এটাও জানাতে পারে যে অতিরিক্ত ট্রাফিকের জন্য এই অ্যাসোসিয়েশনে না মিলে অন্য একটি অ্যাসোসিয়েশন দরকার।

যে উত্তরদাতা কিছুই গ্রহণ করে না, সে বরং একটি ত্রুটি ফেরত দেয়, যা অন্তত বলে যে প্রস্তাবটি প্রত্যাখ্যাত হয়েছে, নীরবে সংকুচিত হয়নি।

এর অর্থ হলো সফল বিনিময় প্রমাণ করে দুই পক্ষ কোনো এক বিষয়ে সম্মত হয়েছে, আপনি যা তালিকাভুক্ত করেছেন তার সবটিতে নয়। প্রাথমিক সফলতার বার্তা ফলাফল পড়ার সূচনা-বিন্দু, কখনোই সিদ্ধান্ত নয়। গৃহীত উপসেটটি একটি /24-এর চেয়েও ছোট হতে পারে, যা ইনস্টল করা সমষ্টিকে প্রস্তাবের সঙ্গে একেবারেই অমিল দেখায়।

যেখানে সারসংক্ষেপ নীরবে একটি সীমানা মুছে দেয়

দুটি /24 ভিন্ন সেবা-নিয়ম রাখতে পারে: একটি শুধু একটি ব্যবস্থাপনা প্রোটোকল অনুমোদন করতে পারে, অন্যটি একটি সাধারণ অ্যাপ্লিকেশন। IP স্তরে দুই ঠিকানাই ঢাকা একটি সিলেক্টর ওই নিয়মগুলো রক্ষা করে না, আর সারসংক্ষেপ সীমানাটিকে টানেলের পেছনে যে ফিল্টারিং আছে তার মধ্যে সরিয়ে দেয়। একত্র করার আগে প্রতিটি সাবনেটের সেবা-নিয়ম তালিকাভুক্ত করুন, নইলে ওই তুলনা কখনো হয় না।

প্রোটোকল ও পোর্টের মান সিলেক্টরের অংশ, ঐচ্ছিক বাড়তি কিছু নয়। মূল নীতি যদি সেগুলো সীমিত করত, সমষ্টিকে একই সীমাবদ্ধতা বহন করতে হবে, নইলে পরিবর্তনটি রাউটিংয়ের পোশাক পরা একটি অনুমতি-পরিবর্তন। সীমাবদ্ধতাই যদি মূল নীতির উদ্দেশ্য হতো, সারসংক্ষেপের পরেও তা স্পষ্ট রাখুন এবং নথিতে তা বলুন।

প্রতিটি প্রিফিক্স ধরে ফলাফল পড়া

পরিবর্তনের পর কনফিগার করা নয়, ইনস্টল করা দেখুন। তারপর প্রতিটি প্রিফিক্স থেকে প্রতিটি দিকে একটি প্রবাহ তৈরি করুন, এবং যে অ্যাসোসিয়েশন এটি সামলায় তার কাউন্টার দেখুন। দুটি প্রিফিক্স একটি অ্যাসোসিয়েশনে ট্রাফিক তৈরি করলে ঠিক আছে; দুটি প্রিফিক্সের একটি কিছু না করলে সেটাই হলো প্রাপ্তি।

ব্যবহারকারীরা যে অ্যাপ্লিকেশন চালান, ঠিক সেইটাই ব্যবহার করুন। গেটওয়েতে উৎপন্ন একটি প্রোব তার পেছনের ক্লায়েন্টের চেয়ে ভিন্ন পথ পরীক্ষা করে, আর এই পার্থক্যই ঠিক সেখানে যেখানে সিলেক্টরের বাগ লুকিয়ে থাকে। যে প্রিফিক্স ব্যস্ত থাকার কথা সেখানে একটি অপরিবর্তিত কাউন্টার যেকোনো লগ-লাইনের চেয়ে শক্তিশালী প্রমাণ, কারণ এটি অনুপস্থিতি মাপে।

পরিবর্তনটিকে ফিরিয়ে আনার উপযোগী করা

মূল নীতিটি কনফিগারেশনে রাখুন যতক্ষণ না নতুনটি প্রতিটি প্রিফিক্স সমন্বয় থেকে পরীক্ষিত হয়, এবং প্রতিটি প্রবাহ কোন অ্যাসোসিয়েশনে গেল তা লিখে রাখুন। প্রস্তাব বদলালে যদি পক্ষ অ্যাসোসিয়েশন প্রতিস্থাপন করে, তবে রোলব্যাককে পুরোনো প্রস্তাব ফিরিয়ে আনতে হবে, শুধু পুরোনো ঠিকানা নয়।

উইন্ডো খোলার আগে অন্য প্রান্তের মালিকের সঙ্গে সমন্বয় করুন। এক পক্ষ যাকে স্পষ্ট মনে করে, তা অন্য পক্ষের কাছে অগ্রহণযোগ্য দলবদ্ধকরণ হতে পারে, আর পরিবর্তনের সময় তা আবিষ্কার করা ব্যয়বহুল। প্রস্তাবিত দলবদ্ধকরণ লিখিতভাবে একমত হোন, তারপর তা বিনিময় যা ইনস্টল করে তার সঙ্গে তুলনা করুন। সেই সম্মতিটি পরিবর্তনের টিকিটে রাখুন, এমন চ্যাট থ্রেডে নয় যা পরের সপ্তাহে হারিয়ে যায়।