iPhone-এ IKEv2 সার্টিফিকেট সেটআপ: ম্যানুয়াল বনাম ব্যবস্থাপিত নথিভুক্তি

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

প্রথম ধাপ: নথিভুক্তির পথ বেছে নিন

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

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

দ্বিতীয় ধাপ: আপনার বেছে নেওয়া পথের জন্য অ্যালগরিদম বাছুন

ম্যানুয়ালি কনফিগার করা iPhone-এর জন্য strongSwan-এর iOS আন্তঃকার্যক্ষমতা নোট RSA সার্ভার সার্টিফিকেট সুপারিশ করে, কারণ ম্যানুয়াল ক্লায়েন্ট ECDSA সার্ভার সার্টিফিকেট নাও গ্রহণ করতে পারে; একই নোট macOS-কে আলাদাভাবে দেখে। এটিকে সমর্থিত ক্লায়েন্ট সেটের জন্য নির্দেশনা হিসেবে পড়ুন, Apple ডিভাইস সম্পর্কে চিরস্থায়ী নিয়ম হিসেবে নয়। ব্যবস্থাপিত প্রোফাইলে বেশি জায়গা আছে: পেলোড ও গেটওয়ে দুটোই সমর্থন করলে এটি স্পষ্টভাবে সার্টিফিকেটের ধরন বেছে নিতে পারে, ECDSA ক্লায়েন্ট পরিচয়সহ।

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

তৃতীয় ধাপ: প্রোফাইল ক্ষেত্রগুলোকে আলাদা জিনিস হিসেবে পড়ুন

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

Apple-এর IKEv2 পেলোড রেফারেন্স স্পষ্ট ECDSA রূপভেদসহ RSA-কে ডিফল্ট সার্টিফিকেট ধরন হিসেবে তালিকাভুক্ত করে এবং ইস্যুয়ার-নাম কী-কে নির্দিষ্ট প্রমাণীকরণ সেটিংসের সঙ্গে যুক্ত করে। কাজ করা কোনো স্থাপনা থেকে একটি কী নকল করার বদলে আপনার বেছে নেওয়া পদ্ধতির রেফারেন্স থেকে সেই সম্পর্কগুলো পড়ুন।

চতুর্থ ধাপ: গেটওয়ে পরিচয়কে তার সার্টিফিকেটের সঙ্গে মিলিয়ে নিন

স্পষ্ট গেটওয়ে নাম ব্যবহার করুন, যেমন vpn.example.com এবং সার্ভার সার্টিফিকেটে একটি মিলে যাওয়া সাবজেক্ট অল্টারনেটিভ নাম রাখুন। strongSwan-এর Apple নির্দেশনাও সার্ভার প্রমাণীকরণের বর্ধিত কী ব্যবহার প্রত্যাশা করে। RSA বা ECDSA বাছাই এগুলোর কিছুই বদলায় না: অ্যালগরিদম নামের অমিল, অনুপস্থিত EKU বা অসম্পূর্ণ চেইন ঠিক করতে পারে না।

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

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

পঞ্চম ধাপ: ক্লায়েন্ট পরিচয়কে CA বিশ্বাস থেকে আলাদা করুন

ক্লায়েন্ট সার্টিফিকেট এবং তার প্রাইভেট কী ফোন যে CA সার্টিফিকেটকে বিশ্বাস করে তার একই বস্তু নয়। PKCS#12 পরিচয়ের ভেতরে একটি CA সার্টিফিকেট বান্ডল করলে তা প্রতিটি সমর্থিত ডিভাইসে স্বয়ংক্রিয়ভাবে বিশ্বাসের অ্যাঙ্কর হিসেবে ইনস্টল হয় না, তাই বিশ্বাস বিতরণকে নিজস্ব যাচাইসহ আলাদা ধাপ হিসেবে ধরুন।

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

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