Mac IKEv2 ECDSA: কোন ধরনের সার্টিফিকেট ক্লায়েন্টের?
Mac-এ IKEv2 সেটিংসের ECDSA256 স্থানীয় পরিচয় সার্টিফিকেট বোঝায়, গেটওয়ে বা ইস্যুয়ারের স্বাক্ষর নয়। বেছে নেওয়ার আগে প্রতিটি ভূমিকা পড়ুন।
macOS-এ IKEv2 ক্লায়েন্ট সেটিংসের ECDSA নির্বাচন একটি সংকীর্ণ প্রশ্নের উত্তর দেয়: কোন সার্টিফিকেট Mac-এর পরিচয় প্রমাণ করে। এটি গেটওয়ে সার্টিফিকেট, ক্লায়েন্ট সার্টিফিকেট ইস্যু করা স্বাক্ষর, বা টানেলের এনক্রিপশন প্রস্তাব বর্ণনা করে না। ওই চারটি ভূমিকাকে একটিমাত্র সামঞ্জস্যের প্রশ্ন হিসেবে দেখা হলো সেই কারণ যেখানে একটি সঠিক স্থানীয় সেটিংকে সার্ভার-সাইড অমিলের দায় দেওয়া হয়। সিদ্ধান্তটি ছোট, কিন্তু এটি নেওয়ার জন্য ব্যবহৃত প্রমাণ অবশ্যই নিখুঁত হতে হবে।
ফিল্ডটি একটি সার্টিফিকেটের নাম দেয়: স্থানীয় পরিচয়
Apple-এর Network Extension API ক্লায়েন্ট ক্রেডেনশিয়ালের জন্য একটি সার্টিফিকেট ধরন প্রকাশ করে, যার মধ্যে NEVPNIKEv2CertificateType.ECDSA256 রয়েছে, যা ECDSA p-256 সার্টিফিকেট ধরন হিসেবে নথিভুক্ত। প্রপার্টিটি identityReference বা identityData দিয়ে দেওয়া সার্টিফিকেটে প্রযোজ্য।
এর মানে সিদ্ধান্তটি Mac যে সার্টিফিকেট উপস্থাপন করে তার সঙ্গে তার সঙ্গে যাওয়া প্রাইভেট কী নিয়ে। ওই লিফ সার্টিফিকেটের পাবলিক কী-এর সঙ্গে মেলে এমন ধরন বেছে নিন এবং সমর্থিত প্রক্রিয়ার মাধ্যমে পরিচয় দিন। Mac-এর কাছে পরিচয়ের জন্য ব্যবহারযোগ্য প্রাইভেট কী না থাকলে ধরন বেছে নেওয়া সংযোগটি বাঁচাতে পারে না।
ম্যানেজড প্রোফাইল একই সিদ্ধান্ত নেয় IKEv2 পেলোডের CertificateType দিয়ে, সঙ্গে PayloadCertificateUUID-এর মতো সার্টিফিকেট রেফারেন্স। ওই ফিল্ডগুলোর পূর্বশর্ত ও লক্ষ্য OS সংস্করণের জন্য স্কিমা আছে; প্রোফাইলে কপি করা খালি ধরন-মান ইনস্টল করা যায় না, এবং সেটিংস উইন্ডো হয়তো প্রতিটি API অপশন দেখায় না। স্থাপনের আগে ওই সংস্করণের জন্য পেলোডের পূর্বশর্ত যাচাই করুন।
সার্টিফিকেটের লেবেল নয়, ভূমিকা দেখে সিদ্ধান্ত নিন
আপনি যে ফিল্ডটি পরিবর্তন করতে যাচ্ছেন তা পড়ুন এবং জিজ্ঞাসা করুন এটি কোন সার্টিফিকেটের দিকে ইঙ্গিত করে। সার্টিফিকেট ভিউয়ারের লেবেলগুলো সাবজেক্ট, ইস্যুয়ার ও স্বাক্ষর অ্যালগরিদম মিশিয়ে দেয়, আর এর মধ্যে কেবল একটি ক্লায়েন্ট পরিচয় নির্বাচনের সঙ্গে সম্পর্কিত।
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
সার্টিফিকেট ভিউয়ার CA থেকে ECDSA স্বাক্ষর দেখালে তা ইস্যুয়ারের সাইনিং কী বর্ণনা করে। ক্লায়েন্টের নিজের কী তখনও RSA হতে পারে, এবং ধরন-ফিল্ডটি স্বাক্ষরের লাইন নয়, ক্লায়েন্টের কী অনুসরণ করা উচিত। এই একক বিভ্রান্তিই অনেক "ECDSA কনফিগার করা আছে কিন্তু সংযোগ ব্যর্থ হয়" রিপোর্টের কারণ। কিছু পরিবর্তনের আগে লিফের কী-ধরন প্রোফাইলে নির্বাচিত ধরনের সঙ্গে মিলিয়ে নিন।
লিফ চিহ্নিত হয়ে গেলে সিদ্ধান্ত সরল হয়: p-256 ক্লায়েন্ট কী-এর জন্য ECDSA256, ভিন্ন কী-এর জন্য অন্য সমর্থিত ধরন। ক্লায়েন্ট সার্টিফিকেট ও তার কী না মিললে VPN প্রোফাইল বদলানোর আগে ওই জোড়া ঠিক করুন।
গেটওয়ে সার্টিফিকেট আলাদা সিদ্ধান্ত
গেটওয়ে নিজের সার্টিফিকেট উপস্থাপন করে এবং Mac তা ট্রাস্ট অ্যাঙ্কর ও প্রত্যাশিত নামের বিপরীতে যাচাই করে। ওই সার্টিফিকেট ECDSA, RSA বা অন্য কী-ধরন ব্যবহার করে কি না তা সার্ভারের বৈশিষ্ট্য, ক্লায়েন্ট পরিচয় সেটিংসের নয়।
ECDSA ক্লায়েন্ট সার্টিফিকেটের স্থানীয় সমর্থন প্রমাণ করে না যে প্রতিটি গেটওয়ে সার্টিফিকেট, কার্ভ বা সার্ভার প্রমাণীকরণ কনফিগারেশন আন্তঃকার্যকর হবে। সার্ভারের পরিচয়, তার চেইন এবং IKE প্রমাণীকরণ পদ্ধতিকে আলাদা ইনপুট হিসেবে যাচাই করুন এবং যে প্রোফাইল সত্যিই স্থাপন করা হবে তা দিয়ে পরীক্ষা করুন।
গেটওয়ে সার্টিফিকেট যদি সমস্যা হয়, লক্ষণ সাধারণত পরিচয় নির্বাচনে নয়, পিয়ার যাচাইয়ের সময় দেখা যায়. ক্লায়েন্টের ধরন বদলানোর আগে ব্যর্থতার ধাপটি পড়ুন, কারণ ট্রাস্ট ব্যর্থতা আর ক্লায়েন্ট-কী অমিলের সমাধান এক নয়।
ইস্যুয়ারের স্বাক্ষর ও কী-সম্মতি গ্রুপ ক্লায়েন্টের ধরন নয়
X.509 সাবজেক্টের পাবলিক কী ও ইস্যুয়ারের স্বাক্ষর আলাদা ফিল্ডে রাখে। সাবজেক্ট পাবলিক কী ইনফরমেশন সার্টিফিকেটের কী বর্ণনা করে; স্বাক্ষর অ্যালগরিদম CA-এর কী ও সাইনিং অপারেশন বর্ণনা করে। কেবল প্রথমটি সার্টিফিকেট-ধরন সেটিংসের সঙ্গে মেলে।
IKE ও Child SA প্রস্তাব আরেকটি অক্ষ। ECDSA সার্টিফিকেট ধরন ESP এনক্রিপশন নির্বাচন নয়, এবং কী-সম্মতি গ্রুপ বদলালে সার্টিফিকেট ধরন নির্বাচিত হয় না। একটি প্রোফাইলে বৈধ প্রস্তাব ও ভুল পরিচয়-ধরন থাকতে পারে, বা সঠিক পরিচয়-ধরন ও পিয়ার যে প্রস্তাব প্রত্যাখ্যান করে তা থাকতে পারে।
পরিবর্তন রেকর্ডে তিনটি লাইন আলাদা রাখুন: পরিচয় সার্টিফিকেট ও কী, গেটওয়ে ট্রাস্ট ইনপুট, এবং প্রস্তাবের অ্যালগরিদম। এগুলোকে একটিমাত্র "ক্রিপ্টো সেটিংস" নোটে মিলিয়ে দিলে পরের ব্যর্থতার কারণ নির্ধারণ অসম্ভব হয়ে পড়ে।
আপনি যে ফিল্ডগুলো কনফিগার করেছেন সেগুলো দিয়ে সিদ্ধান্ত যাচাই করুন
প্রোফাইল সত্যিই যে পরিচয়ের রেফারেন্স দেয় তা যাচাই করুন, তারপর নিশ্চিত করুন যে ওই রেফারেন্সের সার্টিফিকেটে প্রত্যাশিত পাবলিক কী ও ব্যবহারযোগ্য প্রাইভেট কী আছে। UI-তে দেখানো ধরন, রেফারেন্স করা সার্টিফিকেট এবং ডিভাইসের কী—তিনটির মিল থাকতে হবে।
এরপর গেটওয়ে ইনপুট নিশ্চিত করুন: প্রত্যাশিত সার্ভার নাম, ট্রাস্ট অ্যাঙ্কর এবং IKE প্রমাণীকরণ পদ্ধতি। শেষে সংযোগ করুন এবং দেখুন হ্যান্ডশেক কোথায় থামে। পরিচয় বিনিময়ের আগে ব্যর্থতা এই সেটিংস থেকে দূরে ইঙ্গিত করে; পিয়ার যাচাইয়ে ব্যর্থতা গেটওয়ে দিকের দিকে ইঙ্গিত করে।
নির্বাচিত ধরন, পরিচয় রেফারেন্স এবং গেটওয়ে সার্টিফিকেটের সাবজেক্ট স্থাপন নোটে লিখে রাখুন। পরের প্রোফাইল আপডেট যেকোনোটি বদলাতে পারে, আর তিনটি নামকরণ করা মান সেটিংস প্যানেলের স্ক্রিনশটের চেয়ে দ্রুত তুলনা করা যায়।