Väärä DNS-palvelin Windows VPN:ssä: metriikka, sidontajärjestys vai pääte

Windows-asiakkaalla voi olla toimiva tunneli, yrityksen resolveri käytössään ja silti sisäiset nimet menevät kotireitittimelle. Kolme eri mekanismia päättää, mikä palvelin vastaa, ja ne epäonnistuvat eri tavoin. Kaikkia kolmea ei tarvitse korjata: oire kertoo, mikä on pelissä. Alla oleva päätöspuu vie muutaman minuutin ja estää tavanomaisen lopputuloksen, jossa metriikan muutos, rekisterin uudelleenjärjestys ja NRPT-sääntö saapuvat yhtä aikaa eikä kukaan tiedä, mikä niistä teki jotain.

Kolme mekanismia päättää, ja yleensä yksi on väärin

Liitännän metriikka järjestää sovittimet tietylle osoiteperheelle. Sidontajärjestys Tcpip\Linkage-avaimen alla on koneenlaajuinen luettelo liitännän tunnisteista, jota vanhemmat koodipolut yhä konsultoivat. Nimenratkaisun käytäntötaulukko (NRPT) sitoo nimiavaruuden tiettyihin palvelimiin, ja päätteiden luettelo päättää, laajennetaanko lyhyt nimi ylipäätään. Ne ovat toisistaan riippumattomia, ja siksi VPN-sovittimen oikea resolveri häviää muualla olevalle vanhentuneelle mieltymykselle.

Mikään näistä mekanismeista ei ole tunnelin toinen pää. Jos palvelin, jonka VPN työntää, ei pysty ratkaisemaan nimeä, jokainen asiakaspuolen asetus on pelkkää koristetta, joten ensimmäinen päätös on, pystyykö resolveri itse vastaamaan, kun sitä kysytään suoraan.

Päätös yksi: pystyykö työnnetty resolveri ylipäätään vastaamaan?

Kysy palvelimelta nimenomaisesti ja vertaa sitä tavalliseen hakuun. Vastausten välinen ero erottaa valintaongelman tavoitettavuusongelmasta, ja tässä on nopein haarautuma:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Jos ensimmäinen onnistuu ja toinen epäonnistuu, resolveri on tavoitettavissa ja Windows valitsee huonosti; siirry alla oleviin nimiavaruuden ja järjestyksen päätöksiin. Jos myös ensimmäinen epäonnistuu, mikään asiakkaassa ei auta: tarkista, että UDP ja TCP 53 saavuttavat palvelimen tunnelin kautta, ettei palvelimen isäntäpalomuuri pudota allasta ja että palvelimen omat edelleenlähettäjät ovat kunnossa.

Pysähdy tähän haarautumaan. NRPT-säännön soveltaminen resolveriin, johon et pääse, tuottaa saman vian ja enemmän purettavaa määritystä, ja se kätkee todellisen vian näennäisesti arvovaltaisen säännön taakse.

Päätös kaksi: yksi nimiavaruus vai jokainen kysely?

Laajuus päättää välineen. Kun vain yrityksen nimet epäonnistuvat, sido nimiavaruus sen sijaan että järjestäisit koneen uudelleen: NRPT-sääntö lähettää kyseisen päätteen tunnelin resolverille ja jättää kaiken muun rauhaan. Kun jokainen haku kärsii, ongelma on sovittimien yleinen mieltymys, ja metriikka on oikea aloituspaikka, koska se ei muuta yhtään palvelinasetusta.

Aseta metriikka osoiteperheittäin, molemmille liitännöille, ja vahvista järjestys sen jälkeen:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Korvaa 11 tunnelisovittimen ifIndexillä yllä olevasta rivistä; jos 11 on LAN-sovitin, sama komento laskee väärää polkua. LAN-sovittimen nostaminen puolestaan saavuttaa saman järjestyksen toiselta puolelta: netsh int ip set interface interface="Ethernet" metric=15, ja toiselle perheelle netsh int ipv6 set interface interface="Ethernet" metric=15, koska int ip koskee vain IPv4:ää.

