Nepareizs DNS serveris Windows VPN: metrika, saistīšanas kārtība vai sufikss
Trīs Windows mehānismi izvēlas DNS atrisinātāju, un tie sabojājas dažādi. Izlemiet pēc nosaukumtelpas tvēruma, globālās kārtības vai tā, vai labojums pārdzīvo atkārtotu savienojumu.
Windows klientam var būt strādājošs tunelis, tas var nest uzņēmuma atrisinātāju un tomēr sūtīt iekšējos nosaukumus uz mājas maršrutētāju. Kuru serveri atbildēs, nosaka trīs dažādi mehānismi, un tie sabojājas dažādi. Nav jālabo visi trīs: simptoms pasaka, kurš ir spēlē. Zemāk redzamais lēmumu koks aizņem dažas minūtes un novērš ierasto iznākumu, kad metrikas maiņa, reģistra pārkārtošana un NRPT noteikums ierodas kopā un neviens nezina, kurš no tiem ko izdarīja.
Izlemj trīs mehānismi, un parasti viens ir nepareizs
Interfeisa metrika sakārto adapterus noteiktai adrešu saimei. Saistīšanas kārtība zem Tcpip\Linkage ir visai iekārtai kopīgs interfeisa identifikatoru saraksts, kurā vecāki koda ceļi joprojām ieskatās. Nosaukumu izšķiršanas politikas tabula (NRPT) piesaista nosaukumtelpu konkrētiem serveriem, un sufiksu saraksts nosaka, vai īsais nosaukums vispār tiek paplašināts. Tie ir neatkarīgi, tāpēc pareizs atrisinātājs VPN adapterī zaudē novecojušai izvēlei citur.
| 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 |
Neviens no šiem mehānismiem nav tuneļa otrā puse. Ja serveris, ko VPN iebīda, nevar atrisināt nosaukumu, jebkurš klienta puses iestatījums ir tikai rotājums, tāpēc pirmais lēmums ir, vai pats atrisinātājs var atbildēt, kad to jautā tieši.
Pirmais lēmums: vai iebīdītais atrisinātājs vispār var atbildēt?
Jautājiet serverim tieši un salīdziniet ar parastu meklēšanu. Atšķirība starp atbildēm atdala izvēles problēmu no sasniedzamības problēmas, un šeit tas ir ātrākais atzars:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type AJa pirmais izdodas un otrais neizdodas, atrisinātājs ir sasniedzams un Windows izvēlas slikti; dodieties uz zemāk redzamajiem nosaukumtelpas un kārtības lēmumiem. Ja neizdodas arī pirmais, klientā nekas nepalīdzēs: pārbaudiet, vai UDP un TCP 53 sasniedz serveri caur tuneli, vai servera resursdatora ugunsmūris neizmet baseinu un vai paša servera pārsūtītāji ir veseli.
Apstājieties šajā atzarā. NRPT noteikuma piemērošana atrisinātājam, kuram nevarat piekļūt, rada to pašu kļūmi ar vairāk atceļamas konfigurācijas, un tā slēpj īsto defektu aiz noteikuma, kas izskatās autoritatīvs.
Otrais lēmums: viena nosaukumtelpa vai katrs vaicājums?
Tvērums nosaka rīku. Kad neizdodas tikai uzņēmuma nosaukumi, piesaistiet nosaukumtelpu, nevis pārkārtojiet iekārtu: NRPT noteikums nosūta šo sufiksu tuneļa atrisinātājam un atstāj pārējo mierā. Kad ir skarts katrs meklējums, problēma ir globālā adapteru izvēle, un metrika ir vieta, ar ko sākt, jo tā nemaina nevienu servera iestatījumu.
Iestatiet metriku katrai adrešu saimei, abos interfeisos, un pēc tam apstipriniet kārtību:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6Aizstājiet 11 ar tuneļa adaptera ifIndex no iepriekšējās rindas; ja 11 ir LAN adapters, tā pati komanda nolaiž nepareizo ceļu. LAN adaptera pacelšana tā vietā sasniedz to pašu kārtību no otras puses: netsh int ip set interface interface="Ethernet" metric=15, un otrajai saimei netsh int ipv6 set interface interface="Ethernet" metric=15, jo int ip skar tikai IPv4.
Saistīšanas kārtība ir pēdējais līdzeklis, nevis pirmais solis. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage glabā ierīču identifikatoru Bind sarakstu, un tuneļa identifikatora pārvietošana uz priekšu tiešām maina, kuram adapterim jautā pirmajam, taču tā ir visai iekārtai kopīga reģistra vērtība bez tvēruma pa nosaukumtelpām. Eksportējiet to pirms rediģēšanas un pēc tam no jauna pievienojiet tuneli, lai kārtība darbotos tajā stāvoklī, kuru klients gaida.
Vienai nosaukumtelpai dodiet priekšroku šaurākam instrumentam:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersTrešais lēmums: vai labojums pārdzīvo atkārtotu savienojumu?
Metrika, kas darbojas līdz nākamajam zvanu savienojumam, nekad netika saglabāta. L2TP/IPsec un citi savienojuma profili tiek izveidoti no jauna, kad savienojums sākas, tāpēc saglabātā vērtība dzīvo telefona grāmatas ierakstā kā IpInterfaceMetric, ne tikai aktīvajā interfeisā. Dažas vides skriptē šo lauku tieši šī iemesla dēļ; citas iebīda izvēli no pārvaldības politikas un atstāj galapunktu mierā.
Kešatmiņa un reģistrācija ir atsevišķs slānis. To palaišana pēc tuneļa pacelšanas izlabo novecojušus ierakstus un reģistrē klientu no jauna, bet neviens no tiem nepārkārto adapteri:
ipconfig /registerdns
ipconfig /flushdnsTajā pašā slānī ir izslēgšanas slēdzis. Dinamiskās reģistrācijas izslēgšana fiziskajā adapterī neļauj klientam paziņot savu VPN puses adresi nepareizā nosaukumā, un tas ir cits labojums nekā iepriekš aprakstītā atjaunošana.
IPv6 lēmumā ir pelnījis savu rindu. Ja fiziskajam adapterim ir globāla IPv6 adrese, kamēr tunelis pārvadā tikai IPv4, Windows var dot priekšroku ceļam bez tuneļa nosaukumu izšķiršanai. Pārbaudiet šo saimi atsevišķi, jo IPv4 iestatītā metrika par to neko nepasaka:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricIPv6 izslēgšana LAN adapterī noņem šo ceļu un protokolu kopā ar to; metrikas maiņa IPv6 interfeisā vai NRPT noteikums uzņēmuma nosaukumtelpai saglabā saimi un izlabo izvēli. Izvēlieties šaurāko, ja vien neesat nolēmis, ka šim savienojumam nevajadzētu būt IPv6.
Pārbaudiet ar nosauktu avotu, un turiet vienu īpašnieku
Pārbaudiet ar rīkiem, kas ziņo, kurš avots ir spēkā, nevis tikai to, vai lapa ielādējas:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type APēc tam atdaliet filtrēšanu no izvēles, jo no lietojumprogrammas iekšpuses tie izskatās identiski. OpenVPN opcija block-outside-dns bloķē 53 portu citos adapteros; tā neizvēlas atrisinātāju. Ja tagad neizdodas katrs vaicājums, filtrs var bloķēt vienīgo sasniedzamo serveri; ja konfigurētais atrisinātājs tiek ignorēts, kārtība vai nosaukumtelpas noteikums ir nepareizs. Abu maiņa vienlaikus padara bloķētu vaicājumu un ignorētu vaicājumu neatšķiramus.
Turiet vienu DNS politikas īpašnieku: VPN profils, pārvaldības politika vai NRPT noteikums, nevis divi no tiem. Pirms noslēdzat:
- Iebīdītais atrisinātājs atbild, kad to nosauc tieši, un parasta meklēšana to izmanto.
- Mainītais noteikums vai metrika aptver to adrešu saimi, kas patiešām pārvadā vaicājumus.
- Iestatījums pārdzīvo atvienošanu un atkārtotu savienojumu, vai arī esat to pārvietojis uz saglabāto profilu.
- Autoritatīvs ir tieši viens mehānisms, un pārējie atstāti tādi, kādi bija.
Uztveriet kārtību kā vides stāvokli, nevis lietu, ko pabeidzat. Pārbaudiet to vēlreiz pēc atkārtota savienojuma un pēc Windows atjauninājuma, kas skar tīkla steku, jo jebkurš no tiem var atkal izvirzīt fizisko adapteri priekšā.