თქვენი გაყოფილი გვირაბი აპს აღწევს, მაგრამ მის DNS სერვერს არა
გაყოფილ გვირაბს შეუძლია აპის ქვექსელის მარშრუტიზაცია და მაინც გვერდით მდგარი გამხსნელის მიტოვება. დაამატეთ ჰოსტის მარშრუტი, შემდეგ შეამოწმეთ, რომელ სერვერს ირჩევს Windows სინამდვილეში.
აპის ქვექსელის მარშრუტიზაცია გაყოფილი გვირაბის აშკარა ნაწილია და ეს მთელი სამუშაო არ არის. გამხსნელი ხშირად სხვა მისამართზე ზის, ვიდრე აპი, რომელსაც ემსახურება, ამიტომ მომუშავე გვირაბს მაინც შეუძლია ძიება მის გარეთ დატოვოს. პროფილი, რომელიც ატარებს 10.80.0.0/16-ს და მეტს არაფერს, 10.90.0.53-ის მოთხოვნას ლოკალური ინტერფეისით აგზავნის, სადაც კერძო ზონა არ არსებობს. დაამატეთ გამხსნელის გზა, შემდეგ შეხედეთ პრობლემის მეორე ნახევარს: რომელ სერვერს ირჩევს კლიენტი სინამდვილეში.
მითი: ერთი მარშრუტი მთელ სერვისს ფარავს
გაყოფილი გვირაბი დანიშნულების ადგილების სიაა, რომლებიც კავშირზე გადიან, და არა სერვისის აღწერა. აპის ქვექსელი და გამხსნელის მისამართი ორი დანიშნულებაა, და პროფილს შეუძლია ერთი მეორის გარეშე ატაროს. როცა ეს ხდება, აპი მისამართით ხელმისაწვდომია, ხოლო მისი სახელი ვერ წყდება, რაც უფრო DNS ხარვეზს ჰგავს, ვიდრე მარშრუტიზაციის ხარვეზს.
გამხსნელის გარშემო ქვექსელიც ავტომატურად არ იფარება. ერთ მისამართზე ჰოსტის მარშრუტი საკმარისია ამ გამხსნელისთვის და მის მეზობლებს არ ხსნის. ეს არის ჰოსტის მარშრუტის აზრი: დიზაინით ვიწრო და ადვილად დასავიწყებელი, როცა შემდეგი სერვისი იმავე ქვექსელში გამოჩნდება.
სამი რამ უნდა სრულდებოდეს, რომ ძიებამ იმუშაოს: კლიენტი გამხსნელის მისამართს გვირაბით მარშრუტიზებს, კარიბჭე იღებს და გადასცემს ამ მოთხოვნას, და გამხსნელი იღებს მიღებულ წყაროს. პასუხიც შეთანხმებული გზით უნდა დაბრუნდეს. თუ ერთი მათგანი აკლია, სიმპტომი იგივეა, ამიტომ ღირს მისამართების ცხრილის ჩაწერა კონფიგურაციაზე ხელის დაჭერამდე.
განსაზღვრეთ, რომელი მისამართები უნდა ატაროს პროფილმა
ჩამოთვალეთ დანიშნულებები თანმიმდევრობით: აპის ქსელი, გამხსნელის მისამართი და საჯარო საბოლოო წერტილი, რომელიც თავად გვირაბს ამთავრებს. მესამე არასდროს უნდა მარშრუტიზდეს გვირაბში, რადგან გარე კავშირს სჭირდება გზა, რომელიც გვირაბამდე არსებობს.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
შეიტანეთ როგორც UDP, ისე TCP DNS-ისთვის, რადგან იმპლემენტაციებისგან მოსალოდნელია TCP-ის მხარდაჭერა UDP-ის გვერდით, და დაბლოკილი TCP გზა ნელ, ნაწილობრივ ხარვეზებს იძლევა სუფთას ნაცვლად. თუ კერძო ზონა IPv6-ითაც მოემსახურება, ექვივალენტური ჰოსტის გამონაკლისი იყენებს IPv6 მისამართსა და პრეფიქსს და ცალკე ჩანაწერია.
ჩაწერეთ, რას ფარავს პროფილი უკვე, სანამ რამეს დაამატებთ. დუბლირებული მარშრუტი უვნებელია, მაგრამ მოულოდნელი არსებული მარშრუტი გეუბნებათ, რომ პროფილი სხვა მისამართების გეგმისთვის შეიქმნა, ვიდრე თქვენ მიიღეთ.
დაამატეთ ჰოსტის მარშრუტი კავშირის მფლობელის მეშვეობით
ლოკალურად მართული მშობლიური Windows პროფილისთვის მარშრუტი კავშირს ეკუთვნის და არა მანქანის გლობალურ მარშრუტიზაციის ცხრილს. ჯერ გადახედეთ დამატებას, შემდეგ გამოიყენეთ იმავე ფარგლებით, რომელსაც პროფილი იყენებს.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
პირველი ბრძანება ცვლილებას წინასწარ აჩვენებს არაფრის დაყენების გარეშე, ხოლო მეორე ჩამოთვლის მარშრუტებს, რომლებსაც პროფილი ახლა ატარებს. Microsoft-ის Add-VpnConnectionRoute-ის ცნობარი აღწერს თითო მომხმარებლისა და ყველა მომხმარებლის ფარგლებს; ყველა მომხმარებლის პროფილს საკუთარი ფარგლის პარამეტრი სჭირდება, და თითო მომხმარებლის ბრძანება ყველა მომხმარებლის პროფილის წინააღმდეგ ან ვერ სრულდება, ან არასწორ ადგილას ხვდება.
როცა პროფილი იმართება ან მომწოდებლის კლიენტიდან მოდის, ცვლილება იმ მფლობელს ეკუთვნის. მუდმივი სისტემური მარშრუტის კავშირის პოლიტიკაზე დაწყობა მუშაობს მანამ, სანამ პოლიტიკა ხელახლა არ გამოყენდება და მარშრუტი არ გაქრება, რაც ჩვეულებრივ მხარდაჭერის ზარზე ხდება და არა ტესტირებისას. ეს ხარვეზი ჩუმია: მარშრუტი ქრება, სახელი წყვეტს ამოხსნას და არავინ აკავშირებს ორ მოვლენას. ჩადეთ ცვლილება მფლობელის საკუთარ ჩანაწერში, რათა შემდეგმა ხელახალმა გამოყენებამ ის ატაროს და არ წაშალოს.
გამოყენების შემდეგ ხელახლა დააკავშირეთ პროფილი, ნაცვლად იმისა, რომ ჩათვალოთ მარშრუტი ძალაში შესული. ცოცხალ კავშირზე მარშრუტის ცვლილებები ყოველთვის არ აითვისება, და ხელახალი დაკავშირება ასევე ამრავლებს იმ მდგომარეობას, რომელიც თქვენს მომხმარებლებს რეალურად ექნებათ.
შეამოწმეთ, რომელი გამხსნელი გამოიყენა კლიენტმა სინამდვილეში
მარშრუტი აკონტროლებს გამხსნელისკენ მიმართულ პაკეტებს. ის არ წყვეტს, რომელი სახელები უნდა გაიგზავნოს იქ, და ეს არჩევანი ცალკე მექანიზმია. Windows-ში მოქმედი სახელთა სივრცის წესებს შეუძლიათ დომენის მიხედვით გამხსნელის არჩევა, ხოლო პროფილის DNS პარამეტრები ნაგულისხმევს იძლევა. ეს ორი ფენა შეიძლება არ დაეთანხმოს ერთმანეთს ყოველგვარი შეცდომის გარეშე, ამიტომ პირდაპირი მოთხოვნა მხოლოდ ნახევარი მტკიცებულებაა.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
პირველი ბრძანება ბეჭდავს მოქმედ სახელთა სივრცის პოლიტიკას, ხოლო მეორე პირდაპირ კერძო გამხსნელს ეკითხება აპის სახელს. პირდაპირი პასუხი ამტკიცებს, რომ გზა და გამხსნელი მუშაობს; ის არ ამტკიცებს, რომ აპის საკუთარმა ძიებამ სწორედ ის სერვერი აირჩია. შეადარეთ ის იმავე სახელის ჩვეულებრივ ძიებას და იმ პასუხს, რომელსაც აპი იღებს.
გაითვალისწინეთ ქეშები და ბრაუზერის დონის უსაფრთხო DNS, რომელსაც შეუძლია სისტემის გამხსნელი სრულიად გვერდი აუაროს მომხმარებლის მიერ აკრეფილ სახელებს. ძიების სუფიქსი კიდევ ერთი შემცდარი კვალია: ის მოკლე სახელს სრულად კვალიფიციურ სახელად აფართოებს და არაფერი აქვს საერთო იმასთან, რომელი სერვერი პასუხობს.
დაასრულეთ ხელახალი დაკავშირებით და ჩვეულებრივი ძიების გამეორებით, შემდეგ დაადასტურეთ, რომ ჩვეულებრივი დათვალიერება კვლავ თავის დამტკიცებულ პოლიტიკას მიჰყვება. კერძო გამხსნელის საჯაროთი ჩანაცვლება იმისთვის, რომ უკავშირო სახელი ამოიხსნას, გასწორება არ არის, და ის ჩუმად გადაიტანს კერძო მოთხოვნებს იქ, სადაც ისინი არასდროს უნდა წასულიყვნენ.