OpenVPN-ის auth-user-pass-verify სკრიპტი: სწორი გასვლის კოდი

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

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

სამი სტატუსი, რომლის დაბრუნებაც ჰუკს შეუძლია

auth-user-pass-verify შემთხვევაში OpenVPN 2.6-ის სახელმძღვანელო გასვლის კოდ 0-ს განსაზღვრავს როგორც მიღებას, 1-ს როგორც უარყოფას და 2-ს როგორც გადავადებულ აუთენტიფიკაციას. ეს არის ერთადერთი სამი პასუხი, რომელსაც სერვერი იგებს, და თითოეულ მათგანს განსხვავებული შედეგი აქვს კავშირისთვის. სკრიპტი, რომელიც გადის თავისი ბოლო ბრძანების სტატუსით, ფაქტობრივად ლოგის გამოძახებას ან გასუფთავების ნაბიჯს აძლევს ხმის მიცემის უფლებას. ჩაწერეთ სტატუსი ცხადად ყოველ ტოტში, მათ შორის იმ ტოტებში, რომლებიც დამამოწმებელს არასდროს მიუღწევიათ.

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

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

წაიკითხეთ სერტიფიკატის ფაილი ზუსტად ისე, როგორც დაწერილია

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

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

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

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

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

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

დაამოწმეთ განაჩენი და არა დაბეჭდილი ხაზი

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

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

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