რატომ .ovpn ფაილის რედაქტირება ვერ ჩართავს MFA-ს სერვერზე

თქვენ პროფილს უმატებთ auth-user-pass-ს, ხელახლა უკავშირდებით და კლიენტი ითხოვს მომხმარებლის სახელსა და პაროლს. ჩანს, რომ MFA ჩართულია. შემდეგ შეიყვანთ კოდს არასწორი ანგარიშიდან, ან კოდს, რომელიც ათი წუთის წინ ამოიწურა, და გვირაბი მაინც ადის. ეს არის სიმპტომი: კლიენტი შეიცვალა, სერვერი არა. ერთჯერადი პაროლი ფაქტორია მხოლოდ მაშინ, როცა სერვერზე გადამმოწმებელი წყვეტს, მოქმედია თუ არა ის იმ იდენტობისთვის, რომელიც მას ითხოვს.

მოთხოვნა მხოლოდ იმას ამტკიცებს, რომ კლიენტმა იკითხა, მეტს არაფერს

.ovpn ფაილი კლიენტის მხარის დოკუმენტია. მას შეუძლია კლიენტს უთხრას, მოითხოვოს სერტიფიკატები, შეინახოს ისინი ქეშში ან შეწყვიტოს ამის კეთება. მას არ შეუძლია მომხმარებლის რეგისტრაცია, PAM მოდულის დაყენება, ან სერვერის აიძულოს მოითხოვოს მეორე ფაქტორი, რომელსაც ის ახლა არ ამოწმებს.

ტელეფონზე აუთენტიფიკაციის აპის დაყენება ამ კავშირს არც ქმნის. Google Authenticator PAM პროექტი OTP-ის გადამოწმების კომპონენტია და შეიძლება იდგეს OpenVPN-ის უკან; ეს არ არის Google ანგარიშის შესვლის იმპორტირებულ პროფილზე მიწებების გზა.

რეგისტრაცია ის ნაწილია, რომელსაც პროფილი ვერ აკეთებს

TOTP-ს სჭირდება სარეგისტრაციო მასალა, რომელიც საერთოა აუთენტიფიკაციის აპსა და მის გადამმოწმებელს შორის. ტელეფონის ექვსი ციფრი გამოსავალია; მათ უკან მდგარი თესლი საიდუმლოა და ეკუთვნის ერთ იდენტობას.

ამიტომ ოპერატორს სჭირდება რეგისტრაციის პროცესი, რომელიც სწორ თესლს სწორ VPN იდენტობას უკავშირებს, და ასევე დაკარგული ტელეფონისთვის დადასტურებული ჩანაცვლების გზა. მომხმარებლებს საკუთარი სახელობის ფაილის ატვირთვის უფლების მიცემა რეგისტრაციას ანგარიშის ხელში ჩაგდების შესაძლებლობად აქცევს, და ატვირთვის დაშიფვრა ამას არ ცვლის.

PAM-ზე დაფუძნებულ დიზაინს არ სჭირდება თითოეული VPN მომხმარებლისთვის ცალკე Unix ანგარიშის შექმნა. მოდულის დოკუმენტაცია მხარს უჭერს ალტერნატიულ საიდუმლო ბილიკებს და ფაილებზე წვდომისთვის გამოყოფილ ანგარიშს, რაც ფაილური სისტემის იდენტობაა და არა გადასამოწმებელი შესვლის იდენტობა.

გავრცელებული შეცდომაა ფიქსირებული საიდუმლო ბილიკი, რომელიც ერთი მომხმარებლის სახელით მთავრდება და ერთმომხმარებლიანი მაგალითიდან არის კოპირებული. ეს ერთი იდენტობის დემონსტრაციაა, არა მომხმარებლის მიხედვით ძებნა, და მისი ყოველი მოთხოვნისთვის გამოყენება არავის აძლევს დამოუკიდებლად რეგისტრირებულ აუთენტიფიკაციის აპს. ჩაწერეთ იდენტობების რუკა, დაიცავით თესლის ფაილები და პაროლის, სერტიფიკატისა და ანგარიშის შემოწმებები ერთსა და იმავე აუთენტიფიკაციის დასტაში შეინახეთ.

წაიკითხეთ PAM დასტა, რომ ნახოთ რა არის რეალურად საჭირო

