Nebula ব্লকলিস্ট: এটি বিতরণ করুন, লাইটহাউস তা করবে না

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

ব্লকলিস্ট এন্ট্রি আসলে কী করে

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

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

সার্টিফিকেট চিহ্নিত করুন, ডিভাইস নয়

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

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

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

অন্য যেকোনো কনফিগারেশনের মতো এটি বিতরণ করুন

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

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

ব্লকলিস্ট না কর্তৃপক্ষ ঘোরানো

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

হারানো ল্যাপটপ ব্লকলিস্টের দাবি করে, কারণ প্রভাবের পরিধি একটি পরিচয় এবং ভুল ফিঙ্গারপ্রিন্ট ব্লক করলে পরিবর্তনটি প্রত্যাবর্তনযোগ্য। ফাঁস হওয়া কর্তৃপক্ষের চাবি ঘোরানোর দাবি করে, কারণ যে সার্টিফিকেট এখনও জারি হয়নি সেগুলিতে ব্লকলিস্ট সাহায্য করতে পারে না। এই দুই প্রান্তের মধ্যে জিজ্ঞাসা করুন, প্রকাশিত ক্রেডেনশিয়াল অন্য কিছু স্বাক্ষর করতে পারত কি না, কারণ একটি কর্তৃপক্ষ একাধিক হোস্টের বেশি।

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

প্রত্যাখ্যান ও বাকিটা যাচাই করুন

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

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