Mac VPN সার্টিফিকেট লগইন: পরিচয়, কী ব্যবহার নাকি গেটওয়ে বিশ্বাস?
সার্টিফিকেট লগইনের পেছনে তিনটি সিদ্ধান্ত থাকে: কোন পরিচয় বেছে নেওয়া হয়, VPN কম্পোনেন্ট তার কী ব্যবহার করতে পারে কি না, এবং গেটওয়েকে বিশ্বাস করা হয় কি না।
সার্টিফিকেট-ভিত্তিক VPN লগইন Mac-এর কাছে পাসওয়ার্ডের চেয়ে সংকীর্ণ কিছু চায়: এই নির্দিষ্ট প্রাইভেট কী-টি, এই এক্সিকিউশন প্রসঙ্গে, সেই গেটওয়ের কাছে একটি পরিচয় প্রমাণ করতে ব্যবহার করা। ব্যর্থ হলে বার্তাটি সাধারণত কেবল শেষ যে জিনিসটি ভুল হয়েছে তা বর্ণনা করে, যা খুব কমই কারণ। সিস্টেম যে ক্রমে তিনটি সিদ্ধান্ত নেয় সেই ক্রমে সেগুলো অনুসরণ করলে রোগনির্ণয় সৎ থাকে, এবং স্থানীয় অনুমতি সমস্যাকে চেইন-যাচাই ব্যর্থতা হিসেবে গণ্য করা থেকে বিরত রাখে।
Mac যে ক্রমে লগইন করে সেই ক্রমে অনুসরণ করুন
প্রথমে ক্লায়েন্ট একটি পরিচয় নির্বাচন করে: একটি ব্যবহারযোগ্য প্রাইভেট কী-সহ সার্টিফিকেট, যা সমর্থিত স্টোর বা ক্রেডেনশিয়াল প্রোভাইডারের মাধ্যমে পাওয়া যায়। তারপর VPN কম্পোনেন্ট সেই কী দিয়ে একটি ক্রিপ্টোগ্রাফিক অপারেশন করতে বলে, এবং স্থানীয় অনুমোদন মডেল উত্তর দেয়। দুটোই সফল হওয়ার পরেই দূরবর্তী হ্যান্ডশেক ঘটে, যেখানে Mac গেটওয়ে মূল্যায়ন করে এবং গেটওয়ে ক্লায়েন্টের প্রমাণ মূল্যায়ন করে।
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
টেবিলটি উপর থেকে নিচে পড়ুন এবং যে প্রথম সারি ব্যর্থ হয় সেখানেই থামুন। ব্যর্থতার নিচে থাকা সবকিছু অপ্রমাণিত, তাই «সার্টিফিকেট অবিশ্বস্ত» এত সাধারণ এবং এত অনির্ভরযোগ্য একটি উপসংহার।
স্থানীয় অনুমতি আসলে কী কভার করে
macOS কীচেইন মডেলে সুরক্ষিত আইটেমগুলো অপারেশন-নির্দিষ্ট অ্যাক্সেস নিয়ম এবং বিশ্বস্ত অ্যাপ্লিকেশনের একটি তালিকা বহন করে। প্রাইভেট কী দিয়ে সাইন করা সেই অপারেশনগুলোর একটি, এবং নিয়মগুলো তা সম্পাদনকারী এক্সিকিউটেবলের জন্য প্রযোজ্য, নথি হিসেবে সার্টিফিকেটের জন্য নয়। Apple-এর অ্যাক্সেস কন্ট্রোল রেফারেন্সও এই মডেল ও iCloud কীচেইন এবং অ্যাক্সেস-গ্রুপ ব্যবস্থার মধ্যে একটি সীমারেখা টানে, তাই একটির জন্য লেখা পরামর্শ অন্যটিতে প্রযোজ্য হয় না।
এর দুটি পরিণতি আছে। একটি তালিকায় পাবলিক সার্টিফিকেট দৃশ্যমান হওয়া প্রমাণ করে না যে VPN-এর ব্যাকগ্রাউন্ড কম্পোনেন্ট সেই কী-তে আদৌ পৌঁছাতে পারে। আর একটি ফ্রন্ট-এন্ড অ্যাপ্লিকেশনকে দেওয়া অনুমতি আলাদা হেল্পার বা নেটওয়ার্ক এক্সটেনশন সম্পর্কে কিছুই বলে না, কারণ সেগুলো ভিন্ন পরিচয়ের ভিন্ন কোড।
পুরোনো ক্লায়েন্ট থেকে এক্সিকিউটেবল পাথ কপি না করে প্রকৃত বাস্তবায়ন এবং তার সমর্থিত ক্রেডেনশিয়াল-শেয়ারিং ব্যবস্থা শনাক্ত করুন। সিস্টেম প্রথমেই কোন পরিচয় দেবে তা নিশ্চিত করুন:
security find-identity -v -p ssl-clientকোড errSecInteractionNotAllowed পড়া
সেই স্ট্যাটাসটি সিকিউরিটি সার্ভারের সঙ্গে অনুমোদিত নয় এমন ইন্টারঅ্যাকশন জানায়, এবং সার্টিফিকেট চেইন সম্পর্কে কিছুই বলে না। এটিকে যে অপারেশনটি তৈরি করেছে তার সঙ্গে পড়ুন: এমন প্রসঙ্গ থেকে জারি করা সাইনিং অনুরোধ, যা কোনো প্রম্পট দেখাতে পারে না, এভাবেই ব্যর্থ হবে, এমনকি যখন কী এবং সার্টিফিকেট দুটোই সম্পূর্ণ বৈধ। শুরু করার জায়গা হলো যে অপারেশনটি এটি লগ করেছে, সার্টিফিকেট স্টোর নয়। বিশ্বাসের অ্যাঙ্কর নিয়ে আপনার যে কোনো পরিবর্তন ত্রুটিটিকে ঠিক যেখানে ছিল সেখানেই রেখে দেবে।
তাই কোডটিকে এক্সিকিউশন প্রসঙ্গ ও অনুমোদন যাচাই করার কারণ হিসেবে দেখুন। এটিকে গেটওয়ের CA অবিশ্বস্ত হওয়ার প্রমাণ হিসেবে দেখা আপনাকে সমস্যার ভুল অর্ধেকের দিকে পাঠায়, এবং সেখানে করা পরিবর্তন ত্রুটিতে আদৌ প্রভাব ফেলবে না।
সংকীর্ণভাবে মেরামত করুন, বিস্তৃতভাবে নয়
সংযোগের মালিকের এনরোলমেন্ট বা ইমপোর্ট নির্দেশনা দিয়ে শুরু করুন। ক্লায়েন্ট সংস্করণ, প্রোফাইল পরিধি, নির্বাচিত পরিচয় এবং প্রথম প্রাসঙ্গিক স্থানীয় ত্রুটি লিপিবদ্ধ করুন, কারণ এই চারটি তথ্যই সাপোর্ট হ্যান্ডঅফের প্রয়োজন এবং পরবর্তী তুলনা এর উপর নির্ভর করে। একটি পরিচালিত প্রোফাইল বা হার্ডওয়্যার-সমর্থিত পরিচয়ের ক্ষেত্রে প্রশাসক বা প্রোভাইডারকে হ্যান্ডঅফ মেরামত করতে হতে পারে, এবং স্থানীয় ক্লিকের কোনো পরিমাণই তার বিকল্প নয়।
যেখানে পণ্যটি ব্যবহারকারীর অনুমোদন আশা করে, সেখানে কোন কম্পোনেন্ট চাইছে তা নিশ্চিত করুন এবং কেবল সেই অ্যাক্সেসই সমর্থিত প্রবাহের মাধ্যমে অনুমোদন করুন। যেখানে কম্পোনেন্টটি যে প্রসঙ্গে চলে সেখানে প্রম্পট তোলার কোনো উপায় নেই, সেখানে প্রভিশনিংকে বিক্রেতার নথিভুক্ত পথ অনুসরণ করতে হবে, অন্য কোনো টার্মিনাল উইন্ডো থেকে বের করে আনা ডায়ালগ নয়।
পুরোনো পরামর্শে দুটি পরিবর্তন একসঙ্গে বাঁধা হয়, এবং দুটোই অতি বিস্তৃত। প্রতিটি অ্যাপ্লিকেশনকে প্রাইভেট কী-তে অ্যাক্সেস দেওয়া স্থানীয় কী ব্যবহারকে প্রয়োজনের অনেক বাইরে প্রসারিত করে, আর সার্টিফিকেটকে সর্বদা বিশ্বস্ত করতে সেট করা মেশিনের সবকিছুর জন্য সার্টিফিকেট মূল্যায়ন বদলে দেয়। কোনোটিই «এই অনুমোদিত VPN বাস্তবায়ন, এই অভীষ্ট পরিচয় ব্যবহার করে» প্রকাশ করে না।
গেটওয়ে পড়ার আগে স্থানীয়ভাবে যাচাই করুন
মেরামতের পরে নিশ্চিত করুন যে স্থানীয় অপারেশনটি সফল হয়, অন্য দিক থেকে আসা কোনো উত্তর ব্যাখ্যা করার আগে। যদি সাইনিং এখন কাজ করে, তবে পরবর্তী নাম, চেইন বা ক্লায়েন্ট-ভর্তি প্রত্যাখ্যান একটি নতুন ফলাফল, পুনরাবৃত্তি নয়, এবং এটি ভিন্ন মালিকের ভিন্ন সিদ্ধান্তের অন্তর্গত।
উপকারী হ্যান্ডঅফ বলে দেয় তিনটি সিদ্ধান্তের কোনটি ব্যর্থ হয়েছে এবং সেখানেই থেমে যায়। এতে কখনো প্রাইভেট কী থাকে না, এবং পরিষ্কার স্লেট কাজে লাগবে এমন আশায় অসম্পর্কিত কীচেইন আইটেম রিসেট করা হয় না। এই দুটি অভ্যাস ঘটনার সময় নয়, তার আগেই গড়ে তুলুন, যখন একসঙ্গে সবকিছু চেষ্টা করার প্রলোভন সবচেয়ে প্রবল। «কীচেইন পুনর্নির্মাণ করেছি» বলা একটি টিকিট পরবর্তী পাঠককে মূল ত্রুটি সম্পর্কে প্রায় কিছুই বলে না।