Azure-ის კერძო IP VPN ExpressRoute-ზე NVA-ს გარეშე

მითი არის ის, რომ ExpressRoute-ის კერძო peering-ზე ტრაფიკის დაშიფვრას სჭირდება ვირტუალური ქსელური მოწყობილობა. არ სჭირდება. Azure მხარს უჭერს Site-to-Site VPN Gateway-ს, რომლის გვირაბის ბოლო წერტილი კერძო RFC1918 მისამართია, რომელიც წრედის გავლით გადაიტანება, და მოწყობილობა არჩევითია და არა სტრუქტურული. რასაც მოწყობილობის მითი მალავს, ის ნაწილია, რომელიც ნამდვილად კბენს: კერძო ბოლო წერტილის ჩართვა ერთ ობიექტზე ორის ნაცვლად, და იმის დაშვება, რომ პირდაპირმა peering მარშრუტმა ჩუმად მოიგოს დაშიფრულ გზაზე.

საიდან გაჩნდა მითი

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

ამიდან არაფერი არ აპენსიებს NVA-ს. ის აპენსიებს ვარაუდს, რომ მოწყობილობა მოთხოვნისადმი ერთადერთი გზაა.

ჩართეთ კერძო ბოლო წერტილი ორივე დონეზე

დაიწყეთ მუშა ExpressRoute კერძო peering კავშირით, რომელიც დაკავშირებულია VNet-თან, სადაც VPN კარიბჭეა. ლოკალურ მხარეს უკვე უნდა ჰქონდეს წვდომა შესაბამის კერძო მისამართებზე ამ წრედის გავლით, რადგან გვირაბი ამ მისამართებს ტრანსპორტად გამოიყენებს. შემდეგ კარიბჭის წინაპირობა: Microsoft-ის პროცედურა კერძო IP VPN-ისთვის მოითხოვს Standard საჯარო IP რესურსზე აგებულ კარიბჭეს. კერძო გვირაბის მისამართება არ აუქმებს ამ მოთხოვნას, რაც აკვირვებს მათ, ვინც ფიქრობს, რომ „კერძო“ ნიშნავს „არსად საჯარო IP“.

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

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

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

მეორე მითი: დამყარებული გვირაბი შიფრავს თქვენს ტრაფიკს

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

დოკუმენტირებული მიმართვის მეთოდებია დამფარავი დიაპაზონი ExpressRoute-ზე და უფრო კონკრეტული დაცული დიაპაზონი VPN-ზე, ან განცალკევებული პრეფიქსები ორ გზაზე. მაგალითად, კერძო peering-ს შეუძლია ატაროს 10.40.0.0/16, ხოლო VPN აცხადებს 10.40.12.0/24. უფრო კონკრეტული პრეფიქსი იმარჯვებს და დიაპაზონის დარჩენილი ნაწილი პირდაპირ რჩება.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

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

გადაწყვიტეთ რა მოხდება, როცა გვირაბი ვარდება

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

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

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