OpenVPN კლიენტის სერტიფიკატის გარეშე: სერვერის პოლიტიკა და არა პროფილი

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

პროფილი პოლიტიკა არ არის

Community OpenVPN 2.6 სავალდებულო კლიენტის სერტიფიკატებით მოდის, რადგან verify-client-cert ნაგულისხმევად require-ია. სწორედ none-ზე დაყენება აჩერებს სერტიფიკატის მოთხოვნას და კლიენტის ავთენტიფიკაციას გადასცემს იმ მომხმარებლის სახელისა და პაროლის წესრიგს, რომელსაც სერვერი უკვე ამუშავებს. ძველი სახელმძღვანელოები მიმართავენ client-cert-not-required-ს, იმავე იდეის მოძველებულ ჩანაწერს, ამიტომ გამოიყენეთ ის დირექტივა, რომელსაც თქვენი დაყენებული ვერსია ადასტურებს. ნებისმიერ შემთხვევაში ცვლილება სერვერზე ხდება და ვერც ერთი კლიენტის პროფილი ვერ შეასრულებს მას.

ქვემოთ მოცემული ფრაგმენტი სერვერის მხარეს არსებული მთელი ცვლილებაა და თავისთავად არ არის მუშა ავთენტიფიკაციის კონფიგურაცია. verify-client-cert none ხსნის სერტიფიკატის მოთხოვნას, ხოლო username-as-common-name ანგარიშის სახელს აქცევს იმ იდენტობად, რომელსაც ხედავენ შემდგომი გამოძახებები და თითოეული კლიენტის ფაილები. არც ერთი ხაზი არ ამოწმებს პაროლს, ამიტომ შემმოწმებელი მაინც უნდა არსებობდეს.

verify-client-cert none
username-as-common-name

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

რა კვლავ ამოწმებს სერვერს

კლიენტის სერტიფიკატზე უარის თქმა არ ნიშნავს TLS-ზე უარის თქმას. სერვერი ინარჩუნებს თავის სერტიფიკატსა და გასაღებს, ხოლო კლიენტი ინარჩუნებს CA-ს ნდობას და ჰოსტის სახელის შემოწმებებს, რომლებიც ხელს უშლიან მას თაღლითთან საუბარში. remote-cert-tls server-ის ან CA-ს პაკეტის წაშლა იმიტომ, რომ კლიენტს აღარ აქვს სერტიფიკატი, გავრცელებული და სერიოზული არასწორი წაკითხვაა, და 2.6-ის ცნობარი ცხადად ამბობს, რომ ორი მიმართულება დამოუკიდებელია. ერთი სერვერს უმტკიცებს კლიენტს, მეორე კლიენტს უმტკიცებს სერვერს.

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

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

რა უნდა გააკეთოს შემმოწმებელმა

სერტიფიკატის მოთხოვნის მოხსნის შემდეგ ყველაფერი შემმოწმებელზეა დამოკიდებული: დანამატი ან auth-user-pass-verify-ით მართული სკრიპტი. მან უნდა უარყოს არასწორი სერტიფიკატები, უარყოს გამორთული ან უვარგისი ანგარიშები და დაიხუროს, როცა ვერ აღწევს თავის backend-ს. username-as-common-name ხშირად გვერდით ირთვება და ცვლის იმ იდენტობას, რომელსაც ხედავენ შემდგომი გამოძახებები და თითოეული კლიენტის კონფიგურაციის ფაილები. ის არ ამოწმებს პაროლს და არ აქცევს უვარგის ანგარიშს ვარგისად. ეს ცალკეული საქმეებია და მათი არევა იმ გზით ხდება, რომ მიგრაცია გაივლის ბედნიერი გზის ტესტს და ჩავარდება პირველ რეალურ ინციდენტში.

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

შეცვალეთ პოლიტიკა, პროფილი და რუკა ერთად

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

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

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