Sidontajärjestys on viimeinen keino, ei ensimmäinen siirto. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage sisältää Bind-luettelon laitetunnisteista, ja tunnelin tunnisteen siirtäminen eteen todella muuttaa sitä, miltä sovittimelta kysytään ensin, mutta se on koneenlaajuinen rekisteriarvo ilman nimiavaruuskohtaista ulottuvuutta. Vie se ennen muokkausta ja yhdistä tunneli sen jälkeen uudelleen, jotta järjestys pätee tilassa, jota asiakas odottaa.

Yhdelle nimiavaruudelle suosi kapeampaa välinettä:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Päätös kolme: kestääkö korjaus uudelleenyhdistämisen?

Metriikka, joka toimii seuraavaan puhelinverkkoyhteyden uudelleenyhdistämiseen asti, ei ollut koskaan tallennettu. L2TP/IPsec ja muut yhteysprofiilit luodaan uudelleen, kun yhteys alkaa, joten tallennettu arvo elää puhelinluettelomerkinnässä nimellä IpInterfaceMetric, ei vain elävässä liitännässä. Jotkin ympäristöt skriptaavat tuon kentän juuri tästä syystä; toiset työntävät mieltymyksen hallintakäytännöstä ja jättävät päätepisteen rauhaan.

Välimuisti ja rekisteröinti ovat erillinen kerros. Näiden ajaminen tunnelin noustua korjaa vanhentuneet merkinnät ja rekisteröi asiakkaan uudelleen, mutta kumpikaan ei järjestä sovitinta uudelleen:

ipconfig /registerdns
ipconfig /flushdns

Samassa kerroksessa on katkaisin. Dynaamisen rekisteröinnin poistaminen käytöstä fyysisessä sovittimessa estää asiakasta mainostamasta VPN-puolen osoitettaan väärällä nimellä, mikä on eri korjaus kuin yllä oleva päivitys.

IPv6 ansaitsee oman rivinsä päätöksessä. Jos fyysisellä sovittimella on globaali IPv6-osoite, kun taas tunneli kuljettaa vain IPv4:ää, Windows voi suosia tunnelitonta polkua nimien ratkaisuun. Tarkista tämä perhe erikseen, sillä IPv4:lle asetettu metriikka ei kerro siitä mitään:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

IPv6:n poistaminen käytöstä LAN-sovittimessa poistaa polun ja protokollan mukanaan; metriikan muutos IPv6-liitännässä tai NRPT-sääntö yrityksen nimiavaruudelle säilyttää perheen ja korjaa mieltymyksen. Valitse kapeampi, ellet ole päättänyt, ettei sillä linkillä pitäisi olla IPv6:ta.

Vahvista nimetty lähde ja pidä yksi omistaja

Vahvista työkaluilla, jotka kertovat, mikä lähde on voimassa, eivät vain sitä, latautuuko sivu:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Erottele sitten suodatus valinnasta, koska sovelluksen sisältä ne näyttävät samoilta. OpenVPN:n block-outside-dns estää portin 53 muilla sovittimilla; se ei valitse resolveria. Jos nyt jokainen kysely epäonnistuu, suodatin saattaa estää ainoan tavoitettavissa olevan palvelimen; jos määritetty resolveri jätetään huomiotta, järjestys tai nimiavaruussääntö on väärä. Molempien muuttaminen kerralla tekee estetystä ja huomiotta jätetystä kyselystä erottamattomia.

Pidä yksi omistaja DNS-käytännölle: VPN-profiili, hallintakäytäntö tai NRPT-sääntö, ei kahta niistä. Ennen kuin suljet asian:

• Työnnetty resolveri vastaa, kun se nimetään nimenomaisesti, ja tavallinen haku käyttää sitä.
• Muuttamasi sääntö tai metriikka kattaa sen osoiteperheen, joka todella kuljettaa kyselyt.
• Asetus kestää yhteyden katkaisun ja uudelleenyhdistämisen, tai olet siirtänyt sen tallennettuun profiiliin.
• Täsmälleen yksi mekanismi on määräävä, ja muut jätettiin sellaisiksi kuin ne olivat.

Käsittele järjestystä ympäristön tilana etkä asiana, jonka viimeistelet. Tarkista se uudelleen uudelleenyhdistämisen jälkeen ja sellaisen Windows-päivityksen jälkeen, joka koskee verkkopinoa, koska kumpi tahansa voi palauttaa fyysisen sovittimen etualalle.