टोकनका लागि 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 स्वीकार्छ कि, र त्यसपछि मात्र गेटवेले पहिचान स्वीकार्छ कि सोध्नुहोस्। प्रत्येक चरणको आफ्नै त्रुटि सन्देश छ, र प्रत्येक अर्कोभन्दा जाँच्न सस्तो छ।