VPN-მა DNS ჩაიბარა და ლოკალური სახელები გააფუჭა: გაასწორეთ სია

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

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

რომელ სიას იყენებენ აპლიკაციები სინამდვილეში

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

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

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

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

ამოიღეთ გაგზავნილი სერვერები ან ჩამოაქვეითეთ ისინი

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

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

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

სად შეიძლება push-ის გაფილტვრა

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

pull-filter ignore "dhcp-option DNS "

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

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

გახადეთ შესწორება ხელახალი დაკავშირების გამძლე

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

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

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

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