არასწორი DNS სერვერი Windows VPN-ში: მეტრიკა, დაკავშირების რიგი ან სუფიქსი
Windows-ის სამი მექანიზმი ირჩევს DNS ამომხსნელს და ისინი სხვადასხვაგვარად ფუჭდებიან. გადაწყვიტეთ სახელთა სივრცის მოცულობით, გლობალური რიგით ან იმით, გადაურჩება თუ არა შესწორება ხელახალ დაკავშირებას.
Windows კლიენტს შეიძლება ჰქონდეს მომუშავე გვირაბი, ატაროს კორპორატიული ამომხსნელი და მაინც გაუგზავნოს შიდა სახელები სახლის როუტერს. რომელი სერვერი უპასუხებს, ამას სამი განსხვავებული მექანიზმი წყვეტს და ისინი სხვადასხვაგვარად ფუჭდებიან. სამივეს გასწორება არ გჭირდებათ: სიმპტომი გეუბნებათ, რომელია თამაშში. ქვემოთ მოცემულ გადაწყვეტილების ხეს რამდენიმე წუთი სჭირდება და თავიდან გვაცილებს ჩვეულ შედეგს, როცა მეტრიკის ცვლილება, რეესტრის გადალაგება და NRPT წესი ერთად მოდის და არავინ იცის, რომელმა რა გააკეთა.
სამი მექანიზმი წყვეტს, და ჩვეულებრივ ერთი მცდარია
ინტერფეისის მეტრიკა ალაგებს ადაპტერებს მოცემული მისამართების ოჯახისთვის. Tcpip\Linkage-ის ქვეშ მოცემული დაკავშირების რიგი მთელი მანქანის ინტერფეისის იდენტიფიკატორების სიაა, რომელსაც ძველი კოდის ბილიკები ჯერ კიდევ კითხულობენ. სახელთა ამოხსნის წესების ცხრილი (NRPT) სახელთა სივრცეს კონკრეტულ სერვერებს უკავშირებს, ხოლო სუფიქსების სია წყვეტს, გაფართოვდება თუ არა მოკლე სახელი საერთოდ. ისინი დამოუკიდებელია და ამიტომ VPN ადაპტერზე სწორი ამომხსნელი სხვაგან არსებულ მოძველებულ უპირატესობას აგებს.
| What you see | Mechanism to check | First command |
|---|---|---|
| Every name is slow, public names sometimes wrong | Global adapter order: metric, then Linkage | Get-NetIPInterface |
| Internal names resolve to a public address | The query left through the home resolver, not the tunnel | Resolve-DnsName intranet.corp.example -Type A, then the same query with -Server 10.20.0.10 |
| Only corp.example names fail, public names fine | Namespace binding: NRPT or suffix | Get-DnsClientNrptRule |
| Short name fails, fully qualified name works | Suffix list on the adapter, with the corporate suffix ahead of other entries, or pushed by the server | Get-DnsClientGlobalSetting |
| Works, then breaks after a reconnect | Runtime setting that was never persisted | Get-VpnConnection for the stored profile, then Get-NetIPInterface again after a reconnect |
არც ერთი ეს მექანიზმი არ არის გვირაბის მეორე მხარე. თუ სერვერი, რომელსაც VPN უბიძგებს, სახელს ვერ ხსნის, კლიენტის მხარეს ყველა პარამეტრი მხოლოდ მორთულობაა, ამიტომ პირველი გადაწყვეტილებაა, შეუძლია თუ არა თავად ამომხსნელს პასუხის გაცემა, როცა პირდაპირ კითხულობენ.
გადაწყვეტილება პირველი: შეუძლია თუ არა გატანილ ამომხსნელს საერთოდ პასუხის გაცემა?
ჰკითხეთ სერვერს ცალსახად და შეადარეთ ჩვეულებრივ ძიებას. პასუხებს შორის სხვაობა გამოყოფს არჩევანის პრობლემას მიწვდომის პრობლემისგან და აქ ყველაზე სწრაფი განშტოებაა:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type Aთუ პირველი წარმატებულია და მეორე ვერ ხერხდება, ამომხსნელი მისაწვდომია და Windows ცუდად ირჩევს; გადადით ქვემოთ სახელთა სივრცისა და რიგის გადაწყვეტილებებზე. თუ პირველიც ფუჭდება, კლიენტზე ვერაფერი უშველის: შეამოწმეთ, აღწევს თუ არა UDP და TCP 53 სერვერამდე გვირაბით, ხომ არ აგდებს სერვერზე ჰოსტის ფაირვოლი პულს, და ჯანმრთელია თუ არა სერვერის საკუთარი გადამცემები.
გაჩერდით ამ განშტოებაზე. NRPT წესის გამოყენება ამომხსნელზე, რომელსაც ვერ აღწევთ, იმავე უკმარისობას იძლევა მეტი უკუქცევადი კონფიგურაციით და ნამდვილ ხარვეზს მალავს უფლებამოსილად მოჩვენებული წესის უკან.
გადაწყვეტილება მეორე: ერთი სახელთა სივრცე თუ ყოველი მოთხოვნა?
მოცულობა წყვეტს ხელსაწყოს. როცა მხოლოდ კორპორატიული სახელები ფუჭდება, დააკავშირეთ სახელთა სივრცე მანქანის გადალაგების ნაცვლად: NRPT წესი აგზავნის ამ სუფიქსს გვირაბის ამომხსნელთან და დანარჩენს ხელუხლებლად ტოვებს. როცა ყოველი ძიება დაზარალებულია, პრობლემა ადაპტერების გლობალური უპირატესობაა, და მეტრიკა დასაწყისია, რადგან სერვერის არც ერთ პარამეტრს არ ცვლის.
დააყენეთ მეტრიკა თითოეული მისამართების ოჯახისთვის, ორივე ინტერფეისზე, და შემდეგ დაადასტურეთ რიგი:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6ჩაანაცვლეთ 11 გვირაბის ადაპტერის ifIndex-ით ზემოთ მოცემული ხაზიდან; თუ 11 LAN ადაპტერია, იგივე ბრძანება არასწორ ბილიკს აწევს. LAN ადაპტერის აწევა სამაგიეროდ იმავე რიგს აღწევს მეორე მხრიდან: netsh int ip set interface interface="Ethernet" metric=15, და მეორე ოჯახისთვის netsh int ipv6 set interface interface="Ethernet" metric=15, რადგან int ip მხოლოდ IPv4-ს ეხება.
დაკავშირების რიგი ბოლო საშუალებაა და არა პირველი ნაბიჯი. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage ინახავს მოწყობილობის იდენტიფიკატორების Bind სიას, და გვირაბის იდენტიფიკატორის წინ წაწევა ნამდვილად ცვლის, რომელი ადაპტერი იკითხება პირველი, მაგრამ ეს მთელი მანქანის რეესტრის მნიშვნელობაა სახელთა სივრცის მიხედვით მოცულობის გარეშე. გაიტანეთ იგი რედაქტირებამდე და შემდეგ ხელახლა შეაერთეთ გვირაბი, რათა რიგი იმ მდგომარეობაში მოქმედებდეს, რომელსაც კლიენტი ელის.
ერთი სახელთა სივრცისთვის ამჯობინეთ უფრო ვიწრო ხელსაწყო:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersგადაწყვეტილება მესამე: გადაურჩება თუ არა შესწორება ხელახალ დაკავშირებას?
მეტრიკა, რომელიც მუშაობს შემდეგ აკრეფვით ხელახალ დაკავშირებამდე, არასოდეს ყოფილა შენახული. L2TP/IPsec და სხვა კავშირის პროფილები ხელახლა იქმნება კავშირის დაწყებისას, ამიტომ შენახული მნიშვნელობა ტელეფონის წიგნის ჩანაწერში ცხოვრობს როგორც IpInterfaceMetric, და არა მხოლოდ ცოცხალ ინტერფეისზე. ზოგი გარემო ამ ველს ზუსტად ამ მიზეზით სკრიპტავს; სხვები უპირატესობას მართვის პოლიტიკიდან უბიძგებენ და ბოლო წერტილს ხელუხლებლად ტოვებენ.
ქეში და რეგისტრაცია ცალკე ფენაა. მათი გაშვება გვირაბის აწევის შემდეგ ასწორებს მოძველებულ ჩანაწერებს და ხელახლა არეგისტრირებს კლიენტს, მაგრამ არც ერთი მათგანი ადაპტერს ხელახლა არ ალაგებს:
ipconfig /registerdns
ipconfig /flushdnsიმავე ფენაში გამომრთველია. დინამიკური რეგისტრაციის გამორთვა ფიზიკურ ადაპტერზე ხელს უშლის კლიენტს, გამოაცხადოს თავისი VPN მხარის მისამართი არასწორი სახელით, და ეს ზემოთ მოცემული განახლებისგან განსხვავებული შესწორებაა.
IPv6 იმსახურებს საკუთარ ხაზს გადაწყვეტილებაში. თუ ფიზიკურ ადაპტერს გლობალური IPv6 მისამართი აქვს, მაშინ როცა გვირაბი მხოლოდ IPv4-ს ატარებს, Windows შეიძლება უპირატესობა მისცეს გვირაბის გარეშე ბილიკს სახელთა ამოხსნისთვის. შეამოწმეთ ეს ოჯახი ცალკე, რადგან IPv4-ისთვის დაყენებული მეტრიკა მის შესახებ არაფერს ამბობს:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricIPv6-ის გამორთვა LAN ადაპტერზე აშორებს ამ ბილიკს და მასთან ერთად პროტოკოლს; მეტრიკის ცვლილება IPv6 ინტერფეისზე, ან NRPT წესი კორპორატიული სახელთა სივრცისთვის, ინარჩუნებს ოჯახს და ასწორებს უპირატესობას. აირჩიეთ უფრო ვიწრო, თუ არ გადაგიწყვეტიათ, რომ ამ რგოლს IPv6 არ უნდა ჰქონდეს.
გადაამოწმეთ დასახელებული წყაროთი და შეინარჩუნეთ ერთი მფლობელი
გადაამოწმეთ ხელსაწყოებით, რომლებიც იტყობინებიან, რომელი წყაროა ძალაში, და არა მხოლოდ იმას, იტვირთება თუ არა გვერდი:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type Aშემდეგ გამოყავით ფილტრაცია არჩევისგან, რადგან აპლიკაციის შიგნიდან ისინი იდენტურად გამოიყურება. OpenVPN-ის block-outside-dns ბლოკავს 53 პორტს სხვა ადაპტერებზე; ის ამომხსნელს არ ირჩევს. თუ ახლა ყოველი მოთხოვნა ფუჭდება, ფილტრმა შეიძლება დაბლოკოს ერთადერთი მისაწვდომი სერვერი; თუ კონფიგურირებული ამომხსნელი იგნორირდება, რიგი ან სახელთა სივრცის წესი მცდარია. ორივეს ერთდროულად შეცვლა დაბლოკილ მოთხოვნას და იგნორირებულ მოთხოვნას გაურჩეველს ხდის.
DNS პოლიტიკისთვის შეინარჩუნეთ ერთი მფლობელი: VPN პროფილი, მართვის პოლიტიკა ან NRPT წესი, და არა ორი მათგანი. სანამ დახურავთ:
- გატანილი ამომხსნელი პასუხობს, როცა ცალსახად იხსენიება, და ჩვეულებრივი ძიება მას იყენებს.
- თქვენ მიერ შეცვლილი წესი ან მეტრიკა ფარავს იმ მისამართების ოჯახს, რომელიც რეალურად ატარებს მოთხოვნებს.
- პარამეტრი გადაურჩება გათიშვას და ხელახალ დაკავშირებას, ან თქვენ ის შენახულ პროფილში გადაიტანეთ.
- ზუსტად ერთი მექანიზმია უფლებამოსილი, დანარჩენი კი ისე დარჩა, როგორც იყო.
მოეპყარით რიგს როგორც გარემოს მდგომარეობას და არა როგორც დასასრულებელ საქმეს. ხელახლა შეამოწმეთ იგი ხელახალი დაკავშირების შემდეგ და ქსელის დასტაზე შემხები Windows განახლების შემდეგ, რადგან ორივე მათგანს შეუძლია ფიზიკური ადაპტერი ისევ წინ წამოაყენოს.