რატომ წყვეტს DNS მუშაობას Windows-ში OpenVPN-ის დაკავშირების შემდეგ

ოფისის გადამწყვეტზე ping-ის პასუხი მაინც მოდის "OpenVPN"-ის დაკავშირების შემდეგ, და მაინც ყოველი სახელის ძიება ვერ ხერხდება. მისამართი ხელმისაწვდომია, პორტი კი არა, კომბინაცია, რომელიც აზრს იძენს, როცა იცით, რომ Windows-ს შეუძლია DNS-ის ფილტრაცია ადაპტორის მიხედვით. პროფილში block-outside-dns-ის არსებობისას სწორედ ეს ფილტრია პირველი ეჭვმიტანილი, და მარშრუტების ცხრილი არასწორი ადგილია საძებნელად. ქვემოთ მოცემული ორი ტესტი ფენებს წამებში ჰყოფს.

ხელმისაწვდომი მისამართი, მკვდარი პორტი

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

ping <resolver-ip>
nslookup <name> <resolver-ip>

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

ეს პარამეტრი ფილტრაციის პლატფორმის წესია

OpenVPN-ის ცნობარი block-outside-dns-ს აღწერს როგორც Windows Filtering Platform-ის შეზღუდვას, რომელიც ხელს უშლის აპლიკაციებს გვირაბის გარეთ არსებულ ადაპტორებზე DNS-ის მიღწევაში. ის მოიცავს TCP და UDP 53 პორტს. რადგან ფილტრი WFP-ში ცხოვრობს და არა ჩვეულებრივი firewall-ის წესების სიაში, სხვა ადგილას ნებართვის წესის დამატება შედეგს აუცილებლად არ ცვლის. ამიტომ DNS-ის დაშვების ჩვეულებრივი რჩევა მაინც ვერ მუშაობს.

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

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

ფილტრი გადამწყვეტი არ არის

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

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

1. გამოყენებული გადამწყვეტი: შეადარეთ Resolve-DnsName -Server <resolver-ip> <name> იმ DNS სერვერებს, რომლებსაც ipconfig /all ჩამოთვლის.
2. VPN-ის DNS გამოყენებულია: შეამოწმეთ გვირაბის ადაპტორის DNS ჩანაწერები იმავე გამოსავალში ipconfig /all-დან.
3. გამოყენებული ინტერფეისი: Find-NetRoute -RemoteIPAddress <resolver-ip> ასახელებს გამავალ ინტერფეისს ამ დანიშნულებისთვის.

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

რას არ ფარავს ეს პარამეტრი

53 პორტი სახელების გადაწყვეტის მთლიანობა არ არის. DNS over HTTPS და DNS over TLS სხვადასხვა ტრანსპორტს იყენებენ, და ზოგი აპლიკაცია საკუთარ გადამწყვეტ ლოგიკას უშვებს სისტემური პარამეტრების მიუხედავად. ამიტომ ბრაუზერს შეუძლია სახელების გადაწყვეტა, ბრძანების სტრიქონს კი არა.

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

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

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

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

ipconfig /displaydns
nslookup <name> <resolver-ip>

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

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