account required pam_permit.so-ის მსგავსი ხაზი არ ახორციელებს ანგარიშის უფლებამოსილებას და არ ამატებს ფაქტორს. ის ნებას რთავს PAM-ის ანგარიშების მართვის იმ ეტაპს, რაც ეტაპზეა განცხადება და არა თქვენს მომხმარებლებზე.

იგივე ეხება ლმობიერ რეგისტრაციის პარამეტრებს. რეგისტრირებული საიდუმლოს გარეშე მომხმარებლების მიღება შეიძლება იყოს განზრახ გაშვების გადაწყვეტილება, მაგრამ ეს არ არის მტკიცება, რომ MFA სავალდებულოა, და ის უნდა ჩაიწეროს როგორც დროებითი გამონაკლისი დასრულების თარიღით.

შეათანხმეთ კლიენტის ურთიერთქმედება სერვერის დიზაინს

auth-user-pass

ეს დირექტივა ითხოვს მომხმარებლის სახელისა და პაროლის შეყვანას. ის არ აწყობს PAM-ს, არ ქმნის რეგისტრაციის ჩანაწერს და არ ეუბნება სერვერს, რომ პაროლის ველში TOTP მნიშვნელობაა. სერვერის ინტეგრაციამ და კლიენტმა უნდა შეთანხმდნენ ურთიერთქმედებაზე, რომელსაც განლაგება რეალურად უჭერს მხარს: გამოწვევა, დოკუმენტირებული კომბინირებული სერტიფიკატის ფორმატი ან პროდუქტისთვის სპეციფიკური ნაკადი.

ნუ დაუმატებთ კოდს პაროლს მხოლოდ იმიტომ, რომ კლიენტი ერთ ველს აჩვენებს. ეს მუშაობს მხოლოდ იქ, სადაც სერვერის დანამატი ზუსტად ამ ფორმატს ელოდება, და ყველგან სხვაგან დამაბნეველად ვარდება.

შეინახეთ თესლები და QR მასალა საერთო პროფილებისა და ჩვეულებრივი დიაგნოსტიკური ჟურნალების მიღმა. აუთენტიფიცირებული შესვლის არხით გაგზავნილი კოდი არ არის იგივე ობიექტი, რაც კონტროლირებული რეგისტრაციის დროს გაცემული თესლი, და მათი შერევა მხარდაჭერის ბილეთში სწორედ ის გზაა, რომლითაც საიდუმლოები გადის.

ხელახალი კავშირები, ტოკენები და ტესტი, რომელიც საკითხს წყვეტს

დაგეგმეთ, რა მოხდება პირველი წარმატებული შესვლის შემდეგ. ადრე მიღებული კოდი შეიძლება ვადაგასული იყოს ან უარყოფილი იქნას როგორც გამეორება შემდეგი აუთენტიფიკაციისას. auth-nocache აკონტროლებს სერტიფიკატების შენახვას და არ აყენებს MFA-ს, ხოლო reneg-sec 0 არ არის TOTP-ის მხარდაჭერის განსაზღვრება, რამდენჯერაც არ უნდა გამოჩნდეს ფორუმის თემებში.

ზოგიერთი განლაგება გასცემს აუთენტიფიკაციის ტოკენებს საწყისი შემოწმების შემდეგ, რათა ხელახალი კავშირები აღარ იკითხავდეს. ეს დიზაინის გადაწყვეტილებაა საკუთარი მოქმედების ფანჯრითა და გაუქმების ისტორიით, და არა ნაგულისხმევი მნიშვნელობა, რომელსაც მემკვიდრეობით იღებთ.

შემდეგ შეამოწმეთ მიღების პოლიტიკა იმ კლიენტით, რომელსაც ხალხი რეალურად იყენებს. რეგისტრირებული მომხმარებელი სწორი პაროლით, სერტიფიკატითა და მიმდინარე კოდით უნდა დაუკავშირდეს. არასწორი კოდი, რეგისტრაციის გარეშე მომხმარებელი და აკრძალული ანგარიში თითოეული უნდა ჩავარდეს, და მიზეზი სერვერის ჟურნალში უნდა ჩანდეს. სანამ ამ უარყოფებს არ ნახავთ, თქვენ გაქვთ მოთხოვნა და არა პოლიტიკა.