টোকেনের জন্য OpenConnect-এর কোন PKCS#11 URI দরকার?

যে স্মার্ট কার্ডে ইতিমধ্যে সঠিক কী আছে, তাকেও জানাতে হয় তার কোন অবজেক্টটি ব্যবহার করতে হবে। সেই অবস্থায় OpenConnect কপি করা .key ফাইল চায় না; সে চায় এমন PKCS#11 URI, যা সার্টিফিকেটের নাম বলে এবং স্বয়ংক্রিয় অনুসন্ধান কাজ শেষ করতে না পারলে তার পাশের প্রাইভেট কী-ও নামায়। অস্বস্তিকর দিকটি হল, সিনট্যাক্সে বৈধ URI কিছুই প্রমাণ করে না। তাকে গেটওয়ে যে নথিভুক্তি ইতিমধ্যে বিশ্বাস করে তার নাম বলতে হবে, শুধু কার্ড যে অবজেক্ট খুলতে রাজি তা নয়।

রপ্তানি করা কী-এর বদলে ক্লায়েন্ট কী চায়

-c অপশন সাধারণত ফাইল পাথ নেয়, কিন্তু মানটি PKCS#11 URI হিসেবে পার্স হলে OpenConnect এটিকে ডিস্কের ফাইলের বদলে টোকেনের ভেতরের অবজেক্টের রেফারেন্স হিসেবে ধরে। -k অপশন প্রাইভেট কী-এর ক্ষেত্রে একইভাবে কাজ করে। কিছুই রপ্তানি হয় না, এবং কী কার্ডের দেওয়া সুরক্ষা কখনও ছাড়ে না। ক্লায়েন্ট আপনার কাছে যে নামটি চায়, টোকেন মডিউল, সার্টিফিকেট স্টোর ও গেটওয়ে নথিভুক্তি সবাই যেটিতে একমত।

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

দুটি URI, দুটি আলাদা কাজ

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

কী URI উত্তর দেয় মিলে যাওয়া প্রাইভেট উপাদান কোথায় থাকে, যখন OpenConnect তা অনুমান করতে পারে না। শুধু -c দেওয়া থাকলে ক্লায়েন্ট সার্টিফিকেটের বৈশিষ্ট্য থেকে কী-অনুসন্ধান তৈরি করে; -k দিলে অনুমানের বদলে স্পষ্ট অবজেক্ট রেফারেন্স বসে। টোকেনের PIN তৃতীয়, সম্পর্কহীন ইনপুট: এটি কার্যটির জন্য কার্ড খোলে, এবং কোনোদিন কোনো অবজেক্ট চিহ্নিত করে না।

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

ওই উদ্ধৃত স্ট্রিংয়ের সবকিছুই ডেটা। সেমিকোলনগুলো URI অ্যাট্রিবিউট আলাদা করে এবং শতাংশ-এস্কেপ এমন অক্ষর এনকোড করে যা অন্যথায় পার্সিং ভাঙত, তাই পুরো আর্গুমেন্টকে শেল থেকে অক্ষতভাবে বেরোতে হবে।

আপনার নথিভুক্তির সঙ্গে মেলা URI খুঁজে বের করা

GnuTLS-এর সঙ্গে p11tool আসে, যা দেখায় বর্তমান ব্যবহারকারী p11-kit-এর মধ্য দিয়ে আসলে কী পৌঁছাতে পারে। p11tool --list-tokens দিয়ে শুরু করুন, তারপর আপনার দরকারের টোকেনের সার্টিফিকেট অবজেক্টগুলো তালিকাভুক্ত করুন। অবজেক্টগুলো যদি শুধু PIN-এর পরে দেখা যায় তবে --login যোগ করুন, এবং যা আগে দেখা যায় তা বেছে না নিয়ে সাবজেক্ট ও ইস্যুয়ার নথিভুক্তির রেকর্ডের সঙ্গে মেলান।

টোকেন যদি একেবারেই না দেখা যায়, সমস্যা OpenConnect-এর নিচে: p11-kit-এ ওই মিডলওয়্যারের জন্য কোনো মডিউল নিবন্ধিত নেই, বা মডিউলটি অন্য অ্যাকাউন্টের জন্য নিবন্ধিত। সিস্টেম-ব্যাপী নিবন্ধন /etc/pkcs11/modules-এর অধীনে থাকে, এবং ব্যবহারকারী-ভিত্তিক ডিরেক্টরিও সিস্টেম কপি না ছুঁয়ে একই জিনিস রাখতে পারে। মডিউল ফাইলের প্রোভাইডার পাথটি এমন লাইব্রেরির দিকে দেখায় কি না পরীক্ষা করুন যা রিডারের সফটওয়্যার সত্যিই ইনস্টল করেছে।

তালিকা থেকে URI কপি করার সময় তার চারপাশের উদ্ধৃতি রেখে দিন। উদ্ধৃতিহীন সেমিকোলন প্রথম অ্যাট্রিবিউটেই আর্গুমেন্ট কেটে দেয় এবং ক্লায়েন্ট তখন এমন অবজেক্টের কথা জানায় যা সে খুঁজে পায় না।

স্বয়ংক্রিয় কী-অনুসন্ধান যখন হাল ছাড়ে

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

ক্লায়েন্টকে দোষ দেওয়ার আগে p11tool --list-keys দিয়ে নিশ্চিত করুন কী-টি আছে ও দেখা যাচ্ছে। তারপর দেখুন অবজেক্টটি সাইনিং বা ডিক্রিপশনের জন্য ব্যবহারযোগ্য হিসেবে চিহ্নিত কি না, কারণ ভুল বৈশিষ্ট্যে তৈরি কী URI যতই সঠিক হোক হ্যান্ডশেক শেষ করতে পারে না। OpenVPN প্রোফাইলের সিরিয়ালাইজড pkcs11-id মান OpenConnect অপশনে বসাবেন না; একই কার্ডের সঙ্গে কথা বললেও দুটি ক্লায়েন্ট আলাদা আইডেন্টিফায়ার ফরম্যাট ব্যবহার করে।

URI যদি রিজলভ হয় এবং PIN গৃহীত হয় তবু প্রমাণীকরণ ব্যর্থ হয়, URI টিউন করা বন্ধ করুন। গেটওয়ের নিজের ত্রুটি পড়ুন, কারণ পরের ব্যর্থতা টোকেনের উপরে।

যে ব্যর্থতাগুলো শুধু URI সমস্যার মতো দেখায়

ভিন্ন প্রোটোকল বলে এমন গেটওয়ে আপনার URI সঠিক হোক বা ভুল, একইভাবে ব্যর্থ হবে। OpenConnect পুরোনো vpnc ক্লায়েন্ট একটি কারণে বদলেছে, আর কার্ড সমর্থন অসমঞ্জস গেটওয়ে প্রোটোকলকে সামঞ্জস্যপূর্ণ করে না। অবজেক্টের বৈশিষ্ট্যে আরেক ঘণ্টা না লাগিয়ে সার্ভারের প্রত্যাশিত প্রোটোকল ও প্রমাণীকরণের বিন্যাস নিশ্চিত করুন।

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

অবজেক্ট থেকে বাইরের দিকে কাজ করুন: p11tool কি টোকেন দেখে, সার্টিফিকেট ও কী দেখে, OpenConnect কি URI গ্রহণ করে, আর কেবল তারপর জিজ্ঞাসা করুন গেটওয়ে পরিচয় গ্রহণ করে কি না। প্রতিটি ধাপের নিজের ত্রুটি বার্তা আছে, আর প্রতিটি পরেরটির চেয়ে পরীক্ষা করতে সস্তা।