IKEv2 Windows-სა და FortiGate-ში: სამი პარამეტრი, რომელსაც ადამიანები აერთიანებენ
IKE გასაღების გაცვლა, CHILD SA-ის დაცვა და პარტნიორის ავთენტიფიკაცია სამი ცალკე სტრიქონია. ორ დიალოგში ჯგუფის ნომრების დამთხვევა მათ არ აერთიანებს.
IKEv2 შეთანხმება Windows-ის კლიენტსა და FortiGate-ის კარიბჭეს შორის კვლავ ვერ სრულდება, და შეუსაბამო ნომრის ძიება კიდევ უფრო გრძელ ნომრების სიას ქმნის. სია მართვადი ხდება მხოლოდ მაშინ, როცა მას ყოფენ სამ სტრიქონად, რომლებიც დამოუკიდებლად ვარდება: IKE-ის დამცავი გასაღების გაცვლა, CHILD SA-ზე გამოყენებული დაცვა და ავთენტიფიკაცია, რომელიც ამტკიცებს, ვინ არის თითოეული მხარე. ჯგუფის ნომრები ამ სტრიქონებიდან ორში ჩნდება და სხვადასხვა რამეს ნიშნავს.
სამი სტრიქონი, რომლებიც დამოუკიდებლად ვარდება
პირველი სტრიქონი არის გასაღების გაცვლა თავად IKE-ის შიგნით, რომელიც ქმნის მოლაპარაკების დამცავ გასაღებებს. მეორე არის წინადადება CHILD SA-სთვის, რომელიც იცავს ტრაფიკს, რომელსაც გვირაბი გადააქვს. მესამე არის ავთენტიფიკაცია, რომელიც წყვეტს, რას წარადგენს თითოეული მხარე და როგორ ამოწმებს მას მეორე.
წარუმატებლობები სხვადასხვა ადგილას ხდება. გაცვლის წარუმატებლობა აჩერებს მოლაპარაკებას ჯერ კიდევ გვირაბის არსებობამდე. CHILD SA-ის წარუმატებლობა ხდება ავთენტიფიკაციის წარმატების შემდეგ, ზოგჯერ მხოლოდ გასაღებების განახლებისას. ავთენტიფიკაციის წარუმატებლობა ჟურნალებში შეიძლება გაცვლის წარუმატებლობას ჰგავდეს, თუ მხოლოდ პირველ შეცდომას კითხულობთ.
სტრიქონების გამოყოფა ბუღალტერია არ არის. ის ცვლის, რომელი პარამეტრი ღირს შეცვლად, და ხელს უშლის ამ მთელი სფეროს ყველაზე ძვირ ნაბიჯს, კერძოდ, მუშა სერტიფიკატების ხელახლა გენერირებას წინადადების შეუსაბამობის გამოსასწორებლად. ერთი სტრიქონის შეცვლამ არასოდეს უნდა აიძულოს დანარჩენი ორი შეიცვალოს. სწორედ ეს დამოუკიდებლობაა მათი ცალკე დაწერის მთელი აზრი.
რას აკონტროლებს Windows-ის ორი ველი
Windows ორ ველს ცალ-ცალკე ინახავს: DHGroup აკონფიგურირებს თავად IKE გაცვლას, ხოლო PfsGroup აკონფიგურირებს IPsec პოლიტიკას, რომელიც იცავს გვირაბის შიგნით ტრაფიკს. ისინი სხვადასხვა ფაზას ეკუთვნის. Windows-ის IKE ველის FortiGate-ის მე-2 ფაზის მნიშვნელობასთან შედარება არასწორ წყვილს ამოწმებს, და ნომრები შეიძლება დაემთხვეს, თუმცა ქვეშ მყოფი გაცვლა კვლავ ვარდება.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAმეორე და მესამე ბრძანება იტყობინება რეალურად არსებულ უსაფრთხოების ასოციაციებს, და ეს არის ყველაზე ახლოს იმ პასუხთან, რომელიც კლიენტს შეუძლია მოგცეთ. მთავარი რეჟიმის ასოციაცია სწრაფი რეჟიმის ასოციაციის გარეშე CHILD SA-ის პრობლემაა, და ეს მე-2 ფაზის შეუსაბამობის ნიშანია და არა სერტიფიკატის პრობლემის.
ჩაწერეთ, რა იყო შემოთავაზებული და რა არჩეული ერთ ცდაში. შემოთავაზებული სია, რომელიც შეიცავს მისაღებ წინადადებას, და არჩეული წინადადება, რომელიც არ შეესაბამება კარიბჭის პოლიტიკას, კონფიგურაციის უთანხმოებაა და არა თავსებადობის საიდუმლო.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
ელიფსური მრუდის ჯგუფი თქვენს ხელმოწერის გასაღებს არ ირჩევს
ამ სფეროში ყველაზე ჯიუტი მცდარი დასკვნაა, რომ ელიფსური მრუდის DH ჯგუფის არჩევა მოითხოვს ელიფსური მრუდის სერტიფიკატს. DH ჯგუფი გასაღების გაცვლის მასალას იძლევა; ხელმოწერის ალგორითმზე ავთენტიფიკაციის ჩარჩო მოლაპარაკებს, და ეს IKEv2-ში ორი ცალკე გადაწყვეტილებაა.
RFC 7427 სწორედ იმიტომ არსებობს, რომ ეს გადაწყვეტილებები ადრე გადაჯაჭვული იყო, და ის განსაზღვრავს, როგორ ცხადდება და ირჩევა ხელმოწერის ალგორითმები გასაღების გაცვლისგან დამოუკიდებლად. კარიბჭეს შეუძლია ერთდროულად მხარი დაუჭიროს მრუდის ჯგუფს და ხელმოწერის სქემების არჩევანს.
ამიტომ, როცა მოლაპარაკება ჯგუფის შეცვლის შემდეგ ვარდება, შეხედეთ ავთენტიფიკაციის მეთოდს, სანამ სერტიფიკატის გასაღების ტიპს შეხედავთ. სერტიფიკატის შეცვლა ნელი და სარისკო ოპერაციაა, რომელიც იშვიათად არის პასუხი, და მისი პირველად შესრულება ანადგურებს თქვენს უნარს გაიგოთ, რომელი ცვლილება დაეხმარა სინამდვილეში. წაიკითხეთ ავთენტიფიკაციის სტრიქონი, სანამ სერტიფიკატების საცავს შეეხებით.
შეინახეთ ორივე შეთანხმების ფურცლის ცალკე სტრიქონებში და შეცდომა შეწყვეტს მაცდურობას. ერთი სტრიქონი ჯგუფებს ჩამოთვლის, მეორე — ხელმოწერის სქემებსა და იდენტობებს, და არც ერთი არ არის მეორის მტკიცებულება.
მოათავსეთ თითოეული კერძო გასაღები მის ნამდვილ მფლობელთან
კარიბჭეს, რომელიც საკუთარ სერტიფიკატს წარადგენს, სჭირდება მისი შესაბამისი კერძო გასაღები. პარტნიორს, რომელიც ჯაჭვს ამოწმებს, სჭირდება CA სერტიფიკატი და კონკრეტულად არ სჭირდება CA-ის ხელმოწერის გასაღები. ამ სამი ელემენტის არევა არის გზა, რომლითაც ადამიანები CA-ის კერძო გასაღებს VPN მოწყობილობაში იმპორტს უკეთებენ, რომ სერტიფიკატი სხვა კატეგორიაში გამოჩნდეს.
FortiOS-ში როლები განსხვავებულია: ლოკალური სერტიფიკატი მისი გასაღებით, დისტანციური სერტიფიკატი პარტნიორის იდენტიფიცირებისთვის და დისტანციური CA ჩანაწერი, რომელიც ნდობას ამყარებს ამ CA-ის მიერ ხელმოწერილ სერტიფიკატებში. კერძო გასაღების გარეშე დისტანციური CA ჩანაწერი არ არის არასრული; ის სწორია თავისი დანიშნულებისთვის.
იმპორტირებული CA ხელმოწერის გასაღებები აფართოებს ნებისმიერი ადამიანის უფლებამოსილებას, ვისაც ამ მოწყობილობის წაკითხვა შეუძლია. ისინი ასევე არ ხსნიან ჩვეულებრივ პარტნიორის ვალიდაციას, რადგან ვალიდაციას სჭირდება საჯარო სერტიფიკატი და ნდობის გადაწყვეტილება, და არა ახალი სერტიფიკატების გაცემის უნარი.
შეინახეთ CA-ის ხელმოწერის გასაღები გამომცემლის საკუთარ პროცესთან და ჩაწერეთ, რომელი მოწყობილობა ინახავს რომელ გასაღებს. მფლობელთა მოკლე ცხრილი უფრო ღირებულია, ვიდრე ალგორითმების უფრო გრძელი ცხრილი, როცა აუდიტი იკითხავს, ვის შეეძლო ვის მიბაძვა. არავინ არ იმპორტავს გასაღებს, რომელზეც იცის, რომ მხოლოდ ინვენტარისთვისაა. დაწერეთ ინვენტარი ინციდენტამდე და არა შემდეგ.