0x নাকি 0s? ipsec.secrets-এ PSK ফরম্যাট বোঝা
একই শেয়ার্ড সিক্রেট উদ্ধৃতিচিহ্নে লেখা আক্ষরিক টেক্সট, 0x-এর পরে হেক্স, বা 0s-এর পরে Base64 হিসেবে লেখা যায়। ভুল প্রিফিক্স নেগোশিয়েশন নয়, অথেনটিকেশন ব্যর্থ করে।
একটি ক্লায়েন্ট শেয়ার্ড কী দিয়ে অথেনটিকেট হয় আর আরেকটি তা প্রত্যাখ্যান করে, অথচ আপনি যে অক্ষরগুলো পেস্ট করেছেন তা দুই পাশে একই দেখায়। সম্ভবত সেগুলো একই অক্ষর; পার্থক্যটা হলো ফাইলটি তাদের উপর কোন ডিকোডিং নিয়ম প্রয়োগ করে। উদ্ধৃতিচিহ্নে থাকা স্ট্রিং আক্ষরিকভাবে নেওয়া হয়, যে টোকেন 0x দিয়ে শুরু হয় তা হেক্সাডেসিমাল হিসেবে পড়া হয়, আর যে টোকেন 0s দিয়ে শুরু হয় তা Base64 হিসেবে পড়া হয়। এই তিনটি বানানের মধ্যে কেবল একটি আপনার উদ্দিষ্ট অর্থ বোঝায়, তাই সমাধান সাধারণত আরও ভালো পাসওয়ার্ড নয়, একটি রূপান্তর।
উপসর্গটি সাইফার নয়, এনকোডিংয়ের দিকে ইঙ্গিত করে
যখন দুই প্রান্ত ভিন্ন বাইট ধারণ করে, নেগোশিয়েশন তবুও সফল হয় আর প্রমাণটি পরে ব্যর্থ হয়. তখন লগ অ্যালগরিদম অমিলের বদলে ইন্টিগ্রিটি বা HMAC ব্যর্থতা রিপোর্ট করে, কারণ একটি প্রস্তাব বেছে নেওয়া হয়েছিল এবং অথেনটিকেশন ধাপটি মেলেনি। সেই লাইনটি কখনোই সিক্রেটের আকৃতির কথা বলে না।
ধাপটাই সূত্র। বেছে নেওয়া প্রস্তাবের পরে আসা ব্যর্থতার অর্থ দুই পাশ কী উপাদান ছাড়া সব বিষয়ে একমত হয়েছে, অন্যদিকে «কোনো প্রস্তাব বেছে নেওয়া হয়নি» নীতি বা সাইফার স্যুটের বিষয়। পাসওয়ার্ড ঠিক দেখালেও যে ইন্টিগ্রিটি যাচাই ব্যর্থ হয়, সেটিই এনকোডিং অমিলের দৃশ্যমান রূপ।
এক সিক্রেট, ফাইলটি তা পড়তে পারে তিনভাবে
চার বাইটের মান key1-এর জন্য হেক্সাডেসিমাল ও Base64 একই বাইটের দুইটি পুনঃএনকোডিং, আর কেবল শুরুর অক্ষরগুলোই পার্সারকে বলে তার হাতে কোনটি আছে। swanctl ক্রেডেনশিয়াল একই রীতি অনুসরণ করে, তাই দুই ইন্টারফেসের মধ্যে সরানো মানটি তার অর্থ ধরে রাখে কেবল যখন তার প্রিফিক্সও সঙ্গে যায়।
10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==
সেই ব্লকের দুইটি বিবরণই সবচেয়ে বেশি সময় নেয়। হেক্সাডেসিমাল অঙ্ক দুই রেজিস্টারই গ্রহণ করে, তাই 0x6b657931 এবং 0x6B657931 একই মান, কিন্তু বিজোড় সংখ্যক অক্ষর প্রত্যাখ্যাত না হয়ে নিঃশব্দে ভুলভাবে পড়া হয়, যা কাটার পরের প্রতিটি বাইট সরিয়ে দেয়। Base64 প্যাডিং মানটিরই অংশ, তাই শেষের = চিহ্নগুলো ছাড়া পেস্ট করা স্ট্রিং জোরে ব্যর্থ না হয়ে ভিন্ন বাইটে ডিকোড হয়।
যে প্রোফাইল একবার মানটি ডিকোড করেছে সে তা ইতিমধ্যে রূপান্তর করে ফেলেছে, তাই আবার ডিকোড করলে ভিন্ন বাইট ও ভুল পাসওয়ার্ডের মতো দেখতে অথেনটিকেশন ব্যর্থতা তৈরি হয়। অস্পষ্ট যেকোনো কিছুর জন্য উদ্ধৃতিচিহ্নই নিরাপদ দিক, কারণ বিষয়বস্তু আক্ষরিক, এমনকি তা এনকোডিং চিহ্ন দিয়ে শুরু হলেও।
Base64 টেক্সট কোথা থেকে আসে
প্রোফাইল এক্সপোর্ট ও ভেন্ডর পোর্টাল প্রায়ই কী-টি আগেই এনকোড করা অবস্থায় দেয়, সাধারণত এমন একটি ডেটা ফিল্ডে যা কখনো হাতে টাইপ করার জন্য বোঝানো হয়নি। হয় সেই মানটি খুলে ডিকোড করা টেক্সট উদ্ধৃতিচিহ্নে রাখুন, নয়তো চিহ্নটি সামনে রেখে এনকোডেড অবস্থাতেই ছেড়ে দিন। দুইটির অর্ধেক অর্ধেক করাই ভাঙার কারণ। দুই পথই কাজ করে কেবল যদি পুরো মানটি কপি থেকে টিকে থাকে।
দুই দিকই এক-একটি কমান্ড, আর যে সঠিক অপারেশনটি সংরক্ষিত মান তৈরি করেছিল তা টিকেটে রেখে দেওয়া মূল্যবান। এগুলো এই ক্রমে চালান:
printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64
এনকোডেড টেক্সটকে সাধারণ টেক্সটের মতো পেস্ট করাই ব্যয়বহুল ভুল। ফাইলটি অক্ষরগুলো ঠিক যেমন লেখা তেমনই হ্যাশ করে, উৎপন্ন কী সহকর্মীর গণনা করা কী-এর চেয়ে প্রায় এক-তৃতীয়াংশ লম্বা হয়, আর প্রতিটি চেষ্টা কোনো সতর্কবার্তা ছাড়াই একইভাবে ব্যর্থ হয়, কারণ পার্সার তাকে দেওয়া নিয়মটিই অনুসরণ করেছে।
প্রতিটি পিয়ার আসলে কোন বাইট ব্যবহার করে তা নিশ্চিত করুন
ত্রুটির স্ট্রিং থেকে কারণ অনুমান না করে আগে ডেমনটি সংযোগটিকে কীভাবে দেখছে তা পড়ুন, পরে অথেনটিকেশনের ফলাফল। সংরক্ষিত দৈর্ঘ্য মেলানো একটি দ্রুত যুক্তিসঙ্গততা যাচাই, কারণ এনকোডেড টেক্সট যে বাইটকে উপস্থাপন করে তার চেয়ে লম্বা। তারপর নিশ্চিত করুন কোন পরিচয় সারিটি মিলেছে, কারণ ভুল পিয়ারের অধীনে রাখা সঠিক সিক্রেট ঠিক ভুলটির মতোই ব্যর্থ হয়। সারির ক্রমই তা ঠিক করে: প্রথম মিলটিই জেতে, তাই উপরের দিকের একটি বিস্তৃত %any সারি আপনি এইমাত্র সম্পাদনা করা নির্দিষ্ট সারিটি নিঃশব্দে প্রতিস্থাপন করে।
ফাইল ঠিক হয়ে গেলে পুনরায় চালু না করে পুনরায় লোড করুন। ipsec rereadsecrets IKE ডেমনের কপি সতেজ করে, আর swanctl সেটআপ তার নিজস্ব কমান্ডে ক্রেডেনশিয়াল লোড করে। পুনরায় চালু করলে প্রতিষ্ঠিত প্রতিটি অ্যাসোসিয়েশন বাদ পড়ে এবং আপনি যে তুলনা করতে চাইছিলেন তা নষ্ট হয়।
এই যাচাইগুলোর কোনোটিই সিক্রেট প্রকাশ করতে বলে না। একটি দৈর্ঘ্য, একটি পরিচয় নির্বাচক আর একটি সারির অবস্থান এই ধরনের বেশিরভাগ ব্যর্থতা ব্যাখ্যা করে, কোনো হেক্স ডাম্পের দরকার হওয়ার আগেই।
ফলাফল লুকানো ছাড়াই ফাইলটি বদলান
ফাইলটি ডেমনের অ্যাকাউন্টে সীমিত রাখুন, আর জীবন্ত সিক্রেট টিকেট, চ্যাট ও স্ক্রিনশটের বাইরে রাখুন, কারণ পেস্ট করা কী একটি ফাঁস, কোনো ডায়াগনস্টিক নয়। এটি যে ঘটনাটি থেকে এসেছে তার চেয়েও বেশি দিন থাকে।
এমন ক্লায়েন্ট থেকে পরীক্ষা করুন যার কনফিগারেশন আপনার নিয়ন্ত্রণে, অথেনটিকেশন সফল হলো কি না নিশ্চিত করুন, তারপর টানেলটি ট্রাফিক বহন করছে কি না নিশ্চিত করুন। যে পুনঃলোড হ্যান্ডশেক ঠিক করে অথচ রাউটিং ভাঙা থাকে সেটি ভিন্ন সমস্যা, আর সিক্রেট নড়াচড়া বন্ধ করা মাত্রই তা দৃশ্যমান হয়।