FortiGate Azure გასაღების განახლება: peer SA შეთავაზება არ ემთხვევა ლოკალურ პოლიტიკას
მომუშავე IKEv2 გვირაბმა მაინც შეიძლება უარყოს შემცვლელი CHILD SA. შეადარეთ ის შეთავაზება, რომელზეც განახლება რეალურად აწარმოებს მოლაპარაკებას, და არა ის, რომელიც პირველმა ping-მა გამოიყენა.
გვირაბი ამოვიდა, ტრაფიკი გაიარა და მოგვიანებით ჟურნალი ამბობს peer SA proposal not match local policy. ადამიანების უმეტესობა ამ ხაზს კითხულობს როგორც მტკიცებას, რომ ორი კონფიგურაცია არასოდეს დამთხვეულა. ჩვეულებრივ ის უფრო ვიწრო რამეს ნიშნავს: ისინი დაემთხვნენ პირველი CHILD SA-სთვის და შეწყვიტეს დამთხვევა პირველ განახლებაზე, რადგან პირველ ასოციაციას არასოდეს დასჭირდა ის გაცვლა, რომელსაც შემდეგები აკეთებენ. სწორედ ეს განსხვავება განსაზღვრავს, სად უნდა შეხედოთ.
პირველი CHILD SA მემკვიდრეობით იღებს, შემდეგები მოლაპარაკებას აწარმოებენ
IKEv2-ში საწყისი CHILD SA იქმნება IKE_AUTH-ის დროს და მისი გასაღებები გამომდინარეობს IKE SA-ის გასაღების მასალიდან. ამ მომენტში ცალკე Diffie-Hellman გაცვლა არ არსებობს, ამიტომ PFS ჯგუფი, რომელსაც ერთი peer ვერ მიიღებს, ჯერ უბრალოდ არ მოწმდება. გვირაბი ჯანსაღად გამოიყურება, რადგან ის მოთხოვნა, რომელზეც მოგვიანებით ჩავარდებით, არასოდეს შემოწმებულა.
CHILD_SA გასაღების განახლება სხვა შეტყობინებათა მიმდევრობაა. როცა PFS კონფიგურირებულია, peer-ები ახალ გასაღების გაცვლას ასრულებენ და უნდა შეთანხმდნენ ჯგუფზე, რომელსაც ორივე მხარე მიიღებს, ასევე ახალი ასოციაციის ESP შეთავაზებაზე. სწორედ ეს არის ის მომენტი, როცა შეუსაბამობა ხილული ხდება, და ამიტომ შეცდომა ასახელებს შეთავაზებას და არა მარშრუტს.
ამიტომ „გუშინ მუშაობდა“ შეთავაზებაზე არაფერს გეუბნებათ. ის ამბობს, რომ საწყისი გაცვლა წარმატებით დასრულდა, რაც უკვე იცოდით.
წაიკითხეთ წარუმატებელი გაცვლა და არა პირველი ping
სანამ რამეს შეცვლიდეთ, ორივე მხრიდან შეაგროვეთ წარმატებული IKE აუტენტიფიკაცია, საწყისი CHILD SA და წარუმატებელი ჩანაცვლება. შემდეგ ზუსტად დაასახელეთ ოპერაცია: IKE SA გასაღების განახლება, IKE ხელახალი აუტენტიფიკაცია და CHILD SA გასაღების განახლება სამი განსხვავებული მოვლენაა, და „ფაზა 2“ ყოველდღიურ საუბარში ყველას მოიცავს.
შეადარეთ ქვემოთ მოცემული ველები წარუმატებელი კავშირისთვის და არა გვირაბის ზოგადად.
| ფენა | შესადარებელი მნიშვნელობები |
|---|---|
| IKE | ვერსია, დაშიფვრა და მთლიანობა ან PRF განლაგება, DH ჯგუფი |
| IPsec / CHILD | ESP დაშიფვრა და მთლიანობა, განზრახული PFS ან გასაღების გაცვლის ჯგუფი |
| დაცული ტრაფიკი | ლოკალური და დისტანციური სელექტორები, ასევე პოლიტიკაზე დაფუძნებული ნებისმიერი სელექტორის პარამეტრი |
FortiGate-ზე გახსენით ამ გვირაბის ფაზა-2 შეთავაზება, PFS პარამეტრი და მიღებული DH ჯგუფები. წაიკითხეთ ჩატვირთული მნიშვნელობები, ნაცვლად იმისა, რომ ისინი ადრე დამყარებული კავშირიდან გამოიტანოთ. GUI გვერდის ეკრანის სურათი უფრო სუსტი მტკიცებაა, ვიდრე მოქმედი კონფიგურაცია, რადგან ორივე განახლების შემდეგ შეიძლება განსხვავდებოდეს. ექსპორტი გაუკეთეთ თქვენ მიერ შეცვლილ განყოფილებას და შეინახეთ ის ბილეთთან ერთად.
Azure-ის ნაგულისხმევი პოლიტიკა მაინც პოლიტიკაა
კავშირზე მიმაგრებული მორგებული პოლიტიკის არარსებობა არ ნიშნავს, რომ Azure არცერთს არ იყენებს. კავშირი უბრუნდება კარიბჭის ნაგულისხმევ შეთავაზებათა ნაკრებს, რომელიც შეიძლება იყოს უფრო ფართო ან ვიწრო, ვიდრე თქვენი FortiGate-ის მიერ შეთავაზებული. თუ ორივე ნაკრები ემთხვევა IKE-ს, მაგრამ არა ESP-ს PFS-ით, თქვენ მიიღებთ ზუსტად ამ წარუმატებლობის ნიმუშს.
ეს მხოლოდ-კითხვადი ხედი აჩვენებს რეალურად მიმაგრებულ პოლიტიკას საიდუმლოებების გამჟღავნების გარეშე:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesგამოიყენეთ თქვენი რეალური რესურსების სახელები. როდესაც აშკარა პოლიტიკაა საჭირო, დააყენეთ ის კავშირის რესურსზე. ეს არ არის მთელი კარიბჭის გადამრთველი და ჩუმად არ ვრცელდება იმავე კარიბჭის სხვა გვირაბებზე.
პორტალში, Configuration გვერდია ის ადგილი, სადაც მორგებული IPsec/IKE პოლიტიკა უნდა განთავსდეს. Microsoft-ის მორგებული პოლიტიკების სახელმძღვანელო ჩამოთვლის მხარდაჭერილ პარამეტრებსა და SKU მოთხოვნებს. Azure თითო კავშირზე იღებს ერთ სრულ კომბინაციას, ამიტომ IKE ველებს და IPsec ველებს ერთად მიუთითებთ და არა სათითაოდ.
PFS მოთხოვნაა და არა გადასაბრუნებელი გადამრთველი
თუ თქვენი უსაფრთხოების საბაზისო ხაზი PFS-ს მოითხოვს, გადაწყვეტა არის ჯგუფი, რომელსაც ორივე peer ორივე მხრიდან მიიღებს, გამოხატული შესაბამისი პოლიტიკით. PFS-ის გამორთვა იმისთვის, რომ შეცდომა გაქრეს, ცვლის იმ უსაფრთხოების თვისებას, რომლის შენარჩუნებასაც ცდილობდით, და ის ჩვეულებრივ მოგვიანებით სხვა შეუსაბამობის სახით ბრუნდება.
Azure-ისთვის დამახასიათებელი ერთი ხაფანგი: როცა ESP-სთვის GCM-ს ირჩევთ, დაშიფვრისა და მთლიანობის არჩევანმა უნდა დაასახელოს იგივე GCM ალგორითმი და იგივე გასაღების სიგრძე. GCM შიფრის ცალკე მთლიანობის ალგორითმთან შერევა იძლევა კომბინაციას, რომელსაც სერვისი უარყოფს, და ეს peer-ებს შორის შეუსაბამობას ჰგავს, სანამ პოლიტიკას ყურადღებით წაიკითხავთ.
აირჩიეთ ყველაზე ძლიერი კომბინაცია, რომელსაც ორივე მხარე უჭერს მხარს და თქვენი მოთხოვნა იძლევა საშუალებას, შემდეგ ჩაწერეთ ის ცვლილებათა ჩანაწერში. შემდეგი ადამიანი ამ ჩანაწერს შეადარებს და არა მომუშავე გვირაბის მოგონებას. მასში ჩაწერეთ PFS ჯგუფი და ESP შეთავაზება და არა მხოლოდ პოლიტიკის სახელი. როცა მოგვიანებით ვინმე იკითხავს, რატომ ჩავარდა აუდიტი ან რატომ არის განახლება ნელი, ეს ხაზი ორივე კითხვას პასუხობს.
შეამოწმეთ წარუმატებელი გაცვლა
დაგეგმეთ ცვლილება აღდგენის გზით, რადგან პოლიტიკის რედაქტირებამ შეიძლება შეწყვიტოს ის გვირაბი, რომლის გამართვასაც ცდილობთ. ტრაფიკის დაბრუნების შემდეგ დაელოდეთ ან გამოიწვიეთ CHILD_SA განახლება და დაადასტურეთ, რომ ახალი ასოციაცია დამყარებულია განზრახული PFS ჯგუფით. შემდეგ დაადასტურეთ, რომ აპლიკაციის ტრაფიკი მასზე გრძელდება.
ორი ცრუ კვალის დასახელება ღირს. SA-ების სიცოცხლის ხანგრძლივობა ლოკალური სპეციფიკაციებია, ამიტომ არათანაბარი მნიშვნელობები ნორმალურია და მათი შეცვლა მხოლოდ იმას წევს, თუ როდის გამოჩნდება პრობლემა. DPD ადგენს, ცოცხალია peer თუ არა; მისი ვადის გაზრდა ESP ან PFS არჩევანს არ ათანაბრებს.
ჩაწერეთ მოლაპარაკებული შედეგი და ცვლილების შემდეგ შემდეგი მოვლენა. თუ კავშირი ახლა იშლება IKE აუტენტიფიკაციის დასრულებამდე, თქვენ უყურებთ ახლახან რედაქტირებულ IKE პარამეტრებს და არა თავდაპირველ CHILD განახლების ჩავარდნას.