Ի՞նչ PKCS#11 URI է անհրաժեշտ OpenConnect-ին տոկենի համար։

Խելացի քարտը, որն արդեն պարունակում է ճիշտ բանալին, այնուամենայնիվ պետք է իմանա, թե դրա վրա որ օբյեկտն օգտագործել։ 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-ի ատրիբուտները, իսկ տոկոսային փախուստները կոդավորում են նշաններ, որոնք հակառակ դեպքում կխախտեին վերլուծությունը, ուստի ամբողջ արգումենտը պետք է անվնաս անցնի shell-ից։

Գտնել ձեր գրանցմանը համապատասխանող URI-ն

GnuTLS-ը տրամադրում է p11tool, որը թվարկում է, թե ընթացիկ օգտատերն իրականում ինչի կարող է հասնել p11-kit-ի միջոցով։ Սկսեք p11tool --list-tokens-ով, ապա թվարկեք ձեզ հետաքրքրող տոկենի վկայականի օբյեկտները։ Ավելացրեք --login, երբ օբյեկտները հայտնվում են միայն PIN-ից հետո, և համեմատեք սուբյեկտն ու թողարկողը գրանցամատյանի արձանագրության հետ, փոխարենը առաջին հայտնվածը ընտրելու։

Եթե տոկենն ընդհանրապես չի երևում, խնդիրը OpenConnect-ից ներքև է. p11-kit-ում այդ միջնորդ ծրագրի համար գրանցված մոդուլ չկա, կամ մոդուլը գրանցված է այլ հաշվի համար։ Համակարգային մակարդակի գրանցումը գտնվում է /etc/pkcs11/modules-ում, և օգտատիրոջ համար նախատեսված թղթապանակը կարող է պահել նույնը՝ չհպվելով համակարգի պատճենին։ Ստուգեք, որ մոդուլի ֆայլում մատակարարի ուղին ցույց է տալիս այն գրադարանին, որը ընթերցիչի ծրագրաշարը իրականում տեղադրել է։

Երբ URI-ն պատճենում եք ցանկից, պահեք նրա շուրջի չակերտները։ Առանց չակերտների կետստորակետերը կտրում են արգումենտն առաջին ատրիբուտի վրա, և հաճախորդն այնուհետև հայտնում է օբյեկտ, որը չի կարողանում գտնել։

Երբ ավտոմատ բանալու որոնումը հանձնվում է

OpenConnect-ը կարող է վկայականի URI-ից ածանցել բանալու որոնում, բայց այն ճշգրիտ համապատասխանեցումը, որ նա կատարում է, կախված է տարբերակից, և օբյեկտի տեսակի ու պիտակի մշակումը ժամանակի ընթացքում փոխվել է։ URI-ն կրճատելու խորհուրդը, մինչև այն աշխատի, նկարագրում է հին շրջանցում, ոչ թե պահանջ։ Եթե ածանցված որոնումը ձախողվում է, բանալին բացահայտ անվանեք -k-ով՝ վկայականի URI-ն ավելի անորոշ բանի վերածելու փոխարեն։

Նախքան հաճախորդին մեղադրելը հաստատեք, որ բանալին գոյություն ունի և տեսանելի է p11tool --list-keys-ով։ Ապա ստուգեք, որ օբյեկտը նշված է որպես ստորագրության կամ գաղտնազերծման համար պիտանի, քանի որ սխալ ատրիբուտներով ստեղծված բանալին չի կարող ավարտել ձեռքսեղմումը, որքան էլ URI-ն ճիշտ լինի։ Մի՛ տեղափոխեք սերիականացված pkcs11-id արժեքը OpenVPN պրոֆիլից OpenConnect ընտրանք. երկու հաճախորդներն օգտագործում են տարբեր նույնացուցիչի ձևաչափեր, նույնիսկ երբ խոսում են նույն քարտի հետ։

Եթե URI-ն լուծվում է, և PIN-ն ընդունվում է, բայց նույնականացումը դեռ ձախողվում է, դադարեցրեք URI-ի կարգավորումը։ Կարդացեք հենց դարպասի սխալը, որովհետև հաջորդ ձախողումը տոկենից վերև է։

Ձախողումներ, որոնք միայն URI-ի խնդիրների են նման

Այլ պրոտոկոլ խոսող դարպասը նույն կերպ կձախողվի՝ անկախ նրանից ձեր URI-ն ճի՞շտ է, թե՞ ոչ։ OpenConnect-ը փոխարինեց հին vpnc հաճախորդին ինչ-որ պատճառով, և քարտի աջակցությունը անհամատեղելի դարպասի պրոտոկոլը համատեղելի չի դարձնում։ Հաստատեք սերվերի սպասվող պրոտոկոլը և նույնականացման դասավորությունը նախքան օբյեկտի ատրիբուտների վրա ևս մեկ ժամ ծախսելը։

Սերվերի ինքնության վավերացումը նույնպես առանձին շերտ է։ Հաճախորդը ստուգում է դարպասի վկայականն իր վստահության պահոցի դեմ, և այդ ստուգումը կատարվում է այն բանից հետո, երբ քարտն արդեն արել է իր մասը։ Ընթերցիչի թույլտվությունները և կանգնեցված pcscd ծառայությունը ստեղծում են նույն արտաքին ախտանիշը՝ անընթեռնելի տոկեն, բայց շատ ավելի պարզ լուծմամբ։

Աշխատեք օբյեկտից դեպի դուրս. արդյոք p11tool-ը տեսնում է տոկենը, տեսնում է վկայականն ու բանալին, արդյոք OpenConnect-ն ընդունում է URI-ն, և միայն այդ ժամանակ հարցրեք՝ դարպասն ընդունու՞մ է ինքնությունը։ Յուրաքանչյուր քայլ ունի իր սխալի հաղորդագրությունը, և յուրաքանչյուրը ավելի էժան է ստուգել, քան հաջորդը։