Azure UDR VPN კარიბჭისკენ: ერთი დანიშნულება და არა მთელი გასასვლელი

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

შემდეგი ნახტომი კარიბჭეა, არა მოწყობილობის IP

UDR აგზავნის შესაბამის პრეფიქსს შემდეგი ნახტომის ტიპზე, ხოლო VirtualNetworkGateway ტიპია და არა მისამართი. ადამიანები კარიბჭის კერძო IP-ს აკრავენ VirtualAppliance მარშრუტში და შემდეგ ფიქრობენ, რატომ არაფერი ემთხვევა, რადგან ეს ტიპი სამაგიეროდ NIC-ს ან შიდა დატვირთვის ბალანსირებას ელოდება. Microsoft-ის მარშრუტიზაციის დოკუმენტაცია ასევე ზღუდავს კარიბჭის შემდეგ ნახტომს იმ ვირტუალურ ქსელით, რომლის კარიბჭეც VPN კარიბჭეა. ExpressRoute, Route Server და Virtual WAN ჰაბი ამ ვარიანტით არ მისამართდება.

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

წაიკითხეთ მოქმედი მარშრუტი, სანამ რამეს შეცვლით

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

ჯერ შეხედეთ მოქმედ ცხრილს, შემდეგ გადაწყვიტეთ, მარშრუტს ამატებთ თუ ერთს ცვლით:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

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

დაწერეთ მარშრუტი რეალური პრეფიქსისა და ქვექსელის მიხედვით

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

შექმენით მარშრუტი, შემდეგ დაუკავშირეთ ცხრილი ქვექსელს, რომელიც დატვირთვას მასპინძლობს:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

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

დაასრულეთ ლოკალური ნახევარი, თორემ ნაკადი იქ მოკვდება

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

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

სელექტორები და ნებადართული სიები ყოველივე ამისგან განცალკევებულია. Azure-ის შემდეგი ნახტომის არჩევა არ აფართოებს VPN ტრაფიკის სელექტორებს და არ ცვლის გარე სერვისის წყაროს ნებადართულ სიას.

გადაამოწმეთ დანიშნულების მიერ დანახული წყაროთი

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

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