OpenVPN verify-x509-name: subject, name և name-prefix տարբերությունը

Նախ կարդացեք համապատասխանության տեսակը, ապա տեքստը՝ verify-x509-name հրահանգը կարող է ճիշտ թվալ և այնուամենայնիվ ընդունել վկայագիր, որին դուք չէիք ուզում վստահել։ Նույն սպասվող տեքստով, բայց տարբեր տեսակներով երկու տողերը տարբեր պահանջներ են։ Նախ կարդացեք տեսակը, ապա տեքստը։ Հրահանգը դիտարկեք որպես միացման ևս մեկ պայման, ոչ թե ամբողջ ստուգում։

Ինչ է իրականում հաստատում այդ ընտրանքը

Հրահանգը նշում է ինքնություն, որը պետք է կրի մյուս կողմի վկայագիրը։ Երբ համեմատությունը ձախողվում է, OpenVPN դադարեցնում է ձեռքսեղմումը, և թունել չի բարձրանում։ Պրոֆիլի մնացած ամեն ինչը դեռ գործում է. վկայագիրը պետք է շղթայվի վստահելի CA-ի, և դերի ստուգումը պետք է անցնի, ուստի սա լրացուցիչ պայման է, ոչ փոխարինող։ Պրոֆիլը, որը բավարարում է անվան սպասումը և ձախողվում դերի ստուգմանը, դեռ կոտրված է, և մատյանը սովորաբար դա ասում է։

Այն տարբերվում է նաև զննարկիչի կատարած հոսթի անվան ստուգումից։ Զննարկիչը անունները համապատասխանեցնում է subject-ի այլընտրանքային անուններին ըստ իր TLS կույտի կանոնների, մինչդեռ OpenVPN-ը համեմատում է վկայագրի մեկ դաշտ ձեր ընտրած տեսակով։ Այդ պատճառով զննարկիչի ոճի հոսթի անունը հրահանգում տեղադրելը կարող է անհամապատասխանություն առաջացնել, նույնիսկ երբ վկայագիրն իսկապես ծածկում է ծառայությունը։

subject՝ ամբողջ տարբերակիչ անունը, նշան առ նշան

Երբ տեսակը գրված չէ, լռելյայնը subject է, և սպասվող արժեքը պետք է վերարտադրի վկայագրի ամբողջ subject DN-ն։ Դաշտերի կարգը, բաժանիչները, բացատները և escaping-ը բոլորն էլ հաշվի են առնվում, որովհետև համեմատությունը կատարվում է կոդավորված տողի վրա։ Եթե բաց թողնեք տեսակը, դուք ընտրել եք երեք համեմատություններից ամենախիստը։ Չկա նորմալացման քայլ, որը կփրկի արտաքին տարբերությունը։ Սա արժե իմանալ առաջին թարմացումից առաջ, ոչ հետո։

Այդ խստությունը փխրուն է թարմացումների ընթացքում։ CA-ն, որը վերադասավորում է ատրիբուտները, ավելացնում լրացուցիչ դաշտ կամ փոխում արժեքի escaping-ը, նույն մեքենայի համար ստեղծում է նոր տող, և տարիներ աշխատած հրահանգը սկսում է ձախողվել հաջորդ թողարկման ժամանակ։ Ընդունված DN-ը փոփոխությունների մատյանում պահելը հաջորդ թարմացումը դարձնում է պարզ տարբերություն։ Այնտեղ, որտեղ օպերատորը հրապարակում է ամբողջ DN և երաշխավորում դրա ձևը, subject-ը ողջամիտ ընտրություն է. այլուր ավելի նեղ դաշտն ավելի հեշտ է ճշմարիտ պահել։

name՝ մեկ դաշտ, սովորաբար ընդհանուր անունը

Տեսակը name համեմատում է subject-ի մեկ դաշտ։ Եթե պրոֆիլն այլ բան չի ասում, այդ դաշտը ընդհանուր անունն է, և սպասվող արժեքը հենց այդ դաշտն է, ոչ դրա շուրջ DN-ը։

