Windows-এ OpenVPN 3 এবং Connect-এ cryptoapicert কেন ব্যর্থ হয়

আপনি একটি কাজ করা OpenVPN 2 প্রোফাইল নতুন একটি Windows ক্লায়েন্টে কপি করেন, আর পুরনো ক্লায়েন্ট নিজে খুঁজে পেত যে সার্টিফিকেট, তা আর দেওয়া হয় না। যে লাইনটি সেটি কাজ করাত, তা Community 2 ক্লায়েন্টের অন্তর্গত Windows-নির্দিষ্ট একটি সিলেক্টর, আর নতুন অ্যাপ্লিকেশনটি ভিন্ন ক্রেডেনশিয়াল পথের ভিন্ন একটি প্রোগ্রাম। প্রোফাইলটি ওই এক লাইন ছাড়া অপরিবর্তিত, আর ঠিক এ কারণেই পার্থক্যটি দেখা কঠিন।

সেই প্রতিবেদনে তিনটি স্তর মিলিয়ে ফেলা হয়: Community ক্লায়েন্ট, মূল লাইব্রেরি এবং কেউ যে ফ্রন্টএন্ড ইনস্টল করেছে। এর মধ্যে কেবল একটি কখনো নির্দেশটি বুঝেছিল।

যেখানে বিকল্পটি আছে সেখানে এর অর্থ কী

Windows-এ Community OpenVPN 2 ক্লায়েন্টে cryptoapicert এমন একটি সার্টিফিকেট বোঝায় যা ক্লায়েন্টকে ফাইলে নয়, Windows সার্টিফিকেট স্টোরে খুঁজতে হবে। এটি Windows-নির্দিষ্ট একটি সুবিধা, এবং এটি কাজ করে কারণ ওই ক্লায়েন্ট স্টোরটি তালিকাভুক্ত করতে ও প্রাপ্ত কী নিজের TLS স্ট্যাককে দিতে জানে। তাই নির্দেশটি ওই ক্লায়েন্টের কনফিগারেশন ভাষার অংশ, OpenVPN প্রোটোকলের কোনো বৈশিষ্ট্য নয়। তারের বিন্যাসে এটি বহন করে এমন কিছু নেই।

একই লাইনটি অন্য অ্যাপ্লিকেশনে কপি করলে আপনি এমন একটি শব্দ কপি করলেন যা নতুন প্রোগ্রাম বিশ্লেষণ করতে, উপেক্ষা করতে বা প্রত্যাখ্যান করতে পারে। নির্দেশ প্রোটোকলের বৈশিষ্ট্য নয়, আর এটি এমনকি প্রতিটি ক্লায়েন্টের বৈশিষ্ট্যও নয় যা OpenVPN।

মূল লাইব্রেরি বদলে কী দেয়

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

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

Windows ফ্রন্টএন্ড বদলে কী করে

OpenVPN Connect ভিন্ন পথ নেয়: অপারেটর একটি PKCS#12 ফাইল আমদানি করেন যাতে সার্টিফিকেট ও তার ব্যক্তিগত কী থাকে, সেটি এই উদ্দেশ্যে তৈরি একটি OpenVPN Certificate Store-এ রাখেন, তারপর বাহ্যিক সার্টিফিকেটটি প্রোফাইলে নির্ধারণ করেন। এটি একটি সচেতন আমদানি ধাপ, ব্যক্তিগত স্টোরে যা আছে তার স্বয়ংক্রিয় আবিষ্কার নয়। পার্থক্যটি তখন গুরুত্বপূর্ণ যখন কেউ ধরে নেন অন্য উদ্দেশ্যে ইনস্টল করা সার্টিফিকেট কেবল ক্লায়েন্টের তালিকায় দেখা যাবে।

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

কী-এর নীতির সঙ্গে মেলে এমন পথ বেছে নিন

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

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

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