OpenVPN առանց հաճախորդի վկայագրի՝ սերվերի քաղաքականություն, ոչ պրոֆիլ

Դուք ջնջում եք վկայագրի և բանալու տողերը, հանձնում պրոֆիլը, և կապը դեռ ձախողվում է վկայագրի սխալով։ Պրոֆիլը երբեք այն չէր, ինչ պարտադրում էր այդ պահանջը։ Սերվերն է որոշում՝ արդյոք հաճախորդի վկայագիրը պարտադիր է, և հաճախորդի կողմի ոչ մի փոփոխություն չի բանակցում այն։ Ուստի լուծումը սերվերի քաղաքականության փոփոխությունն է, որը կատարվում է դիտավորյալ, և ամեն ինչ, ինչից այն կախված է, թարմացվում է նույն անցումով։

Պրոֆիլը քաղաքականությունը չէ

Community OpenVPN 2.6-ը գալիս է պարտադիր հաճախորդի վկայագրերով, քանի որ verify-client-cert լռելյայն require է։ Այն none-ի վրա դնելն է, որ դադարեցնում է վկայագրի պահանջը և հաճախորդի նույնականացումը հանձնում է սերվերի արդեն գործող օգտանուն-գաղտնաբառ կարգավորմանը։ Ավելի հին ուղեցույցները դիմում են client-cert-not-required-ին՝ նույն մտքի հնացած ուղղագրությանը, ուստի օգտագործեք այն հրահանգը, որը փաստագրում է ձեր տեղադրված տարբերակը։ Ամեն դեպքում փոփոխությունը կատարվում է սերվերում, և ոչ մի հաճախորդի պրոֆիլ չի կարող այն կատարել։

Ստորև հատվածն ամբողջ սերվերային փոփոխությունն է, և ինքնին այն աշխատող նույնականացման կոնֆիգուրացիա չէ։ verify-client-cert none-ը հանում է վկայագրի պահանջը, մինչդեռ username-as-common-name-ը հաշվի անունը դարձնում է այն ինքնությունը, որը տեսնում են հետագա հետադարձ կանչերը և յուրաքանչյուր հաճախորդի ֆայլերը։ Ոչ մի տող գաղտնաբառ չի ստուգում, ուստի ստուգիչ դեռ պետք է գոյություն ունենա։

verify-client-cert none
username-as-common-name

Այդ ստուգիչը պլագին է կամ սկրիպտ, որը ղեկավարվում է auth-user-pass-verify-ով, և այն պետք է տեղում լինի նախքան վերևի տողերից որևէ մեկը իմաստ կունենա։ Հերթականությունը շրջելը ձեզ տալիս է պատուհան, որտեղ սերվերը ոչ վկայագիր է պահանջում, ոչ հաշիվ ստուգում։

Ինչն է դեռ ստուգում սերվերը

Հաճախորդի վկայագրից հրաժարվելը TLS-ից հրաժարվել չէ։ Սերվերը պահում է իր վկայագիրն ու բանալին, իսկ հաճախորդը պահում է CA-ի վստահությունը և հոսթի անվան ստուգումները, որոնք թույլ չեն տալիս խոսել խաբեբայի հետ։ remote-cert-tls server-ը կամ CA-փաթեթը հեռացնելը, քանի որ հաճախորդն այլևս վկայագիր չունի, տարածված և լուրջ սխալ ընթերցում է, և 2.6 տեղեկատուն հստակ ասում է, որ երկու ուղղությունները անկախ են։ Մեկը սերվերին ապացուցում է հաճախորդին, մյուսը՝ հաճախորդին սերվերին։

Պրոֆիլը կարող է նաև կրել tls-auth կամ tls-crypt բլոկ։ Դա կառավարման ալիքի ընդհանուր բանալի է՝ իր բաշխման և պտտման ցիկլով, ուստի առանց վկայագրի կամ բանալու տողերի ֆայլն ինքնաբերաբար անվտանգ չէ հրապարակման համար։ Վերաբերվեք դրան որպես գաղտնիք, քանի դեռ չեք կարդացել այն։

Աշխատող պրոֆիլից պատճենված վկայագրի ֆայլն ինքնին ոչինչ չի ապացուցում. տիրապետումը նշանակում է պահել դրան համապատասխանող անձնական բանալին, ինչը ստուգում է վկայագրով նույնականացվող տեղակայումը։ Վկայագիր պարունակող ֆայլը ֆայլ չէ, որով կարելի է նույնականացվել։

Ինչ պետք է անի ստուգիչը

Վկայագրի պահանջը հեռացնելուց հետո ամեն ինչ հենվում է ստուգիչի վրա՝ պլագինի կամ auth-user-pass-verify-ով ղեկավարվող սկրիպտի։ Այն պետք է մերժի անվավեր հավատարմագրերը, մերժի անջատված կամ ոչ պիտանի հաշիվները և փակ կերպով ձախողվի, երբ չի կարող հասնել իր backend-ին։ username-as-common-name հաճախ միացվում է կողքին, և այն փոխում է այն ինքնությունը, որը տեսնում են հետագա հետադարձ կանչերը և յուրաքանչյուր հաճախորդի կոնֆիգուրացիայի ֆայլերը։ Այն գաղտնաբառ չի ստուգում և ոչ պիտանի հաշիվը պիտանի չի դարձնում։ Դրանք առանձին աշխատանքներ են, և դրանք խառնելն այն ճանապարհն է, որով միգրացիան անցնում է երջանիկ ուղու թեստը և ձախողվում իր առաջին իրական միջադեպում։

Բացասական դեպքերը ստուգեք նույնքան ուշադիր, որքան դրականը։ Գաղտնաբառի հուշում ցույց տվող պրոֆիլը միայն ապացուցում է, որ հաճախորդը կարող է հուշում նկարել, մինչդեռ սխալ գաղտնաբառ ընդունող սերվերը ապացուցում է շատ ավելի վատ բան։ Թեստային հավաքածուին ավելացրեք անջատված հաշիվ և ժամկետանց հավատարմագիր, ոչ միայն վատ գաղտնաբառ։

Փոխեք քաղաքականությունը, պրոֆիլը և քարտեզագրումը միասին

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

Այս ուղու համար պահեք երկու թեստային հաշիվ՝ մեկ վավեր և մեկ հայտնի վատ, և օգտագործեք երկուսն էլ ստուգիչի ցանկացած փոփոխությունից հետո։ Վավեր հաշիվը ապացուցում է երջանիկ ուղին և ինքնության քարտեզագրումը, վատը՝ որ մերժումը դեռ աշխատում է։ Ոչ մի թեստ ձեզ ոչինչ չի ասում պիտանելիության կանոնների մասին, ուստի ավելացրեք հաշիվ, որը պետք է մերժվի քաղաքականության պատճառներով, եթե տեղակայումն ունի այդպիսիք։ Յուրաքանչյուր փոփոխությունից հետո գործարկեք բոլոր երեքը, քանի որ ամեն ինչ ընդունել սկսող ստուգիչը ճիշտ նման է աշխատող մուտքի։

Գրանցեք, թե սերվերն իրականում որ նույնականացման մեթոդներն է ընդունում, ոչ թե ինչ է առաջարկում պրոֆիլը։ Այդ գրառումը պատասխանում է այն հարցին, որը մարդիկ անընդհատ տալիս են՝ ով կարող է միանալ այս ծառայությանը։ Այն նաև վերապրում է հաջորդ ադմինիստրատորին, որը հակառակ դեպքում նորից կբացահայտի այն փաթեթների որսից։