Vale DNS-server Windowsi VPN-is: metrika, sidumisjärjekord või sufiks
Kolm Windowsi mehhanismi valivad DNS-resolveri ja need ebaõnnestuvad erinevalt. Otsustage nimeruumi ulatuse, üldise järjekorra või selle järgi, kas parandus elab üle uuestiühenduse.
Windowsi klient võib omada töötavat tunnelit, kanda ettevõtte resolverit ja saata ikkagi sisemised nimed koduruuterile. Milline server vastab, otsustavad kolm erinevat mehhanismi ja need ebaõnnestuvad erinevalt. Kõiki kolme pole vaja parandada: sümptom ütleb, milline on mängus. Allolev otsustuspuu võtab paar minutit ja hoiab ära tavapärase tulemuse, kus metrikamuudatus, registri ümberjärjestus ja NRPT reegel maanduvad korraga ning keegi ei tea, milline neist midagi tegi.
Kolm mehhanismi otsustavad ja tavaliselt on üks vale
Liidese metrika järjestab adapterid antud aadressiperekonna jaoks. Sidumisjärjekord jaotise Tcpip\Linkage all on masinaülene liidese identifikaatorite loend, mida vanemad kooditeed ikka veel vaatavad. Nimelahenduse poliitikatabel (NRPT) seob nimeruumi kindlate serveritega ja sufiksi loend otsustab, kas lühinimi üldse laiendatakse. Need on sõltumatud ja seepärast kaotab VPN-adapteri õige resolver mujal asuva aegunud eelistuse vastu.
| 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 |
Ükski neist mehhanismidest ei ole tunneli teine pool. Kui server, mille VPN läbi surub, ei suuda nime lahendada, on iga kliendipoolne säte vaid kaunistus, seega esimene otsus on, kas resolver ise suudab vastata, kui seda otse küsida.
Otsus esimene: kas läbisurutud resolver üldse suudab vastata?
Küsige serverilt otsesõnu ja võrrelge seda tavalise päringuga. Vastuste vahe eraldab valikuprobleemi kättesaadavuse probleemist ja see on siin kiireim hargnemine:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type AKui esimene õnnestub ja teine ebaõnnestub, on resolver kättesaadav ja Windows valib halvasti; minge allpool nimeruumi ja järjekorra otsuste juurde. Kui ka esimene ebaõnnestub, ei aita kliendil miski: kontrollige, kas UDP ja TCP 53 jõuavad tunnelist serverini, kas serveri host-tulemüür ei viska basseini välja ja kas serveri enda edastajad on terved.
Peatuge sellel hargnemisel. NRPT reegli rakendamine resolverile, kuhu te ei pääse, tekitab sama tõrke, aga rohkema tagasivõetava konfiguratsiooniga, ja peidab tegeliku vea autoriteetsena näiva reegli taha.
Otsus teine: üks nimeruum või iga päring?
Ulatus otsustab tööriista. Kui ainult ettevõtte nimed ebaõnnestuvad, siduge nimeruum, mitte ärge järjestage masinat ümber: NRPT reegel saadab selle sufiksi tunneli resolverile ja jätab kõik muu rahule. Kui mõjutatud on iga päring, on probleemiks ülemasiniline adapterieelistus, ja metrika on koht, kust alustada, sest see ei muuda ühtki serverisätet.
Määrake metrika aadressiperekonna kaupa, mõlemal liidesel, ja kinnitage seejärel järjekord:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6Asendage 11 tunnelisadapteri ifIndexiga ülalolevalt realt; kui 11 on LAN-adapter, langetab sama käsk vale tee. Kui tõstate hoopis LAN-adapterit, jõuate sama järjekorrani teiselt poolt: netsh int ip set interface interface="Ethernet" metric=15, ja teise perekonna jaoks netsh int ipv6 set interface interface="Ethernet" metric=15, sest int ip puudutab ainult IPv4.
Sidumisjärjekord on viimane abinõu, mitte esimene samm. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage hoiab seadme identifikaatorite loendit Bind ja tunneli identifikaatori ette toomine muudab tõesti, millist adapterit esimesena küsitakse, kuid see on masinaülene registriväärtus, millel puudub nimeruumipõhine ulatus. Eksportige see enne muutmist ja ühendage tunnel hiljem uuesti, et järjekord kehtiks olekus, mida klient ootab.
Ühe nimeruumi jaoks eelistage kitsamat vahendit:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersOtsus kolmas: kas parandus elab üle uuestiühenduse?
Metrika, mis töötab kuni järgmise sissehelistamisühenduseni, ei olnud kunagi salvestatud. L2TP/IPsec ja teised ühendusprofiilid luuakse ühenduse alguses uuesti, seega salvestatud väärtus elab telefoniraamatu kirjes kui IpInterfaceMetric, mitte ainult aktiivsel liidesel. Mõned keskkonnad skriptivad seda välja just sel põhjusel; teised suruvad eelistuse halduspoliitikast ja jätavad lõpp-punkti rahule.
Vahemälu ja registreerimine on eraldi kiht. Nende käivitamine pärast tunneli tõusmist parandab aegunud kirjed ja registreerib kliendi uuesti, kuid kumbki ei järjesta adapterit ümber:
ipconfig /registerdns
ipconfig /flushdnsSamas kihis on väljalüliti. Dünaamilise registreerimise keelamine füüsilisel adapteril takistab kliendil kuulutada oma VPN-poolset aadressi vale nime all, mis on teistsugune parandus kui ülalpool kirjeldatud värskendus.
IPv6 väärib otsuses omaette rida. Kui füüsilisel adapteril on globaalne IPv6 aadress, samal ajal kui tunnel kannab ainult IPv4, võib Windows nime lahendamisel eelistada tunnelita teed. Kontrollige seda perekonda eraldi, sest IPv4 jaoks seatud metrika ei ütle selle kohta midagi:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricIPv6 keelamine LAN-adapteril eemaldab selle tee ja koos sellega protokolli; metrikamuudatus IPv6 liidesel või NRPT reegel ettevõtte nimeruumi jaoks hoiab perekonna alles ja parandab eelistuse. Valige kitsam, kui te pole otsustanud, et sellel lingil ei tohiks IPv6 olla.
Kontrollige nimetatud allikaga ja hoidke ühte omanikku
Kontrollige tööriistadega, mis teatavad, milline allikas kehtib, mitte ainult seda, kas leht laaditakse:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type ASeejärel eraldage filtreerimine valikust, sest rakenduse seest näevad need identsed välja. OpenVPN-i block-outside-dns blokeerib pordi 53 teistel adapteritel; see ei vali resolverit. Kui nüüd ebaõnnestub iga päring, võib filter blokeerida ainsa kättesaadava serveri; kui konfigureeritud resolverit eiratakse, on järjekord või nimeruumireegel vale. Mõlema korraga muutmine teeb blokeeritud päringu ja eiratud päringu eristamatuks.
Hoidke DNS-poliitikal üks omanik: VPN-profiil, halduspoliitika või NRPT reegel, mitte kaks neist. Enne sulgemist:
- Läbisurutud resolver vastab, kui seda otsesõnu nimetada, ja tavaline päring kasutab seda.
- Muudetud reegel või metrika katab selle aadressiperekonna, mis päringuid tegelikult kannab.
- Säte elab üle katkestuse ja uuestiühenduse, või olete selle salvestatud profiili viinud.
- Autoriteetne on täpselt üks mehhanism ja ülejäänud jäeti nii, nagu olid.
Käsitlege järjekorda keskkonnaseisundina, mitte asjana, mille lõpetate. Kontrollige seda uuesti pärast uuestiühendust ja pärast Windowsi värskendust, mis puudutab võrgupaketti, sest kumbki võib füüsilise adapteri taas ette tuua.