OpenVPN-এ কিছুই সার্টিফিকেটকে Easy-RSA থেকে আসতে বাধ্য করে না, এবং যে ফ্লিটের ইতিমধ্যেই সাংগঠনিক PKI আছে তাদের সাধারণত দ্বিতীয়টি তৈরি করা উচিত নয়। আসল কাজটি টুল বেছে নেওয়া নয়, বরং ঠিক করা যে ইস্যু করা পরিচয়গুলোর অর্থ কী, টানেল কোন পিয়ারদের গ্রহণ করে, এবং নবায়ন ও প্রত্যাহার কীভাবে যাচাইকারীর কাছে পৌঁছায়। নিচের পাঁচটি ধাপ ক্রমানুসারে সম্পন্ন করুন, কারণ পরের ধাপ প্রথম ধাপে নেওয়া ভূমিকার সিদ্ধান্ত মেরামত করতে পারে না।

একটি অভিন্ন পরিচয়ের বদলে দুটি ভূমিকা ইস্যু করুন

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

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

প্রতিটি পাশে বিশ্বাসের ইনপুট সংযুক্ত করুন

ক্লায়েন্ট ও সার্ভারের প্রত্যেকের বিশ্বাসের অ্যাঙ্কর, নিজের পরিচয় এবং স্পষ্ট ভূমিকা প্রত্যাশা দরকার। তিনটিই উল্লেখ করা একটি ক্লায়েন্ট ফ্র্যাগমেন্ট এভাবে দেখায়।

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

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

বিশ্বাস না বাড়িয়ে মধ্যবর্তী সার্টিফিকেট সরবরাহ করুন

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

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

PKI দলের সাথে সম্মত হোন কীভাবে নবায়ন ও প্রত্যাহার VPN যাচাইকারীদের কাছে পৌঁছায়, কোন ইস্যুয়ারগুলি গুরুত্বপূর্ণ এবং কে তালিকা প্রকাশ করে তা সহ। একটি সার্টিফিকেটে এমবেড করা CRL বিতরণ পয়েন্ট একটি নির্দেশ, কিছু এটি এনেছে তার প্রমাণ নয়।

প্রত্যাহার আসলে কীভাবে আসে তা ঠিক করুন

crl-verify যাচাইকারীকে একটি ফাইল বা এন্ডপয়েন্ট পরামর্শ করতে দেয়, এবং সেই ব্যবস্থার একজন মালিক ও একটি রিফ্রেশ পথ দরকার। স্থাপনার সময় একবার কপি করা তালিকা প্রথমবার সার্টিফিকেট প্রত্যাহার হলে নীরবে আপনাকে রক্ষা করা বন্ধ করে দেয়।

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

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

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

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

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