strongSwan: কী টাইপ, লোডার এবং ভুল backend

ফাইলের এক্সটেনশন কী অ্যালগরিদম চিহ্নিত করে না, এবং একটি .pem খোলসে RSA বা ECDSA উপাদান থাকতে পারে। PEM বলে কীভাবে বাইট মোড়ানো হয়, আর RSA ও ECDSA ভিন্ন অ্যালগরিদমের নাম, এবং PKCS12 ফাইল আরেকটি আলাদা জিনিস। strongSwan প্লাগইন ও একটি কনফিগারেশন backend-এর মাধ্যমে ক্রেডেনশিয়াল লোড করে, তাই একটি সার্টিফিকেট তালিকায় দেখা যেতে পারে অথচ প্রাইভেট কী কখনো ব্যবহারযোগ্য হয় না। যেকোনো গোপন তথ্য সম্পাদনার আগে সেই স্তরগুলো আলাদা করুন।

এনকোডিং, অ্যালগরিদম ও প্যাকেজিং তিনটি স্তর

একটি কী ফাইলের একটি এনকোডিং, একটি অ্যালগরিদম এবং প্রায়ই একটি কন্টেইনার থাকে। PEM পরিচিত base64 খোলস; DER তার বাইনারি সমতুল্য; PKCS12 একটি সার্টিফিকেটকে তার কী ও চেইনের সাথে একত্র করে। সার্টিফিকেট-চেইন ফাইল আরেকটি কন্টেইনার, এবং এতে সাধারণত কোনো প্রাইভেট কী থাকে না। এই লেবেলগুলোর কোনোটিই বলে না ভেতরের উপাদান RSA না ECDSA।

অ্যালগরিদম বস্তুটির নিজের থেকে পড়ুন। প্রোভাইডারের বিপণন নাম বা ফাইল এক্সটেনশন প্রমাণ নয়, কারণ একই ইস্যুকারী ভিন্ন কী টাইপ দিতে পারে।

লোডারকে দোষ দেওয়ার আগে পাবলিক কী তুলনা করুন

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

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

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

পুরোনো ipsec.secrets বা swanctl ক্রেডেনশিয়াল

strongSwan-এ সাধারণভাবে ব্যবহৃত দুটি ক্রেডেনশিয়াল পথ আছে। পুরোনো starter স্ট্যাক টাইপ-নির্দিষ্ট এন্ট্রি পড়ে ipsec.secrets. এবং প্রতিটি এন্ট্রিকে উপাদানের সঠিক টাইপ উল্লেখ করতে হবে। swanctl ও vici স্ট্যাক নিজের ক্রেডেনশিয়াল ডিরেক্টরি থেকে নিজের কনফিগারেশনের মাধ্যমে কী লোড করে। যে ফাইল চলমান backend পড়ে না সেটি সম্পাদনা করলে কিছুই বদলায় না।

: ECDSA "/etc/ipsec.d/private/server-key.pem"

কোন backend সত্যিই চলছে তা খুঁজুন, তারপর কী-টি সেই backend যেখানে খোঁজে সেখানে রাখুন। strongSwan 5.9 পুরোনো ম্যানুয়াল টাইপ-নির্দিষ্ট সিক্রেট এন্ট্রি সংজ্ঞায়িত করে, এবং এটি swanctl ডকুমেন্টেশন নয়। দুটিকে মেশালে এমন একটি ডেমন তৈরি হয় যা প্রশাসক যেটিকে প্রামাণিক মনে করেন সেই ফাইল উপেক্ষা করে। ত্রুটি না জানানো রিলোডের অর্থ কেবল কনফিগারেশন পার্স হয়েছে।

লোড ইভেন্ট ও প্রমাণীকরণের ফলাফল পড়ুন

নিয়ন্ত্রিত রিলোডের পরে নির্দিষ্ট কী-এর জন্য ডেমনটির নিজের লোডিং আউটপুট পড়ুন। স্ট্যাটাস ডাম্পে তালিকাভুক্ত একটি সার্টিফিকেট দেখায় না যে প্রাইভেট কী তার সাথে মিলেছে।

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