სად ხვდება სტატიკური გამოწვევის კოდი OpenVPN-ში შესვლისას

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

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

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

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

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

რა უნდა უკვე უჭერდეს მხარს სერვერს

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

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

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

დაშიფრული ველი, რომელსაც მართვის ინტერფეისი აგზავნის

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

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

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

სტატიკური დინამიკურის წინააღმდეგ: განსხვავებული დრო

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

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

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

შეამოწმეთ წარმატებაც და მარცხიც, და არა მხოლოდ დიალოგი

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

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