পাসওয়ার্ড-শুধু OpenVPN প্রোফাইলে কোন CA ফাইল যায়?

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

ক্রমটি গুরুত্বপূর্ণ: শেষ দুটি প্রশ্নের অর্থ হয় কেবল তখনই, যখন আপনি জানেন কোন উপাদান থাকার কথা।

প্রোফাইল আগে থেকেই কী বহন করে তা দিয়ে শুরু করুন

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

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

প্রোফাইল যে ফাইলগুলোর প্রতি নির্দেশ করে সেগুলোর জন্য দেওয়া প্যাকেজটি পরীক্ষা করুন: একটি CA সার্টিফিকেট, মাঝে মাঝে আলাদা ক্লায়েন্ট সার্টিফিকেট ও কী, এবং সম্ভবত একটি tls-auth বা tls-crypt ফাইল। যে প্রোফাইল চারটি ফাইলের প্রতি নির্দেশ করে অথচ দুটি নিয়ে আসে সেটি অসম্পূর্ণ, এবং ক্ষেত্র দেখানোর কোনো পরিমাণই তা সারায় না। আপনার কাছে যে সার্টিফিকেট আছে তা প্রতিস্থাপন না করে অপারেটরের কাছে অনুপস্থিত অংশটি চান।

চার ধরনের উপাদান আলাদা করুন

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

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

ক্লায়েন্টকে বিশ্বাস ফাইলের দিকে নির্দেশ করুন

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

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

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

একই ত্রুটি নয়, পরের ত্রুটিটি পড়ুন

সঠিক CA দেওয়ার উদ্দেশ্য ত্রুটিটি বদলানো, সেটি অদৃশ্য করা নয়। CA লোড হওয়ার পরে সার্ভার-পরিচয় ব্যর্থতা মানে সার্টিফিকেটটি প্রত্যাশিত নাম বা remote-cert-tls প্রত্যাশার সাথে মেলেনি, যা পাসওয়ার্ড প্রত্যাখ্যানের চেয়ে ভিন্ন মেরামত। পাসওয়ার্ড প্রত্যাখ্যান মানে TLS স্তর সফল হয়েছে এবং শংসাপত্র ভুল। প্রথম নতুন বার্তাটি ধরে রাখুন; সেটিই কাজের।

যে ক্লায়েন্ট সংযোগ করে কিন্তু কিছুতে পৌঁছাতে পারে না সে বিশ্বাস পুরোপুরি পেরিয়ে গেছে এবং এখন রাউটিং বা DNS প্রশ্নের মুখোমুখি।

সেই ডায়ালগ পেরোতে কখনো যাচাই বন্ধ করবেন না। যে ক্লায়েন্ট যেকোনো সার্টিফিকেট গ্রহণ করে তার CA চাওয়ার কোনো কারণ নেই, এবং এটি যে টানেল তৈরি করে তা অপারেটরের উদ্দিষ্ট টানেল নয়।