IKEv2 NO_PROPOSAL_CHOSEN: কোন ধাপে স্যুট প্রত্যাখ্যাত হয়েছে?

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

প্রথমে: কোন বিনিময় প্রত্যাখ্যাত হয়েছে

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

শুধু নোটিফিকেশন দিয়ে বিনিময় শনাক্ত হয় না। এর উপরের লাইনটি কোন SA নিয়ে আলোচনা হচ্ছে তা বলে, আর সেই নামটিই দেখার মতো প্রস্তাব-তালিকার দিকে ইঙ্গিত করে।

সম্পূর্ণ স্যুট তুলনা করুন, আলাদা কীওয়ার্ড নয়

একটি প্রস্তাব হলো একটি সমন্বয়: এনক্রিপশন অ্যালগরিদম, ইন্টিগ্রিটি বা AEAD, কী-এক্সচেঞ্জ গ্রুপ, এবং যেকোনো সিউডো-র‍্যান্ডম ফাংশন। শুধু এনক্রিপশনের নাম তুলনা করাই সাধারণ ভুল, কারণ দুই পিয়ার AES-256-এ একমত হয়ে SHA-1 বনাম SHA-256-এ দ্বিমত করতে পারে। ব্যর্থ ধাপে দেওয়া ও অনুমোদিত স্যুট পাশাপাশি লিখুন, তারপর খালি ছেদটি খুঁজুন।

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

এছাড়াও যাচাই করুন যে উভয় বাস্তবায়ন আপনার কনফিগার করা জিনিস সমর্থন করে। অন্য প্ল্যাটফর্ম থেকে নকল করা নাম দেখতে বাক্যতাত্ত্বিকভাবে পরিচিত লাগতে পারে অথচ প্লাগইন বা বাস্তবায়নটি পুরোপুরি অনুপস্থিত।

IKE স্যুট ও ESP স্যুট আলাদা বস্তু

IKE প্রস্তাব সম্পাদনা করলে প্রত্যাখ্যাত CHILD প্রস্তাব মেরামত হবে না, আর উল্টোটাও সত্য। strongSwan-এ এগুলো আলাদা সেটিং, মোটামুটি IKE SA-এর জন্য proposals = aes256-sha256-modp2048 এবং CHILD SA-এর জন্য আলাদা ESP তালিকা। যে তালিকা ব্যর্থ বিনিময়ের সাথে মেলে সেটিই বদলান, তারপর সমাধান কাজ করেছে ধরে না নিয়ে লগ আবার পড়ুন।

CHILD SA-এর জন্য প্রাসঙ্গিক সেটিং হলো ESP প্রস্তাব-তালিকা, IKE-এর নয়। IKE লাইনটি সেখানে কপি করলে এমন কনফিগারেশন তৈরি হয় যা পার্স হয় কিন্তু ভুল বস্তু নিয়ে আলোচনা করে।

চালু টানেল যা রিকি-তে ব্যর্থ হয়

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

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

ipsec statusall | grep -E "IKE:|ESP:"

একটি ছেদ বেছে নিন, তারপর দুই ধাপ নিশ্চিত করুন

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

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