Nebula সার্টিফিকেট রিলোড IP পরিবর্তন করেনি: কারণ এখানে
রিলোড হোস্ট ক্রেডেনশিয়াল আবার পড়ে কেবল তখনই, যখন ওভারলে ঠিকানা একই থাকে। ঠিকানা বদলানো মানে পুনরায় চালু এবং নেটওয়ার্ক পরিবর্তন, পুনরায় চেষ্টা নয়।
আপনি ভিন্ন ওভারলে ঠিকানা দিয়ে নতুন হোস্ট সার্টিফিকেট ইস্যু করেন, তা পুরোনো ফাইলের উপরে কপি করেন, রিলোড পাঠান, আর হোস্ট আগের ঠিকানাতেই উত্তর দিতে থাকে। প্রতিক্রিয়া হলো ধরে নেওয়া যে রিলোড ব্যর্থ হয়েছে বা ভুল ফাইল পড়া হয়েছে। সাধারণত কোনোটিই ঘটেনি: চলমান প্রক্রিয়াটি ইচ্ছাকৃতভাবে সেই পরিচয়ই ধরে রেখেছে যা আগে থেকেই ছিল, কারণ প্রতিস্থাপন এমন কিছু বদলেছে যা রিলোড প্রয়োগ করতে পারে না।
Nebula-র PKI রিলোড সমর্থন ঠিক এই সীমারেখাসহ নথিভুক্ত, এবং একই ডকুমেন্টেশন যখন দেখায় যে অন্য পরিবর্তনের জন্য রিলোড কাজ করে, তখন এটি সহজেই চোখ এড়িয়ে যায়।
রিলোড আসলে কী আবার পড়ে
হোস্ট সার্টিফিকেট কেবল SSH কী-র মতো ক্রেডেনশিয়াল নয়। এটি ওভারলে ঠিকানা, হোস্ট নাম, গ্রুপ সদস্যতা এবং বৈধতার সময়সীমা বহন করে, আর এগুলো সবই CA-র স্বাক্ষর দিয়ে একসূত্রে বাঁধা। ডিমন সেই স্বাক্ষরিত বিষয়বস্তু ব্যবহার করে নির্ধারণ করে সে নিজেকে কীভাবে উপস্থাপন করবে এবং তার উপর কোন নিয়ম প্রযোজ্য হবে।
রিলোড প্রক্রিয়াটিকে তার টানেল না ফেলেই নবায়িত ক্রেডেনশিয়াল নিতে দেয়, যা নিয়মিত রোটেশনের জন্য মূল্যবান: একই ঠিকানা, একই নাম, একই গ্রুপ, পরে মেয়াদ শেষ। সীমাবদ্ধতা হলো পরিচয় একই থাকতে হবে। ওভারলে ঠিকানা বদলালে রিলোড পথটি তা প্রয়োগ করতে পারে না, কারণ ঠিকানাটি চলমান ইনস্ট্যান্স ইতিমধ্যে যে বিষয়ে প্রতিশ্রুতিবদ্ধ হয়েছে তার অংশ।
তাই আপনি যে আচরণ দেখেছেন তা নথিভুক্ত সীমাবদ্ধতার নিজের কাজ, নীরব ব্যর্থতা নয়। ডিস্কের ফাইলটি নতুন; মেমোরির পরিচয়টি পুরোনো; পুনরায় চালু ছাড়া সেই পার্থক্য মেটানোর কোনো সমর্থিত উপায় প্রক্রিয়াটির নেই।
ঠিকানা, নাম ও গ্রুপ একই পরিচয়
সার্টিফিকেটকে আলাদা আলাদা সম্পাদনযোগ্য ক্ষেত্রের সমষ্টি না ভেবে একক রেকর্ড ভাবা সহায়ক। ঠিকানা সরানো পছন্দ বদলানোর মতো নয়, কারণ ঠিকানাটি অন্য হোস্টের পিয়ার কনফিগারেশনে, সার্ভিস বাইন্ডিংয়ে এবং পরিচয়ের বিরুদ্ধে লেখা নীতিমালায় দেখা যায়।
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
গ্রুপ আলাদা লাইনের দাবিদার, কারণ তারা একই বিভ্রান্তির আরও নীরব সংস্করণ ঘটায়। যে হোস্ট তার ঠিকানা রেখে গ্রুপ বদলায় সে পুনরায় চালুর পর ভিন্ন সার্ভিসে পৌঁছাতে পারে, আর কেবল পুরোনো ঠিকানায় পিং করা পরীক্ষা সম্পূর্ণ সুস্থ দেখাবে, অথচ নিচে অ্যাক্সেস সিদ্ধান্ত বদলে গেছে। কেবল পৌঁছানো নয়, নিয়মে আবদ্ধ একটি সার্ভিস যাচাই করুন। টানেল নিশ্চিত করা আর নীতিমালা নিশ্চিত করার পার্থক্য এটাই।
লোড করা সার্টিফিকেটের সঙ্গে প্রতিস্থাপনের তুলনা করুন
ডিমন ফাইলটি উপেক্ষা করেছে ধরে নেওয়ার আগে দুটোই পড়ুন। যে সার্টিফিকেট লোড করতে চান তা প্রিন্ট করুন এবং যে ক্ষেত্রগুলো বদলেছেন বলে মনে করেন তা নিশ্চিত করুন, তারপর নিশ্চিত করুন যে চলমান কনফিগারেশন ওই পথেই নির্দেশ করে, অন্য কোথাও রাখা কপিতে নয়।
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)প্রক্রিয়ার আর্গুমেন্ট মানুষ যতটা ভাবে তার চেয়ে বেশি গুরুত্বপূর্ণ। যে ইউনিট -config /etc/nebula/config.yml পাঠায় সে ওই ফাইলের pki.cert এন্ট্রি পড়ে, আর স্টেজিং ডিরেক্টরিতে ইনস্টল করা সার্টিফিকেট কিছুই প্রভাবিত করে না। আপনি যে ডকুমেন্টেশন অনুসরণ করেছেন তার পথ নয়, চলমান কমান্ড লাইনের পথ যাচাই করুন। দুটি ভিন্ন হলে সার্টিফিকেট একেবারে না ছুঁয়েই আপনি সমস্যা খুঁজে পেয়েছেন।
নতুন সার্টিফিকেটের ঠিকানা ভিন্ন হলে এবং প্রক্রিয়া পুরোনোটি ধরে রাখলে, এখন আপনার কাছে রহস্য নয়, ব্যাখ্যা আছে। সম্ভব হলে এটি পুনরায় চালু করুন এবং ঠিকানা পরিবর্তনকে দুর্ঘটনাজনিত নয়, পরিকল্পিত নেটওয়ার্ক পরিবর্তন হিসেবে গণ্য করুন।
ঠিকানা পরিবর্তন মানেই নেটওয়ার্ক পরিবর্তন
মেশিন সরানোর পরিকল্পনা যেভাবে করতেন, সেভাবেই পরিকল্পনা করুন। অন্য হোস্ট তাদের কনফিগারেশনে পুরোনো ঠিকানা পিন করে থাকতে পারে, সার্ভিসগুলো স্পষ্টভাবে সেটিতেই বাইন্ড হতে পারে, আর ফায়ারওয়াল নিয়ম সেটির বিরুদ্ধে লেখা থাকতে পারে। সার্টিফিকেট বদলালে হোস্ট সরে যায়, আর হোস্ট সরলে অন্য জায়গার ধরে নেওয়া ভিত্তিহীন হয়ে পড়ে।
এটি করার সময় দ্বিতীয় একটি ব্যবস্থাপনা পথ খোলা রাখুন, কারণ আপনি যেটি বাধাগ্রস্ত করছেন সেটিই ওভারলে সংযোগ হতে পারে। যে টানেলটি ভাঙতে যাচ্ছেন তার ভেতর দিয়েই এটি করা পাঁচ মিনিটের পরিবর্তনকে সাইট ভিজিটে পরিণত করার চিরাচরিত উপায়।
পুনরায় চালু গ্রহণযোগ্য কিনা তা নির্ভর করে হোস্টটি কী করছে তার উপর, এবং এটি প্রযুক্তিগত নয়, সময়সূচির প্রশ্ন। যা ঐচ্ছিক নয় তা হলো রিলোড পঞ্চমবার পাঠানোর বদলে পুনরায় চালুর প্রয়োজনীয়তা স্বীকার করা।
পুরোনো ক্রেডেনশিয়াল আলাদাভাবে অবসর দিন
একটি মেশিনে প্রতিস্থাপন ইনস্টল করলে প্রতিটি পিয়ার এখনো সেই ক্রেডেনশিয়ালেই ভরসা করে যা সে আগে থেকেই জানে। পরিবর্তনের কারণ যদি আপস হয়ে থাকে, তবে পুরোনো পরিচয়টি বিশ্বাস বা ব্লকলিস্ট পদ্ধতির মাধ্যমে অবসর দিতে হবে, যাতে পিয়াররা সত্যিই তা প্রত্যাখ্যান করে।
এটি নিজস্ব যাচাইসহ আলাদা ধাপ: নতুন ফাইল কাজটি করেছে ধরে নেওয়ার বদলে অন্য হোস্ট থেকে নিশ্চিত করুন যে পুরোনো পরিচয় আর কাজ করে না। Nebula PKI কনফিগারেশন ডকুমেন্টেশন রিলোডযোগ্য সেটিংস এবং এখানে বর্ণিত ঠিকানার সীমাবদ্ধতা কভার করে, এবং উৎপাদনসংক্রান্ত কিছু রোটেট করার আগে এটি সম্পূর্ণ পড়া উচিত।