ટોકન માટે 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 સ્વીકારે છે કે નહીં, અને પછી જ પૂછો કે ગેટવે ઓળખ સ્વીકારે છે કે નહીં. દરેક પગલાની પોતાની ભૂલસંદેશ હોય છે, અને દરેક આગળના પગલા કરતાં ચકાસવા સસ્તું છે.