რატომ სჭირდება წერტილიდან საიტამდე კავშირს მარშრუტზე დაფუძნებული Azure VPN კარიბჭე
პოლიტიკაზე დაფუძნებულ კარიბჭეს არ აქვს გვირაბის ინტერფეისი კლიენტის მარშრუტებისთვის. რა უნდა აშენდეს თავიდან, რა თანმიმდევრობით და რომელი შეზღუდვები გადარჩება ჩანაცვლებას.
პოლიტიკაზე დაფუძნებული კარიბჭე აშენებს IPsec გვირაბს, რომელსაც ტრაფიკის სელექტორები ირჩევენ, და მას არ აქვს ინტერფეისი კლიენტის მარშრუტების გადასაცემად. წერტილიდან საიტამდე კავშირი მარშრუტიზაციის ფუნქციაა: კარიბჭეს აქვს კლიენტის მისამართების აუზი და ვირტუალურ ქსელში ამ კლიენტებისკენ მარშრუტებს აყენებს. სწორედ ეს შეუსაბამობაა მიზეზი, რომ პორტალი მისი დამატების არცერთ ვარიანტს არ აჩვენებს. არსებულ კარიბჭეზე ვერაფერს გადართავ ისე, რომ ინტერფეისი შეიქმნას, ამიტომ ცვლილება ჩანაცვლებაა და არა კონფიგურაციის რედაქტირება.
თანმიმდევრობა ცალკეულ ნაბიჯებზე მნიშვნელოვანია. თუ რიგითობას შეცდები, საიტებს შორის შეწყვეტა ტექნიკური მომსახურების ფანჯარას გასცდება.
რას აკეთებს სინამდვილეში პოლიტიკაზე დაფუძნებული კარიბჭე
პოლიტიკაზე დაფუძნებული კარიბჭე პაკეტებს ადარებს კავშირზე კონფიგურირებულ ტრაფიკის სელექტორებს და დამთხვევებს ერთ გვირაბში აგზავნის. არ არსებობს მისამართიანი გვირაბის ინტერფეისი და ვირტუალურ ქსელში არსად არ ჩანს მარშრუტი თითოეული კლიენტისთვის. მარშრუტების ცხრილი უბრალოდ იღებს კარიბჭეზე მიმთითებელ ლოკალურ პრეფიქსებს. ეს მოდელი საკმარისია ორ მუდმივ მისამართთა სივრცეს შორის საიტებს შორის კავშირისთვის.
მარშრუტზე დაფუძნებული კარიბჭე პირიქით მუშაობს: ის გვირაბის ინტერფეისს წარმოადგენს და მარშრუტები წყვეტენ, რა შედის მასში. წერტილიდან საიტამდე კავშირი და ნებისმიერი დიზაინი, რომლის პარტნიორთა ნაკრები იცვლება, ამ ინტერფეისის არსებობაზეა დამოკიდებული.
რატომ სჭირდება კლიენტის აუზს ეს ინტერფეისი
როცა ლეპტოპი უერთდება, კარიბჭე მას წერტილიდან საიტამდე აუზიდან მისამართს ანიჭებს. შემდეგ ვირტუალურ ქსელს სჭირდება მარშრუტი, რომელიც ამბობს, რომ ეს მისამართი კარიბჭის გავლით ხელმისაწვდომია. გვირაბის ინტერფეისის გარეშე არაფერია, რასაც ეს მარშრუტი მიუერთდება.
აუზი მოდის თქვენ მიერ განსაზღვრული დიაპაზონიდან და კარიბჭე იქიდან ანაწილებს. თუ ეს დიაპაზონი ემთხვევა ლოკალურ ქსელს ან დაწყვილებულ ვირტუალურ ქსელს, კონფლიქტი მხოლოდ კლიენტის მიერთების შემდეგ გამოვლინდება, რაც მის აღმოსაჩენად ცუდი მომენტია. დაჯავშნეთ აუზი მიგრაციის დაწყებამდე.
ტიპიც არ არის კავშირზე დამოკიდებული პარამეტრი. ერთ კარიბჭეს ერთი ტიპი აქვს და ყოველი კავშირი, რომელსაც ის ინახავს, შესაბამისად იქცევა, ამიტომ შერეულ დიზაინს მეორე კავშირი კი არა, მეორე კარიბჭე სჭირდება.
ტიპი შექმნისას ფიქსირდება
Microsoft აცხადებს, რომ ვირტუალური ქსელის კარიბჭის ტიპს განლაგების შემდეგ ვერ შეცვლი პოლიტიკაზე დაფუძნებულსა და მარშრუტზე დაფუძნებულს შორის. არ არსებობს კონვერტაციის ბრძანება და პორტალში გადამრთველი. მეორე კარიბჭის შექმნა იმავე ქვექსელში არც გვერდის ავლაა, რადგან Azure თითო ვირტუალურ ქსელზე ერთ კარიბჭეს უშვებს. ამიტომ მიგრაციაა წაშლა, თავიდან აშენება და ხელახლა დაკავშირება.
ეს SKU-ს გადაწყვეტილებასაც იმავე მშენებლობაში აქცევს. მოგვიანებით უფრო დიდ SKU-ზე გადასვლა კიდევ ერთი კარიბჭის ჩანაცვლებაა კიდევ ერთი შეწყვეტით.
ერთი კარიბჭე, ერთი GatewaySubnet
კარიბჭე ცხოვრობს GatewaySubnet-ის სახელობის ქვექსელში და მას მხოლოდ ერთი კარიბჭე იკავებს. ამ ქვექსელის ზომის განსაზღვრა მომზადების ნაწილია, რადგან უფრო დიდ SKU-ს მეტი მისამართი სჭირდება და ქვექსელს მოგვიანებით ვერ შეამცირებ. ჩაწერეთ მიმდინარე საიტებს შორის პარამეტრები, საერთო გასაღები, ლოკალური ქსელის კარიბჭე და ეფექტური მარშრუტები, სანამ რამეს შეეხებით. შემდეგ ფანჯარას შეწყვეტად მოეკიდეთ, რადგან საიტებს შორის გვირაბი გამორთული რჩება, სანამ ახალი კავშირი არ დაკონფიგურირდება.
თავიდან აშენების რიგი, რომელიც შეწყვეტას ზღუდავს: შექმენით მარშრუტზე დაფუძნებული კარიბჭე, თავიდან შექმენით საიტებს შორის კავშირი იმავე ლოკალური ქსელის კარიბჭესთან, დაადასტურეთ გვირაბი და ერთი ჰოსტიდან ჰოსტამდე მოთხოვნა და მხოლოდ ამის შემდეგ დაამატეთ წერტილიდან საიტამდე კავშირი და შექმენით ახალი კლიენტის პაკეტი.
რას არ ასწორებს ჩანაცვლება
მეორე შეზღუდვა პარტნიორს ეკუთვნის და არა Azure-ს. პოლიტიკაზე დაფუძნებულ ლოკალურ მოწყობილობას მხოლოდ იმ ვირტუალურ ქსელზე შეუძლია მიღწევა, რომელსაც უერთდება, და ვერ გაივლის სხვა ლოკალურ ქსელებში ან სხვა ვირტუალურ ქსელებში იმავე კარიბჭით. Azure-ის მხარის ჩანაცვლება არ ცვლის იმას, რისი არჩევაც პარტნიორს შეუძლია.
თუ მოთხოვნა ნამდვილად საიტებს შორის გავლა არის, პასუხია მარშრუტზე დაფუძნებული პარტნიორი მოწყობილობა ან ტოპოლოგია, სადაც თითოეული დანიშნულება ცალკე მთავრდება. თარიღის დაპირებამდე ეს გადაწყვიტეთ, რადგან მხოლოდ კარიბჭის ჩანაცვლება ამას არ მოგცემთ.
ოპერაციებისა და შემოწმებების რიგი
თითოეული შესაძლებლობა ცალკე გადაამოწმეთ. პირველ რიგში საიტებს შორის გვირაბის მდგომარეობა და ერთი ჰოსტიდან ჰოსტამდე მოთხოვნა, შემდეგ წერტილიდან საიტამდე კავშირი და ერთი კერძო რესურსი, შემდეგ ნებისმიერი გავლის გზა, რომელსაც დიზაინი აცხადებს. მწვანე კარიბჭის სტატუსი მხოლოდ იმას ადასტურებს, რომ უსაფრთხოების ასოციაცია ავიდა და მეტს არაფერს. შეინახეთ შემოწმებები ამ რიგში, რომ ჩავარდნამ მიუთითოს იმ ეტაპზე, რომელმაც ის შემოიტანა.
ნებისმიერი ტოპოლოგიური ცვლილების შემდეგ თავიდან შექმენით კლიენტის პაკეტები და აუზი შორს დაიჭირეთ ყოველი ლოკალური და დაწყვილებული დიაპაზონისგან. შეზღუდვები და SKU-ს განსხვავებები თავმოყრილია Azure VPN Gateway-ის პარამეტრების ცნობარში.