GDOI: কেন কী সার্ভার আপনার ডেটা পথে নেই

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

দুই ধরনের নিরাপত্তা অবস্থা

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

স্ট্যান্ডার্ডটি কী-হালনাগাদ বার্তা সুরক্ষিত রাখা একটি পুনঃকী নিরাপত্তা সংযোগেরও নাম দেয়, যা সদস্যরা কীভাবে ট্রাফিক সুরক্ষিত রাখে তা বর্ণনা করা ডেটা-নিরাপত্তা সংযোগ থেকে আলাদা।

রেখাচিত্র নয়, বিনিময়গুলো অনুসরণ করুন

প্রতিটি বার্তা কীসের জন্য দেখুন। নিবন্ধন নিয়ন্ত্রককে বলে কোন সদস্য জিজ্ঞাসা করছে এবং অবস্থা তৈরি করে; পুনঃকী সদস্যদের বলে নীতি বা কী বদলেছে; এরপর সুরক্ষিত অ্যাপ্লিকেশন ট্রাফিক স্থাপিত ডেটা-নিরাপত্তা সংযোগ ব্যবহার করে সদস্যদের মধ্যে প্রবাহিত হয়। নিয়ন্ত্রকের ঠিকানা প্রথম দুটিতে থাকে এবং তৃতীয়টিতে একেবারেই না থাকতে পারে।

সেজন্যই ভৌত সন্নিধির ভিত্তিতে আঁকা ইন্টারফেস রেখাচিত্র এখানে বিভ্রান্তিকর। নিয়ন্ত্রকের ইন্টারফেস একটি নিয়ন্ত্রণ উৎস, প্রতিটি এনক্রিপ্টেড প্যাকেটের স্বয়ংক্রিয় পরবর্তী হপ নয়।

রাখার মতো তিনটি রেকর্ড

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

এগুলো কারো স্মৃতিতে নয়, কনফিগারেশনের পাশে রাখুন। সদস্যপদ পরিবর্তন এত কম হয় যে প্রয়োজন হওয়ার সময় যুক্তিটি সবসময়ই হারিয়ে গেছে।

ইন্টারফেস, সেবা সংযুক্তি, প্রক্রিয়াকরণ পথ

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

সেবা সংযুক্তি কীভাবে ট্রাফিক পায় তা প্ল্যাটফর্মের নিজস্ব ডকুমেন্টেশনে পড়ুন। প্রোটোকল মানসম্মত হলেও প্রক্রিয়াটি ভেন্ডর-নির্দিষ্ট।

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

নিয়ন্ত্রণ প্রাপ্যতা ও ডেটা ফরওয়ার্ডিং আলাদা যাচাই

সাধারণ পরিচালনা, সদস্যপদ পরিবর্তন এবং কী হালনাগাদের জন্য নিয়ন্ত্রকের নাগালের পরিকল্পনা করুন। ইতিমধ্যে স্থাপিত অবস্থায় সফল একটি অ্যাপ্লিকেশন বিনিময় প্রমাণ করে না যে পরের নিবন্ধন বা পুনঃকী সদস্যের কাছে পৌঁছাতে পারবে, আর এই ফাঁক সাধারণত কয়েক ঘণ্টা পরে এমন টানেল হিসেবে দেখা দেয় যা নতুন সদস্য নেওয়া বন্ধ করে দেয়। শুধু কাজ করা সেশন নয়, নতুন নিবন্ধন পরীক্ষা করুন।

তারপর নিয়ন্ত্রককে বাদ দিয়ে ফরওয়ার্ডিং আলাদাভাবে পরীক্ষা করুন। দুই যাচাই, দুই ফলাফল, আর কোন অর্ধেক ভাঙা তা নিয়ে অনেক ছোট তর্ক।