ٹوکن کے لیے 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 کی خصوصیات کو الگ کرتے ہیں اور فیصدی escapes اُن حروف کو انکوڈ کرتے ہیں جو بصورت دیگر تجزیہ توڑ دیں گے، اس لیے پوری دلیل کو شیل سے بے نقصان گزرنا ہوگا۔

اپنے اندراج سے میل کھانے والا 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 قبول کرتا ہے، اور پھر ہی پوچھیں کہ گیٹ وے شناخت قبول کرتا ہے یا نہیں۔ ہر مرحلے کا اپنا خرابی پیغام ہے، اور ہر ایک اگلے سے جانچنے میں سستا ہے۔