Azure P2S DNS ვერ მუშაობს, როცა resolver დაწყვილებულ VNet-შია

გაუშვით ping VM-ზე და ის გპასუხობს; ჰკითხეთ მისი სახელი და კლიენტი ამბობს, რომ ჰოსტი უცნობია. როცა resolver დაწყვილებულ ვირტუალურ ქსელშია და არა იმ ქსელში, რომელიც VPN gateway-ს შეიცავს, შედეგების ეს წყვილი მოსალოდნელია და resolver-ის არავითარი დიაგნოსტიკა ამას არ ცვლის. რაც აკლია, არის მარშრუტიზაციის ხელშეკრულება, რომელსაც peering ნაგულისხმევად ინახავს. ორი ტოპოლოგია ქაღალდზე თითქმის იდენტურად გამოიყურება, და სხვაობა მომუშავესა და გატეხილს შორის სწორი მიმართულებით დაყენებული peering-გადამრთველების წყვილია.

წარმოიდგინეთ ლეპტოპი, რომელიც გვირაბს აკეთებს VNet2-ის gateway-ში, ხოლო DNS-ს მომსახურე დომენის კონტროლერი VNet1-ში ზის.

ორი ტოპოლოგია, ერთი განსხვავება

მოათავსეთ resolver თავად gateway-ის ვირტუალურ ქსელში და სახელი გადაიჭრება გვირაბის აწევის წამს. არც ერთი peering-პარამეტრი არ მონაწილეობს ამ ძიებაში.

გადაიტანეთ იგივე resolver peering-ის მეორე მხარეს და კლიენტი მაინც იღებს პასუხს VM-დან, სანამ სახელი უცნობი რჩება. სერტიფიკატი, გვირაბი და კლიენტი უცვლელია. ერთადერთი, რაც გადაადგილდა, არის ის, სად ცხოვრობს resolver. peering-მა მას მისცა მარშრუტი ამ მისამართამდე, და არა gateway-ს უფლება იქ ტრაფიკი გადაიტანოს.

მხარე A: დაუშვით gateway-ის ტრანზიტი gateway-ის მფლობელთან

peering ორ ვირტუალურ ქსელს აერთებს, მაგრამ ეს შეერთება გარდამავალი არ არის gateway-ის გავლით მომავალი ტრაფიკისთვის, და point-to-site მოთხოვნა ზუსტად ასე მოდის. ამიტომ VNet2-ის gateway-ს არ აქვს უფლება ძიება VNet1-ს გადასცეს, სანამ დიზაინი ამას არ დაუშვებს. ნებართვა არის გადამრთველი peering-ზე, რომელიც ეკუთვნის gateway-ის შემცველ ქსელს.

დააყენეთ Allow gateway transit VNet2-იდან VNet1-ისკენ მიმართულ peering-ზე. ეს თვისება peering-ის ობიექტს ეკუთვნის და არა gateway-ის რესურსს, ამიტომ მას peering-ის დანაში კითხულობთ და ცვლით. ეს არის მთელი მხარე A.

მხარე B: გამოიყენეთ დისტანციური gateway-ები პარტნიორზე

მეორე ნახევარი სარკისებრი ანარეკლია: VNet1-იდან VNet2-ისკენ უკანა peering-ზე ჩართეთ Use remote gateways. იმავე დროშის ჩართვა ორივე ბოლოში, ან მხოლოდ ერთში, ტოვებს ნახევრად აშენებულ გზას და საწყის სიმპტომს ხელუხლებლად. ტრანზიტს მხოლოდ VPN gateway-ის მქონე ქსელი უშვებს, და პარტნიორი ის მხარეა, რომელიც მას იყენებს.

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

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

წყვილის გვერდიგვერდ დანახვა ყველაზე სწრაფი გზაა შებრუნებული პარამეტრის დასაჭერად. peering, რომელიც gateway-ის მხარეს აცხადებს AllowGatewayTransit false-ს, მთელ ხარვეზს ხსნის პაკეტის დაჭერის გარეშე.

რა უნდა მიიღოს კლიენტმა მაინც

მარშრუტიზაცია აუცილებელია და არ არის საკმარისი, რადგან point-to-site პროფილმა კლიენტს უნდა მისცეს DNS მისამართიც, რომელიც პასუხობს ტრანზიტის მუშაობის შემდეგ. პლატფორმის resolver არ არის ის მისამართი: ის პასუხობს ვირტუალურ ქსელთან დაკავშირებულ Azure Private DNS ზონებზე, მაგრამ არაფერს თქვენს საკუთარ დირექტორიის სერვერებზე განთავსებულ ზონაზე, და სწორედ ამას იყენებს ეს განლაგება. მიმართეთ კლიენტი მასზე და საჯარო სახელები სიხარულით გადაიჭრება, ხოლო შიდა ჰოსტი უცნობი რჩება.

ჰკითხეთ resolver-ს დაკავშირებული ლეპტოპიდან, სანამ სხვა რამეს შეცვლით.

nslookup dc01.corp.example 10.1.0.4

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

შეადარეთ იგივე ხელშეკრულება site-to-site მხარეს

ამიდან არაფერია განსაკუთრებით ლეპტოპებისთვის. ჩაანაცვლეთ კლიენტი site-to-site-ის ფილიალით და ორმხრივი მოთხოვნა ბრუნდება: ფილიალი პირდაპირ gateway-ის ქსელში მოდის, და ორი ქსელის მოშორებით მდებარე სერვისი კვლავ peering-ის უკანაა.

ტრანზიტი ორივე peering-ზე უნდა მიენიჭოს, და გადამრთველი, რომელიც მას იძლევა, peering-ზე ცხოვრობს და არა კლიენტის ტიპზე.

სანამ gateway-ს დაადანაშაულებთ

Windows ინახავს resolver-ების სიას თითო ადაპტერზე, ამიტომ დაადასტურეთ, რა მიიღო სინამდვილეში გვირაბის ინტერფეისმა, სანამ gateway-ს დაადანაშაულებთ.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

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

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