তিনটি ভিন্ন প্রশ্নের উত্তর দেয় OpenVPN প্রোফাইলের তিনটি ভিন্ন অংশ, এবং সেগুলো একসাথে মেলানোই মানুষকে চলমান একটি যাচাই বন্ধ করতে নিয়ে যায়। প্রতিপক্ষের সার্টিফিকেট কি আমার বিশ্বস্ত কর্তৃপক্ষ দ্বারা স্বাক্ষরিত? সেই সার্টিফিকেট কি TLS সার্ভার ভূমিকা ঘোষণা করে? এটি কি ঠিক সেই সার্ভার যা আমি পৌঁছাতে চেয়েছিলাম? remote-cert-tls server শুধুমাত্র মাঝের প্রশ্নটির উত্তর দেয়, এবং তা করে সার্টিফিকেটের ভেতরের এক্সটেনশন পড়ে।

তিনটি যাচাই যা মাথায় মেলা সহজ

বিশ্বাসের অ্যাঙ্কর বাস করে ca নির্দেশনায়। ভূমিকা যাচাই remote-cert-tls-এর অন্তর্গত। পরিচয় যাচাই verify-x509-name-এর অন্তর্গত, যখন কোনো প্রোফাইল এটি ব্যবহার করে, অথবা ডিপ্লয়মেন্ট যে নাম-যাচাই যোগ করে তার।

তারা ভিন্ন ভিন্ন ব্যর্থতা ঢেকে রাখে:

QuestionDirectiveFailure it catches
Who signed this?caCertificate from an unrelated authority
Is this a server?remote-cert-tlsClient certificate presented by a peer
Is this my server?verify-x509-nameAnother valid server from the same CA

একটি প্রোফাইলে তিনটিই থাকতে পারে এবং তবুও দুর্বল হতে পারে যদি CA খুব প্রশস্তভাবে ভাগ করা হয়, যা নির্দেশনার প্রশ্ন নয়, কী-ব্যবস্থাপনার প্রশ্ন।

ভূমিকা যাচাই কী পড়ে

নির্দেশনাটি একটি ম্যাক্রো। এটি কী-ব্যবহারের প্রয়োজনীয়তা এবং TLS ওয়েব সার্ভার ভূমিকা উল্লেখকারী বর্ধিত-কী-ব্যবহারের প্রয়োজনীয়তায় প্রসারিত হয়, তাই প্রতিপক্ষের সার্টিফিকেটকে অবশ্যই সেই উদ্দেশ্য ঘোষণা করতে হবে। ক্লায়েন্ট প্রমাণীকরণের জন্য ইস্যু করা সার্টিফিকেট এটি পূরণ করে না, এমনকি যখন একই কর্তৃপক্ষ দুটিই স্বাক্ষর করেছে।

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

নির্দেশনাটি নকশাগতভাবে অপ্রতিসম: ক্লায়েন্টরা remote-cert-tls server বহন করে, আর সার্ভাররা remote-cert-tls client বহন করে। এগুলো অদলবদল করুন এবং প্রতিটি সংযোগ ভূমিকা ত্রুটিতে ব্যর্থ হবে যা ভাঙা সার্টিফিকেটের মতো দেখায়।

পুরোনো প্রোফাইল কখনও একই উদ্দেশ্যে ns-cert-type ব্যবহার করে। বর্তমান ম্যানুয়াল পৃষ্ঠাগুলো সেই অপশনকে অতিক্রান্ত বলে গণ্য করে, তাই এখনও যার উপর নির্ভর করা প্রোফাইল ডিবাগ করার বদলে মাইগ্রেট করার যোগ্য।

কেন এটি নিষ্ক্রিয় করা সমাধানের মতো মনে হয়

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

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

নাম যাচাই একটি আলাদা নির্দেশনা

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

verify-x509-name সার্টিফিকেট সাবজেক্টকে আপনার কনফিগার করা মানের সাথে তুলনা করে, সঠিক সাবজেক্ট, প্রিফিক্স বা একক ফিল্ডের জন্য মিলানোর মোড সহ। যে ফিল্ডটি সত্যিই গেটওয়েকে শনাক্ত করে তা ব্যবহার করুন, এবং নাম বদলালে সেটি ইচ্ছাকৃতভাবে হালনাগাদ করার প্রত্যাশা করুন।

কোনো নির্দেশনাই ভালো কী-ব্যবস্থাপনার বিকল্প নয়। ক্লায়েন্ট কী ফাইলটি প্রোফাইলের সাথে এদিক-ওদিক কপি হলে, প্রতিপক্ষের পরিচয় বিতরণ তালিকার সমান শক্তিশালী।

প্রোফাইল সম্পাদনার আগে সার্টিফিকেট পরীক্ষা করুন

প্রতিপক্ষের সার্টিফিকেট এবং ক্লায়েন্ট লগ এই ক্রমে পড়ুন। সার্টিফিকেট বলে এটি কোন ভূমিকা ঘোষণা করে; লগ বলে কোন যাচাই এটি প্রত্যাখ্যান করেছে।

এই কমান্ডগুলো একটি বিস্তারিত সংযোগ থেকে ব্যবহার-এক্সটেনশন এবং যাচাইয়ের লাইন ছাপে:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

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

সম্পর্কিত নিবন্ধ