რატომ მოითხოვს Client VPN-ის სერტიფიკატის ხელახლა იმპორტი ახალ საბოლოო წერტილს

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

საბოლოო წერტილი ინახავს მითითებებს, არა სერტიფიკატებს

მექანიზმი ზუსტად უნდა ჩამოვაყალიბოთ, რადგან ის ხსნის მთელ ხარვეზს. create-client-vpn-endpoint იღებს სერვერის სერტიფიკატის ARN-ს და კლიენტის ფესვური სერტიფიკატების ჯაჭვის ARN-ს, და მიღებული საბოლოო წერტილი ინახავს ამ მითითებებს ავთენტიფიკაციის პარამეტრებთან ერთად როგორც ფიქსირებულ თვისებებს. API არ გვთავაზობს ოპერაციას, რომელიც შეცვლის სერვერის სერტიფიკატს არსებულ საბოლოო წერტილზე.

კავშირის დადასტურება გამოცნობის გარეშე შეგიძლიათ. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 ბეჭდავს სერტიფიკატის ARN-ს, კლიენტის ფესვური ჯაჭვის ARN-ს, ავთენტიფიკაციის ტიპს, კლიენტის CIDR-ს და დაკავშირებულ ქვექსელებს, რაც იმ თვისებების სრული ნაკრებია, რომელთა ხელახლა შექმნაც დაგჭირდებოდათ. გაუშვით ის ხელახლა იმპორტამდე და შემდეგ და გამოსავალი არ იძვრება. ეს არის მტკიცებულება, რომ ხელახლა იმპორტი ვერასოდეს დაეხმარებოდა.

რატომ ვერ აღწევს ხელახლა იმპორტი საბოლოო წერტილამდე

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

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

ჯაჭვი კლიენტის სერტიფიკატის ნაწილია

ხარვეზის მეორე ნახევარი კლიენტის სერტიფიკატშია და მისი უგულებელყოფა უფრო ადვილია. კლიენტის სერტიფიკატი უნდა იმპორტირდეს იმ ჯაჭვთან ერთად, რომელმაც ის გამოსცა, თუმცა იმპორტის ფორმა ამ ველს არასავალდებულოდ აჩვენებს. ჯაჭვის გარეშე საბოლოო წერტილი ვერ ააგებს გზას კლიენტის სერტიფიკატიდან იმ კლიენტის ფესვურ CA-მდე, რომლითაც ის კონფიგურირებულია, და კავშირი მთავრდება რბილი გადატვირთვით, რომელიც პაკეტების ჩამომვარდებელ ფაირვოლს ჰგავს. openssl verify -CAfile root-ca.pem client.crt ამ კითხვას ლოკალურად ერთ წამში პასუხობს და ის პირველი ბრძანება უნდა იყოს, რომელსაც გაუშვებთ.

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

საბოლოო წერტილის ხელახლა შექმნა მიგრაციაა

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

თანმიმდევრობა, რომელიც ამას უსაფრთხოს ხდის, მოკლეა: შექმენით ახალი საბოლოო წერტილი იგივე CIDR-ით, ქვექსელებით და ავტორიზაციის წესებით, ექსპორტში გაიტანეთ ახალი პროფილი aws ec2 export-client-vpn-client-configuration-ით და შეამოწმეთ ერთი მომხმარებლით. მხოლოდ ამის შემდეგ ჩამოდის ძველი საბოლოო წერტილი.

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

დაალაგეთ დიაგნოსტიკა

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

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

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