Որոգայթն այն է, որ ժամանակակից վկայագրերը միշտ չէ, որ ծառայության անունը դնում են CN-ի մեջ։ Շատերը կրում են այն subject-ի այլընտրանքային անվան մեջ և CN-ը թողնում են դատարկ կամ ընդհանուր, ուստի զննարկիչի ընդունած վկայագիրը կարող է ձախողվել այս համեմատությանը։ Նախքան սպասումը գրելը ստուգեք ձեզ իրականում տրված վկայագիրը և հաստատեք, թե որ դաշտն է ընտրում պրոֆիլը։ Դատարկ CN-ի համեմատությունը անվան հետ անհամապատասխանություն է, ոչ կարգավորման պատահար։

name-prefix՝ միտումնավոր լայն, ուստի սահմանափակեք շրջանակը

Տեսակի name-prefix սպասումը համապատասխանում է ընտրված դաշտի սկզբին։ Սա հարմար է անվանակարգման սխեմայի համար և վտանգավոր՝ ցանկացած ընդհանուր բանի համար։

Եթե սպասումը vpn.example է, ապա կանցնեին և՛ vpn.example.com և՛ vpn.example.net , պայմանով որ շղթայի մնացած մասը վստահելի է։ Լայնությունը հատկանիշն է, և միևնույն ժամանակ այն մասը, որը պետք է գրավոր հիմնավորել։ Նախադրյալը ողջամիտ է, երբ CA-ն և անվանակարգման սխեման ձերն են, և շատ ավելի թույլ, երբ հանրային CA-ն թողարկում է նույն ձևանմուշով։ Եթե սխեմային ճկունություն է պետք, սահմանափակեք այն CA-ում, այլ ոչ թե ընդլայնեք հաճախորդի ստուգումը։

Ընտրեք տեսակը ըստ նույնացուցիչի, ապա ապացուցեք այն

Աշխատեք հակառակ ուղղությամբ՝ օպերատորի նախատեսած ինքնությունից։ Եթե նա հրապարակում է ամբողջ DN և պահում այն կայուն, subject դա է արտահայտում։ Եթե ծառայությունը կոչում է ընդհանուր անունով, օգտագործեք name ։ Եթե նա տիրապետում է անվանակարգման սխեմայի և ընդունում դրա ամբողջ տարածքը, name-prefix դա հստակ ասում է։

Թարմացումներն այն տեղն են, որտեղ հրահանգը փորձարկվում է։ Համեմատեք հաստատված ինքնությունը նոր վկայագրի հետ, ոչ հին ֆայլի, որովհետև նոր վերջնակետի հասցեն չի նշանակում նոր վկայագրի ինքնություն։ Մի՛ ջնջեք հրահանգը միայն այն պատճառով, որ ծանոթ հասցեն պատասխանում է՝ հասանելիությունը և նախատեսված մյուս կողմը տարբեր փաստեր են , և հասցեն ապացուցում է միայն, որ ինչ-որ բան պատասխանել է։ Գրանցեք ճշգրիտ սխալը և անվան հրապարակային տվյալները մաքրված զեկույցում, որովհետև անվան անհամապատասխանությունը կարելի է ցույց տալ առանց որևէ անձնական բանալու նյութի։

Աջակցվող ուղղումից հետո նորից միացեք բոլոր նախատեսված ստուգումներով և ստուգեք այն ռեսուրսը, որն իսկապես անհրաժեշտ է։ Հաջողությունը նշանակում է, որ նախատեսված սերվերն ընդունվել է, ոչ թե ինչ-որ վկայագիր բռնի ուժով անցկացվել է։ Պաշտոնական ձեռնարկը OpenVPN 2.6 manual փաստագրում է երեք տեսակները և դրանց վստահության նշումները, և հենց այն է հղումը, որին վկայակոչում են, երբ մատակարարի ինտերֆեյսը հակասում է պրոֆիլին։