OpenVPN Access Server და Community: რა გადადის სინამდვილეში

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

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

რატომ არ ატარებს .ovpn ფაილი კონფიგურაციას

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

Community Edition-ში ეკვივალენტები თქვენივე შენახული ფაილებია: client-config-dir ჩანაწერები, რომლებშიც თითოეული კლიენტის პარამეტრებია, როგორიცაა ifconfig-push და iroute, გაუქმებებისთვის CRL და tls-crypt გასაღები. Access Server იმავე ცნებებს საკუთარ მონაცემთა ბაზაში ინახავს და ვებკონსოლისა და sacli ბრძანების ხაზის ხელსაწყოს მეშვეობით ამჟღავნებს. ცნებები ერთი-ერთზე თანხვედრია; არტეფაქტები საერთოდ არ გადადის.

პროფილები ასევე კონტრაბანდით შემოიტანენ ქცევას, რომელსაც ვერავინ შეამჩნევს, სანამ არ შეიცვლება. redirect-gateway def1-ის მქონე კლიენტი მთელ დათვალიერებას სერვერის გავლით აგზავნის; გადაიტანეთ ის ინსტალაციაში ამ ხაზის გარეშე და საჩივარი იქნება, რომ ინტერნეტი გატყდა. CA-ს შეუსაბამობა ან არასწორი remote-cert-tls პარამეტრი ხმამაღლა ვარდება, რაც კარგი შედეგია. დაკარგული tls-crypt გასაღები ჩუმი ვადის გასვლის სახით ვარდება, რაც კარგი არ არის.

რას ფლობს მართვის შრე

დათვალეთ ის, რაც პროტოკოლი არ არის: ანგარიშების შექმნა, პაროლის აღდგენა, ჯგუფებზე მიკუთვნება, MFA-ში რეგისტრაცია, კავშირის უფლებები და აუდიტის კვალი, რომელიც პასუხობს, ვინ და როდის დაუკავშირდა. Community Edition ამათგან არცერთს არ იძლევა პირდაპირ. თქვენ ირჩევთ აუთენტიფიკაციის ბექენდს, PAM-ს, LDAP-ს ან RADIUS-ს უერთებთ დანამატის ან auth-user-pass-verify-ის მეშვეობით, და დანარჩენს თავად ინარჩუნებთ. Access Server აწვდის მომხმარებლის პორტალს, ადმინისტრაციის კონსოლს და ინტეგრაციებს გავრცელებულ იდენტობის მომწოდებლებთან. არც ერთი წყობა არ არის ნაგულისხმევად უფრო უსაფრთხო, რადგან პოლიტიკა მაინც იმ ადამიანმა უნდა დაწეროს, ვინც ქსელს იცნობს.

უფლებები ყველაზე მწვავე ოპერაციული განსხვავებაა. Access Server ერთდროული კავშირების რაოდენობით იძლევა ლიცენზიას და ამ რაოდენობას პროგრამულად აღასრულებს. Community Edition-ში გლობალური ზღვარი ერთი max-clients ხაზია, ხოლო მომხმარებლის ან ჯგუფის მიხედვით ნებისმიერი რამ ნიშნავს მეტ client-config-dir სამუშაოს და თქვენივე აღსრულებას. გუნდი, რომელსაც ამ მოვლის სურვილი არ აქვს, ზუსტად ამას ყიდულობს, როცა კომერციულ პროდუქტს იხდის.

ლიცენზირება და მხარდაჭერა: ხაზი, რომელსაც არავინ ბიუჯეტში არ დებს

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

მხარდაჭერის საკუთრება იმავე გაყოფას მიჰყვება. Community Edition-ით თქვენ ხართ ესკალაციის გზა ყოველი უცნაური კლიენტისა და ყოველი ბირთვის განახლებისთვის. Access Server-ით გყავთ გამყიდველი, რომელსაც დაურეკავთ, და მემკვიდრეობით იღებთ მისი გამოშვებების რიტმს, მოერგოს ის თქვენს ცვლილებების ფანჯარას თუ არა.

შემოწმებები გადასვლამდე

სანამ რომელიმე მიმართულებით გადახვიდეთ, დაინვენტარიზეთ, რას ინახავს რეალურად მომუშავე სერვერი. Access Server-ის მხარეს გაიტანეთ მომხმარებელთა სია და ჯგუფების მიკუთვნებები და აღნიშნეთ, რომელი ანგარიშები არიან MFA-ზე დამოკიდებული. Community Edition-ის მხარეს ჩამოთვალეთ გაცემული სერტიფიკატები, CRL და client-config-dir-ის ქვეშ არსებული ყოველი ფაილი. შეადარეთ ორი სია სტრიქონ-სტრიქონ, რადგან მათ შორის სხვაობა სწორედ მიგრაციის სამუშაოა.

სცადეთ წარმომადგენლობითი კლიენტები, სანამ ძველი სერვისი ჯერ კიდევ მუშაობს. openvpn --config client.ovpn --verb 4 წინა პლანზე ბეჭდავს ხელის ჩამორთმევას, გაგზავნილ მარშრუტებსა და DNS პარამეტრებს, ხოლო openssl x509 -in client.crt -noout -subject -enddate აჩვენებს, რომელ სერტიფიკატს წარადგენს კლიენტი რეალურად. კლიენტს, რომელიც უკავშირდება, მაგრამ შიდა ჰოსტს ვერ აღწევს, აქვს მარშრუტის ან iroute-ის ღრმული და არა აუთენტიფიკაციის მარცხი.

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