टोकनसाठी 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 स्वीकारतो का, आणि मगच गेटवे ओळख स्वीकारतो का ते विचारा। प्रत्येक टप्प्याचा स्वतःचा त्रुटी संदेश असतो, आणि प्रत्येक पुढच्यापेक्षा तपासायला स्वस्त आहे।