AWS Client VPN თუ VPN EC2-ზე: ოპერირების სახელმძღვანელო

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

ნაბიჯი 1: დაწერეთ მოთხოვნა ანგარიშამდე

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

იყავით კონკრეტული დანიშნულებებთან დაკავშირებით. «VPC-ზე წვდომა» ჩვეულებრივ სამ სხვადასხვა რამეს ნიშნავს: VPC-ის CIDR-ს, დაწყვილებულ ქსელს და ლოკალურ დიაპაზონს Transit Gateway-ის უკან. მართული საბოლოო წერტილი სამივეს აღწევს, მაგრამ თითოეულს სჭირდება მარშრუტი და ავტორიზაციის წესი, და თითოეული ცალკე სტრიქონია თქვენს მოთხოვნაში.

ნაბიჯი 2: ჩამოთვალეთ, რაც უკვე მუშაობს

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

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

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

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

ნაბიჯი 3: გაყავით პასუხისმგებლობები

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

საკუთარი ჰოსტინგი ამას აბრუნებს. თქვენ ფლობთ სტუმარ ოპერაციულ სისტემას, VPN დემონს და მის კონფიგურაციას, სერტიფიკატებსა და გასაღებებს, სარეზერვო ასლებს, მონიტორინგსა და აღდგენას. EC2-ის უსაფრთხოების მოდელი სტუმრისა და აპლიკაციის უსაფრთხოებას მომხმარებელზე აკისრებს, VPN სერვერი კი სტუმარია, როგორც ნებისმიერი სხვა.

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

ნაბიჯი 4: შეადარეთ აღწერად სამუშაო დატვირთვას

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

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

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

ნაბიჯი 5: გადადით უკვე გამოცდილი უკან დაბრუნებით

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

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

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