সার্টিফিকেটের নামের অমিল বা মেয়াদোত্তীর্ণ: দুটিকে আলাদা করা

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

ত্রুটির লেখাই রোগনির্ণয়

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

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

যদি ব্যর্থতা প্রচেষ্টার মধ্যে বদলায়, আপনার তৃতীয় সম্ভাবনা আছে: একই নামের পেছনে একাধিক নোড।

নাম যাচাই: ক্লায়েন্ট কী তুলনা করে

ক্লায়েন্ট যে পরিচয়টি প্রত্যাশা করার জন্য কনফিগার করা হয়েছিল তা সার্টিফিকেটের নামগুলোর সঙ্গে তুলনা করে, যেগুলো subjectAltName এক্সটেনশনে থাকে। প্রোফাইলে কাঁচা IP, সার্টিফিকেটে তালিকাভুক্ত নয় এমন একটি উপনাম, বা এমন নাম যা কেবল একই সার্ভারে রিজলভ হয়, সবই এই যাচাইয়ে ব্যর্থ হয়। সঠিক মেশিনে পৌঁছানো আর সঠিক পরিচয় উপস্থাপন করা এক নয়।

আগের কোনো প্রচেষ্টার ফাইলের বদলে সার্ভারটি আসলে যে সার্টিফিকেট উপস্থাপন করে তা পরিদর্শন করুন। নিচের কমান্ডটি আপনার কনফিগার করা নামটি চায়, তাই উত্তরে প্রকৃত ক্লায়েন্ট যে সার্টিফিকেট দেখত তা অন্তর্ভুক্ত থাকে।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

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

মেয়াদোত্তীর্ণ: কার ঘড়ি পড়া হচ্ছে

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

কোনো সিদ্ধান্তে পৌঁছানোর আগে ক্লায়েন্টে সার্টিফিকেটের তারিখগুলো UTC-এর সঙ্গে তুলনা করুন:

openssl x509 -in cert.pem -noout -dates
date -u

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

একটি ঠিক করলে অন্যটি কেন প্রকাশ পায়

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

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

এই বিস্তারিতটাই অনিয়মিত টিকিটকে পুনরুৎপাদনযোগ্য একটিতে বদলে দেয়।

নতুন সংযোগ দিয়ে এটি প্রমাণ করুন

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

সঠিক ত্রুটি পর্যায় ও সার্টিফিকেটের বিবরণ টিকিটের সঙ্গে রাখুন।

এই রেকর্ডই পরের ব্যক্তিকে সার্টিফিকেটের সমস্যার জন্য অ্যাকাউন্টের পাসওয়ার্ড রিসেট করা থেকে বিরত রাখে। পরিচয় ও বৈধতা আলাদা প্রশ্ন, এবং দ্বিতীয়টি কীভাবে মূল্যায়ন করা হয় তার রেফারেন্স RFC 5280।