OpenVPN PAM: մուտքի արգումենտը ծառայություն է, ոչ թե օգտվող

Սերվերում օգտվող ավելացվեց, գաղտնաբառը ճիշտ մուտքագրվեց, և կապը դեռ ավարտվում է AUTH_FAILED-ով։ Պլագինի տողը սովորաբար բացատրում է պատճառը՝ պլագինի ուղուց հետո եղած բառը PAM ծառայության անունն է, և հենց այն է որոշում, թե մոդուլների որ կույտն է պատասխանում հարցին։ Սա օգտվողի անուն չէ և ցուցիչ չէ գաղտնաբառերի ֆայլի, որը OpenVPN -ը ինքն է կարդում։

Ինչ է ընտրում երկրորդ բառը

Կազմաձևման տողը վերցնում է պլագինի ուղի և մեկ արգումենտ՝

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

Այդ արգումենտը PAM գրադարանին փոխանցվում է որպես ծառայության անուն, ինչի շնորհիվ գործարկվում է /etc/pam.d/openvpn-ում եղած կույտը։ Եթե այնտեղ գրեք login, փոխարենը կստանաք ինտերակտիվ մուտքի քաղաքականությունը, ձեր տարածման մեջ այդ քաղաքականության ներառած մոդուլներով։

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

Որտեղից է կույտն իրականում կարդում հաշիվները

PAM-ը բաշխիչ է։ Ծառայության ֆայլը մոդուլները թվարկում է հերթականությամբ, և առաջինը, որ կարող է պատասխանել, որոշում է արդյունքը։ pam_unix կանչող կույտը կարդում է տեղական հաշիվներ, իսկ LDAP կամ RADIUS մոդուլ կանչող կույտը հավատարմագրերը ուղարկում է բոլորովին այլ տեղ։

Կարդացեք այն ֆայլը, որին լուծվում է ծառայության անունը՝ ներառյալ այն ամենը, ինչ այն ընդգրկում է՝

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

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

Մեկ փորձ, երկու մատյան

Կապակցեք մեկ ձախողված կապը երկու կողմերում։ OpenVPN-ի մատյանը ցույց է տալիս պլագինի արդյունքը և հաճախորդի մերժումը, իսկ համակարգի նույնականացման մատյանը՝ թե որ մոդուլն աշխատեց և ինչ որոշեց։ Երկուսը նույն ժամանակային պատուհանում կարդալն է, որ առանձնացնում է բացակայող ծառայության ֆայլը backend-ի ժամկետանցից։ Նույնականացման մատյանում բացվածքը նշանակում է, որ կույտին ընդհանրապես չեն հասել։

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

Ստուգեք ծառայությունն ուղղակիորեն PAM-ով խոսող գործիքով, որպեսզի միաժամանակ չվրիպազերծեք VPN-ը և կույտը։ Նույն ծառայության անվան և հաշվի հետ հաջող ուղղակի փորձը սահմանափակում է խնդիրը դեյմոնի կողմից հավատարմագրերի փոխանցման ձևով, ոչ թե հաշվով։

pamtester openvpn alice authenticate

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

Առանձին ծառայությունը ավելի լավ է, քան մուտքի խմբագրումը

Տվեք VPN-ին սեփական ծառայության ֆայլ, երբ նրա պահանջները տարբերվում են ինտերակտիվ մուտքից, ինչը սովորաբար այդպես է։ login կամ common-auth խմբագրելը փոխում է քաղաքականությունը յուրաքանչյուր ծրագրի համար, որ ներառում է դրանք, և հաջորդ մարդը, ով կվրիպազերծի անկապ մուտքի խնդիր, կժառանգի ձեր փոփոխությունը։

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

Ինչ է ուղարկում հաճախորդը և ինչ չի ուղարկում

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

Օգտվողի անունն ու գաղտնաբառը կարող են գոյակցել հաճախորդի սերտիֆիկատների հետ՝ և PAM-ը միացնելը պատճառ չէ դադարեցնելու սերտիֆիկատների ստուգումը։ Պահեք տեղակայման նախատեսած շերտերը և ուղղեք միայն հաշիվների աղբյուրը։

Ընդունումը երկկողմ է՝ նախատեսված հաշիվը հաջողվում է, և այն հաշիվը, որը պետք է մերժվի, դեռ ձախողվում է։ Ֆայլը auth-pam պլագինի README-ն փաստագրում է ծառայության արգումենտը և backend-երը, որոնց այն կարող է սպասարկել, և հենց այնտեղ է վայրը հաստատելու այն կարգավորումը, որը փորձում եք կառուցել։