Rangur DNS-þjónn í Windows VPN: mæligildi, bindiröð eða viðskeyti
Þrír gangverkar Windows velja DNS-upplausnarann, og þeir mistakast á mismunandi vegu. Ákveddu eftir umfangi nafnrýmis, alheimsröð eða hvort lagfæring lifir endurtengingu.
Windows-biðlari getur haft vinnandi göng, borið fyrirtækjaupplausnarann og samt sent innri nöfn á heimaleiðarann. Þrír mismunandi gangverkar ákveða hvaða þjónn svarar, og þeir mistakast á mismunandi vegu. Þú þarft ekki að laga alla þrjá: einkennið segir þér hver er í gangi. Ákvörðunartréð hér að neðan tekur nokkrar mínútur og kemur í veg fyrir venjulegu útkomuna, þar sem breyting á mæligildi, endurröðun í skrá og NRPT-regla lenda saman og enginn veit hver gerði eitthvað.
Þrír gangverkar ákveða, og venjulega er einn rangur
Mæligildi viðmótsins raðar millistykjum fyrir tiltekna vistfangafjölskyldu. Bindiröðin undir Tcpip\Linkage er vélvíður listi viðmótsauðkenna sem eldri kóðaslóðir fletta enn upp. Nafnupplausnarstefnutöflurnar (NRPT) binda nafnrými við tiltekna þjóna, og viðskeytalistinn ákveður hvort stutt nafn sé yfirhöfuð víkkað. Þeir eru óháðir, og þess vegna tapar réttur upplausnari á VPN-millistykkinu fyrir úreltri forgangsskipan annars staðar.
| 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 |
Ekkert þessara gangverka er hin hlið gönganna. Ef þjónninn sem VPN ýtir inn getur ekki leyst nafnið, er sérhver stilling á biðlarahlið skraut, því fyrsta ákvörðunin er hvort upplausnarinn sjálfur geti svarað þegar spurt er beint.
Ákvörðun eitt: getur innýtti upplausnarinn svarað yfirhöfuð?
Spurðu þjóninn berum orðum og berðu saman við venjulega leit. Bilið milli svaranna aðskilur valvandamál frá aðgengisvandamáli, og hér er skjótasti kvíslinn:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A
Ef fyrra tekst og seinna mistekst er upplausnarinn aðgengilegur og Windows velur illa; farðu í ákvarðanirnar um nafnrými og röð hér að neðan. Ef fyrra mistekst líka hjálpar ekkert á biðlaranum: athugaðu hvort UDP og TCP 53 ná þjóninum gegnum göngin, að engin hýsileldveggur á þjóninum hendi lauginni og að eigin áframsendur þjónsins séu heilbrigðir.
Stoppaðu á þessum kvísl. Að beita NRPT-reglu á upplausnara sem þú nærð ekki skilar sama bilun með meiri uppsetningu til að afturkalla, og hún felur raunverulegu bilunina bak við reglu sem virðist valdboðin.
Ákvörðun tvö: eitt nafnrými, eða hver fyrirspurn?
Umfangið ákveður verkfærið. Þegar aðeins fyrirtækjanöfn mistakast skaltu binda nafnrýmið í stað þess að endurraða vélinni: NRPT-regla sendir viðskeytið til upplausnara ganganna og lætur allt annað í friði. Þegar hver leit verður fyrir áhrifum, er vandamálið alheims millistykkaforgangur, og mæligildið er staðurinn til að byrja því það breytir engri þjónsstillingu.
Stilltu mæligildið fyrir hverja vistfangafjölskyldu, á báðum viðmótum, og staðfestu röðina eftir á:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6
Skiptu 11 út fyrir ifIndex millistykksins í göngunum úr línunni hér að ofan; ef 11 er LAN-millistykkið lækkar sama skipun röngu slóðina. Að hækka LAN-millistykkið í staðinn nær sömu röð frá hinni hliðinni: netsh int ip set interface interface="Ethernet" metric=15, og netsh int ipv6 set interface interface="Ethernet" metric=15 fyrir seinni fjölskylduna, því int ip snertir aðeins IPv4.
Bindiröðin er síðasta úrræðið en ekki fyrsta skrefið. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage geymir Bind-lista yfir tækjaauðkenni, og að færa auðkenni ganganna fremst breytir vissulega því hvaða millistykki er spurt fyrst, en það er vélvítt skrárgildi án umfangs fyrir hvert nafnrými. Flyttu það út fyrir breytingu og tengdu göngin svo aftur þannig að röðin gildi í því ástandi sem biðlarinn væntir.
Fyrir eitt nafnrými skaltu velja mjórra verkfærið:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers
Ákvörðun þrjú: lifir lagfæringin endurtengingu?
Mæligildi sem virkar þar til næsta hringdu-tenging endurtengist var aldrei vistað. L2TP/IPsec og aðrar tengingarsnið eru endursköpuð þegar tengingin hefst, svo vistað gildi lifir í færslu símaskrárinnar sem IpInterfaceMetric, ekki aðeins á lifandi viðmótinu. Sum umhverfi skrifa þann reit með skriftu einmitt af þessari ástæðu; önnur ýta forgangnum frá stjórnunarstefnu og láta endapunktinn í friði.
Skyndiminni og skráning eru sérstakt lag. Að keyra þetta eftir að göngin hafa risið lagar úreltar færslur og skráir biðlarann aftur, en hvorugt endurraðar millistykki:
ipconfig /registerdns
ipconfig /flushdns
Það er rofi í sama lagi. Að slökkva á kvikskráningu á líkamlega millistykkinu kemur í veg fyrir að biðlarinn tilkynni vistfang sitt á VPN-hlið undir röngu nafni, og það er önnur lagfæring en uppfærslan hér að ofan.
IPv6 á skilið eigin línu í ákvörðuninni. Ef líkamlega millistykkið ber alheims IPv6-vistfang á meðan göngin flytja aðeins IPv4, getur Windows valið slóðina án ganga fyrir nafnupplausn. Athugaðu þá fjölskyldu sérstaklega, því mæligildi stillt fyrir IPv4 segir ekkert um hana:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric
Að slökkva á IPv6 á LAN-millistykkinu fjarlægir þá slóð og samskiptaregluna með; breyting á mæligildi á IPv6-viðmótinu, eða NRPT-regla fyrir fyrirtækjanafnrýmið, heldur fjölskyldunni og lagar forganginn. Veldu mjórri kostinn nema þú hafir ákveðið að sú tenging eigi ekki að hafa IPv6.
Staðfestu með nefndri heimild, og hafðu einn eiganda
Staðfestu með verkfærum sem segja til um hvaða heimild er í gildi, ekki bara hvort síða hleðst:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A
Aðskildu svo síun frá vali, því innan úr forriti líta þau eins út. block-outside-dns hjá OpenVPN lokar porti 53 á öðrum millistykjum; það velur ekki upplausnara. Ef hver fyrirspurn mistekst núna gæti sía verið að loka eina aðgengilega þjóninum; ef horft er fram hjá stillta upplausnaranum er röðin eða nafnrýmisreglan röng. Að breyta báðu í einu gerir lokaða fyrirspurn og hunsaða fyrirspurn óaðgreinanlegar.
Hafðu einn eiganda að DNS-stefnu: VPN-sniðið, stjórnunarstefnu eða NRPT-reglu, ekki tvö þeirra. Áður en þú lýkur:
- Innýtti upplausnarinn svarar þegar hann er nefndur berum orðum, og venjuleg leit notar hann.
- Reglan eða mæligildið sem þú breyttir nær yfir vistfangafjölskylduna sem ber fyrirspurnirnar í raun.
- Stillingin lifir aftengingu og endurtengingu, eða þú hefur fært hana í vistaða sniðið.
- Nákvæmlega einn gangverkur er ráðandi, og hinir voru látnir óbreyttir.
Líttu á röðina sem ástand umhverfisins en ekki eitthvað sem lýkur. Athugaðu hana aftur eftir endurtengingu og eftir Windows-uppfærslu sem snertir netstakkinn, því hvort tveggja getur sett líkamlega millistykkið aftur fremst.