Azure peering თუ VPN VNet-იდან VNet-ში? გადაწყვიტეთ მარშრუტიზაციამდე

Azure გაძლევთ ორი ვირტუალური ქსელის დაკავშირების სულ ცოტა ორ გზას და ეს არ არის ერთი და იმავე ობიექტის ურთიერთშემცვლელი პარამეტრები. Peering აერთიანებს VNet-ებს Microsoft-ის ხერხემალზე კარიბჭის გარეშე; VPN VNet-იდან VNet-ში აყენებს IPsec ურთიერთობას ორ კარიბჭეს შორის, რომლებსაც თქვენ ათავსებთ, ზომავთ და აკონტროლებთ. გადაწყვეტილება სამ პირობამდე მიდის და თუ მარშრუტის დამატებამდე სამივეს ვერ უპასუხებთ, თქვენ უგვირგვინო გზას აშენებთ იმ მოდელისთვის, რომელიც არასდროს აგირჩევიათ.

სამი პირობა, რომლებიც მოდელს განსაზღვრავს

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

ორივე მოდელს აერთიანებს მკაცრი მისამართების წესი: VNet-ების მისამართების სივრცეები არ უნდა გადაიფაროს. არც peering და არც VPN VNet-იდან VNet-ში არ არის ორი იდენტური დიაპაზონის ცალსახად ქცევის მხარდაჭერილი გზა, ხოლო გადაფარვა მოითხოვს რუკების დიზაინს ან გადაპროექტებას და არა სხვა ტიპის კავშირს.

პირობა 1: გჭირდებათ IPsec საზღვარი, რომელიც თქვენ გეკუთვნით?

Peering ტრაფიკს გადააქვს Azure-ის კერძო ხერხემალზე და არ მოითხოვს VPN კარიბჭეს თავად peered კავშირისთვის. ეს განცხადება ტრანსპორტზეა და არა დაშიფვრაზე, რომელიც აუდიტორს გადასცემთ როგორც «ჩვენ IPsec-ს ვამუშავებთ». თუ მოთხოვნა ასახელებს მომხმარებლის მიერ კონფიგურირებულ გვირაბს, კონკრეტულ IKE პოლიტიკას ან საზღვარს, რომელიც მთავრდება თქვენს კონტროლქვეშ არსებულ აღჭურვილობაზე, peering ამას არ აკმაყოფილებს, რამდენად კერძოც არ უნდა იყოს ხერხემალი.

VPN VNet-იდან VNet-ში ნამდვილად იძლევა ამ საზღვარს: ორი კარიბჭე, IPsec/IKE ურთიერთობა, საერთო გასაღებები და მთელი ოპერაციული ზედაპირი, რომელიც ამას მოჰყვება. თქვენ მემკვიდრეობით იღებთ გვირაბის მდგომარეობას, კარიბჭის სიმძლავრეს, SKU შეზღუდვებს და მონიტორინგს, რომელიც ამტკიცებს, რომ გვირაბი მუშაობს. ეს არის სწორი პასუხი, როდესაც მოთხოვნა სწორედ ამ საზღვარს ეხება, რომელიც peering-ის მიმოხილვაში აღწერილია როგორც peering-ისგან განსხვავებული კავშირის ტიპი.

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

პირობა 2: ტოპოლოგია პირდაპირია თუ რაღაცას გავლა სჭირდება?

Peering გამტარი არ არის. ჰაბზე peered ორი VNet ამით ერთმანეთთან დაკავშირებული არ ხდება და ერთი მიმართულებით მომუშავე ჩამოჩნდება მარშრუტი ჩვეულებრივ არის peering, რომელმაც Connected-ს მხოლოდ ერთ მხარეს მიაღწია. ორივე მხარე უნდა არსებობდეს და ორივემ უნდა აჩვენოს Connected, და ეს არის პირველი, რასაც ამოწმებთ, როცა ტრაფიკი ჩუმად ქრება.

თუ მოთხოვნა ჰაბის გავლით ლოკალურ ქსელზე წვდომაა, კარიბჭის გავლა ცალკე დიზაინია კონკრეტული როლებით: ჰაბი ფლობს კარიბჭეს, spoke-ის peering ნებას რთავს კარიბჭის გავლას და spoke-მა უნდა დაუშვას გადაგზავნილი ტრაფიკი. ეს peering-ის თვისებებია და არა VNet-ების დაკავშირების ავტომატური შედეგები:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

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

პირობა 3: ვის ეკუთვნის გამტარი გზა და ანგარიში?

ყოველ დამატებით ნახტომს ჰყავს მფლობელი. Peering-ის შემთხვევაში ახალი VNet ნიშნავს ახალ peering წყვილს ორივე მხარეს, ხოლო გავლისთვის — ჰაბს, რომელიც აგრძელებს ტრაფიკის გადაგზავნას, და მარშრუტების ცხრილს, რომელიც აგრძელებს მისკენ მითითებას. VPN-ის შემთხვევაში ახალი VNet ნიშნავს კიდევ ერთ კარიბჭეს ან კიდევ ერთ კავშირს არსებულზე, საკუთარი სიმძლავრის ჭერით, რომელსაც თვალყური უნდა ადევნოთ.

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

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

შეამოწმეთ არჩევანი მისივე მტკიცებასთან

დაწერეთ ერთი წინადადება, რომელიც ასახელებს მოდელს, საზღვარს და მფლობელს, შემდეგ შეამოწმეთ, რომ განლაგებული მდგომარეობა მას შეესაბამება. Peering-ისთვის ეს ნიშნავს, რომ ორივე peering მდგომარეობა Connected-ია, ეფექტური მარშრუტი აჩვენებს peering-ის შემდეგ ნახტომს სამიზნე პრეფიქსისთვის და გზაზე კარიბჭე არ არის. VPN VNet-იდან VNet-ში ეს ნიშნავს, რომ ორივე კავშირი Connected-ია, გასაღებები და პოლიტიკები ემთხვევა ორივე კარიბჭეზე და მარშრუტის შემდეგი ნახტომი ვირტუალური ქსელის კარიბჭეა.

თუ შემოწმებები წინადადებას ეწინააღმდეგება, ჯერ წინადადება გაასწორეთ. ამ დიზაინებში დაბნეულობის უდიდესი ნაწილი მოდის ჰიბრიდიდან, რომელიც არავის აღუწერია: peering სამუშაო დატვირთვის ქვექსელისთვის, VPN ერთი ძველი სერვისისთვის და მარშრუტების ცხრილი, რომელიც ჩუმად უპირატესობას ანიჭებს ერთ-ერთს.