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-ებს, რომლებსაც ის შეიძლება მოემსახუროს, და სწორედ იქ არის ადგილი იმ განლაგების დასადასტურებლად, რომლის აშენებასაც ცდილობთ.