SSTP და IKEv2 სხვადასხვა RRAS სერტიფიკატის კონტროლს იყენებენ

თუ შეცვლით „VPN სერტიფიკატს“, შესაძლოა არასწორი სერვისი შეცვალოთ. RRAS ინახავს სულ მცირე სამ სერტიფიკატის კონტროლს და თითოეული მათგანი სხვადასხვა პროტოკოლსა და სხვადასხვა კავშირის როლს ეკუთვნის. პროტოკოლის პირველად დასახელება რისკიან ვარაუდს ერთ, შექცევად მიბმის ცვლილებად აქცევს. ყველაფერი ქვემოთ ამ ერთი წინადადებისგანაა დამოკიდებული.

დაასახელეთ პროტოკოლი სერტიფიკატამდე

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

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

SSTP HTTPS-მიბმაა

მხარდაჭერილ Remote Access განლაგებებში Set-RemoteAccess ავლენს SslCertificate პარამეტრს, რომელიც გამოიყენება SSTP კავშირისთვის და HTTPS-თან დაკავშირებული DirectAccess როლისთვის.

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

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

შემავალ IKEv2-ს საკუთარი პარამეტრი აქვს

Set-VpnAuthProtocol აკონფიგურირებს შემავალ საიტ-საიტ IKEv2 აუთენტიფიკაციას, ხოლო CertificateAdvertised სერტიფიკატს აწვდის, როცა გვირაბის აუთენტიფიკაციის რეჟიმი მათ იყენებს. ეს არ არის ზოგადი ბრძანება ჰოსტზე ნებისმიერი სერვერის სერტიფიკატის ასარჩევად.

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

ცალკეული საიტ-საიტ ინტერფეისის იდენტობა დგინდება Set-VpnS2SInterface-ის მეშვეობით. ეს ავტომატურად SSTP სერტიფიკატი არ არის, თუნდაც ორივე ერთსა და იმავე საცავში იყოს იმავე მანქანაზე.

ჯერ შეამოწმეთ კანდიდატი

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

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

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

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

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

განახლება გააქტიურება არ არის

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

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

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