DNS-ის დაყენება Windows VPN ადაპტერზე PowerShell-ით და შემდეგ შემოწმება

Windows-ის VPN კავშირი არ ინახავს DNS სერვერებს იმ პროფილში, რომელსაც პარამეტრებში არედაქტირებთ. როცა გვირაბი ამოდის, კლიენტი შლუზთან IP კონფიგურაციაზე მოლაპარაკებას აწარმოებს, შლუზი ხსნადთა სიას აგზავნის და Windows-ი მას გვირაბის ადაპტერზე იყენებს. ეს ადაპტერი თქვენი Wi-Fi ან Ethernet-ისგან ცალკე ინტერფეისია, და სია ინტერფეისს ეკუთვნის, არა პროფილს. როცა იცით, რომელი ობიექტი ფლობს მნიშვნელობას, PowerShell-ში მისი გადაფარვა ერთი ბრძანებაა; გადაფარვის ხელახალ დაკავშირებაზე გადატანა ის ნაწილია, რომელიც გადაწყვეტილებას მოითხოვს.

რომელი ობიექტი ფლობს მისამართს

RAS გვირაბის ადაპტერს ქმნის, როცა კავშირი წარმატებით სრულდება, და შლის, როცა კავშირი წყდება. DNS სერვერები, რომლებსაც ipconfig /all-ში ხედავთ, იმ კონფიგურაციის გაცვლისას მოდის, IPv4 და IPv6 მისამართებისა და მარშრუტების გვერდით. ვინაიდან მნიშვნელობა ინტერფეისზეა მიბმული, Set-DnsClientServerAddress წერს იმაში, რაც მხოლოდ მაშინ არსებობს, სანამ კავშირი არსებობს.

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

იპოვეთ ფსევდონიმი, სანამ DNS-ს შეეხებით

პროფილის სახელი და ინტერფეისის ფსევდონიმი ჩვეულებრივ ერთი და იგივე სტრიქონია, მაგრამ ერთი და იგივე ობიექტი არ არის. Get-VpnConnection პროფილებს ჩამოთვლის; Get-NetAdapter იმ ინტერფეისებს ჩამოთვლის, რომლებიც Windows-ს ნამდვილად აქვს. DNS cmdlet-ებს მეორე სჭირდებათ, და ეს ორი უფრო ხშირად იშლება, ვიდრე ადამიანები ელიან, განსაკუთრებით მაშინ, როცა კლიენტი ადაპტერის სახელს ამატებს აღწერას, როგორიცაა "(RAS)".

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

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

ერთხელ დაუკავშირდით, შემდეგ წაიკითხეთ ნამდვილი ფსევდონიმი, სანამ რომელიმე DNS ბრძანებას დაწერთ:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

გამოიყენეთ გადაფარვა სწორი თანმიმდევრობით

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

თავად cmdlet ერთი ხაზია, დოკუმენტირებული Microsoft-ის Set-DnsClientServerAddress-ის ცნობარში:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

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

რატომ შეიძლება ხელახალმა დაკავშირებამ ცვლილება გააუქმოს

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

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

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

შეამოწმეთ გადაწყვეტა და არა მხოლოდ პარამეტრი

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

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

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

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