Windows VPN-ის DNS გაჟონვა: რატომ იმარჯვებს მეტრიკა მარშრუტზე

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

ორი ახსნა ერთი გაჟონვისთვის

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

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

შეადარეთ მეტრიკები და რეზოლვერები ერთად

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

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

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

გვირაბი ზემოთ აწიეთ და ხელახლა შეამოწმეთ

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

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

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

გახადეთ ის გადატეხილი კავშირის მიმართ მდგრადი

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

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