iOS আপনার strongSwan টানেল প্রত্যাখ্যান করেছে: IKE প্রস্তাবগুলো তুলনা করুন

সনদ বা ঠিকানায় কিছুই ব্যাখ্যা করে না কেন গত বছর strongSwan-এ সংযুক্ত একটি iPhone এ বছর ব্যর্থ হচ্ছে। ঠিকানা, পূর্বে বিনিময় করা কী বা ক্লায়েন্ট পরিচয়ের কিছুই বদলাতে হয়নি। যা সরে গেছে তা হলো ফোনের অন্তর্নির্মিত ক্লায়েন্ট যে রূপান্তরগুলোর বিষয়ে আলোচনা করতে প্রস্তুত তার তালিকা, আর সেই তালিকা সার্ভারেরটির সঙ্গে আর মিললে না পড়লেই আলোচনা শেষ হয়ে যায়, কারও পরিচয় যাচাই হওয়ার আগেই।

যে লগ লাইনটি সিদ্ধান্ত দেয়

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

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

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

ফোনে কী বদলাল

iOS-এর একটি সংস্করণ তার ক্লায়েন্ট যে অ্যালগরিদম ব্যবহার করতে রাজি তা ছেঁটে দিয়েছে। দুর্বল অখণ্ডতা হ্যাশ, ছোট Diffie-Hellman গ্রুপ, এবং পুরোনো অপশন আগে রাখা প্রস্তাবগুলো আর গ্রহণযোগ্য নয়।

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

একটি জোড়া যা এখনও আলোচনায় আসে

বর্তমান ফোনের জন্য একটি আধুনিক সংমিশ্রণই যথেষ্ট। যে জোড়াটি আলোচনায় আসে তা এমন:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

ike লাইনটি কী-বিনিময় চলার সময় ব্যবহৃত এনক্রিপশন, অখণ্ডতা ও Diffie-Hellman গ্রুপ বহন করে। esp লাইনটি কেবল ডেটা চ্যানেল ঢাকে, কারণ গ্রুপটি তার প্রয়োগের আগেই নির্ধারিত হয়ে গেছে। সংযোগটি রিলোড করুন বা ডেমনটি পুনরায় চালু করুন, তারপর ফোনটি আবার সংযুক্ত করুন। ওই গ্রুপ মানটি কেবল তখনই রাখুন যখন আপনি যে সব ক্লায়েন্টকে সেবা দেন তারা সবাই তা এখনও গ্রহণ করে, আর একটি পুরোনো পিয়ারের বেশি প্রয়োজন বলে সবার জন্য প্রস্তাবটি প্রশস্ত করবেন না।

সংশোধনের তিন জায়গা, একটি সাধারণত বন্ধ

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

আপনার নিয়ন্ত্রণের বাইরের কোনো ডিভাইস হালনাগাদ করা না গেলে দ্বিতীয় অপশনটি বেছে নিন। পুরোনো পিয়ারটি অবসরে পাঠাতে পারলে এবং একক নীতি বহন করতে চাইলে প্রথমটি নিন।

দুই ক্ষেত্রেই পছন্দটি কনফিগারেশনে দৃশ্যমান থাকে, আর সেটাই মূল কথা। নীরব ফলব্যাক যা পুরোনো রূপান্তরে নেমে আলোচনা করে, স্পষ্ট ব্লকের চেয়ে খারাপ, কারণ কোনো পর্যালোচনাই তা কখনও সামনে আনবে না।

প্রমাণ করুন, তারপর লিখে রাখুন

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

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