Malĝusta DNS-servilo en Windows VPN: metriko, bindordo aŭ sufikso

Windows-kliento povas havi funkciantan tunelon, porti la entreprenan solvilon kaj tamen sendi internajn nomojn al la hejma enkursigilo. Tri malsamaj mekanismoj decidas, kiu servilo respondas, kaj ili malsukcesas malsame. Vi ne devas ripari ĉiujn tri: la simptomo diras al vi, kiu estas en la ludo. La decidarbo sube daŭras kelkajn minutojn kaj malhelpas la kutiman rezulton, kie metrika ŝanĝo, reordigo de la registrejo kaj NRPT-regulo alvenas kune kaj neniu scias, kiu ion faris.

Tri mekanismoj decidas, kaj kutime unu estas malĝusta

La interfaca metriko ordigas adaptilojn por difinita adresfamilio. La bindordo sub Tcpip\Linkage estas tutmaŝina listo de interfacaj identigiloj, kiun pli malnovaj kodvojoj ankoraŭ konsultas. La Nomrezolucia Politika Tabelo (NRPT) ligas nomspacon al difinitaj serviloj, kaj la sufiksa listo decidas, ĉu mallonga nomo entute etendiĝas. Ili estas sendependaj, kaj tial ĝusta solvilo sur la VPN-adaptilo perdas al kaduka prefero aliloke.

Neniu el ĉi tiuj mekanismoj estas la alia flanko de la tunelo. Se la servilo, kiun la VPN puŝas, ne povas solvi la nomon, ĉiu agordo ĉe la klienta flanko estas nur ornamo, do la unua decido estas, ĉu la solvilo mem povas respondi, kiam oni demandas ĝin rekte.

Decido unu: ĉu la puŝita solvilo entute povas respondi?

Demandu la servilon eksplicite kaj komparu tion kun ordinara serĉo. La breĉo inter la respondoj apartigas elektoproblemon de atingebloproblemo, kaj ĝi estas la plej rapida disforkiĝo ĉi tie:

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

Se la unua sukcesas kaj la dua malsukcesas, la solvilo estas atingebla kaj Windows elektas malbone; iru al la decidoj pri nomspaco kaj ordo sube. Se la unua ankaŭ malsukcesas, nenio ĉe la kliento helpos: kontrolu, ĉu UDP kaj TCP 53 atingas la servilon tra la tunelo, ĉu gastiga fajromuro sur la servilo forĵetas la naĝejon, kaj ĉu la propraj plusendiloj de la servilo sanas.

Haltu ĉe ĉi tiu disforkiĝo. Apliki NRPT-regulon al solvilo, kiun vi ne povas atingi, produktas la saman fiaskon kun pli da agordo por malfari, kaj ĝi kaŝas la veran difekton malantaŭ regulo, kiu aspektas aŭtoritata.

Decido du: unu nomspaco aŭ ĉiu demando?

La amplekso decidas la ilon. Kiam malsukcesas nur entreprenaj nomoj, ligi la nomspacon anstataŭ reordigi la maŝinon: NRPT-regulo sendas tiun sufikson al la solvilo de la tunelo kaj lasas ĉion alian trankvila. Kiam ĉiu serĉo estas trafita, la problemo estas tutmonda adaptila prefero, kaj la metriko estas la loko por komenci, ĉar ĝi ŝanĝas neniun servilan agordon.

Agordu la metrikon laŭ adresfamilio, sur ambaŭ interfacoj, kaj poste konfirmu la ordon:

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

Anstataŭigu 11 per la ifIndex de la tunela adaptilo el la linio supre; se 11 estas la LAN-adaptilo, la sama komando malaltigas la malĝustan vojon. Altigi la LAN-adaptilon anstataŭe atingas la saman ordon de la alia flanko: netsh int ip set interface interface="Ethernet" metric=15, kaj netsh int ipv6 set interface interface="Ethernet" metric=15 por la dua familio, ĉar int ip tuŝas nur IPv4.

La bindordo estas la lasta rimedo, ne la unua paŝo. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage tenas liston Bind de aparataj identigiloj, kaj movi la tunelan identigilon antaŭen ja ŝanĝas, kiun adaptilon oni demandas unue, sed ĝi estas tutmaŝina registreja valoro sen amplekso laŭ nomspaco. Eksportu ĝin antaŭ redaktado, kaj poste rekopplektu la tunelon, por ke la ordo validu en la stato, kiun la kliento atendas.

Por unu nomspaco, preferu la pli mallarĝan instrumenton:

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

Decido tri: ĉu la riparo postvivas rekonekton?

Metriko, kiu funkcias ĝis la sekva telefonkonekta rekonekto, neniam estis konservita. L2TP/IPsec kaj aliaj konektaj profiloj estas rekreiataj, kiam la konekto komenciĝas, do la konservita valoro vivas en la telefonlibra enskribo kiel IpInterfaceMetric, ne nur sur la viva interfaco. Iuj medioj skriptigas tiun kampon ĝuste pro tio; aliaj puŝas la preferon el administra politiko kaj lasas la finpunkton trankvila.

Kaŝmemoro kaj registrado estas aparta tavolo. Ruli ĉi tion post kiam la tunelo leviĝas riparas kadukajn enskribojn kaj registras la klienton denove, sed nek unu nek la alia reordigas adaptilon:

ipconfig /registerdns
ipconfig /flushdns

En la sama tavolo estas malŝaltilo. Malŝalti dinamikan registradon sur la fizika adaptilo malhelpas la klienton anonci sian VPN-flankan adreson sub la malĝusta nomo, kio estas alia riparo ol la refreŝigo supre.

IPv6 meritas propran linion en la decido. Se la fizika adaptilo havas tutmondan IPv6-adreson dum la tunelo portas nur IPv4, Windows povas preferi la sentunelan vojon por nomrezolucio. Kontrolu tiun familion aparte, ĉar metriko agordita por IPv4 diras nenion pri ĝi:

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

Malŝalti IPv6 sur la LAN-adaptilo forigas tiun vojon kaj la protokolon kun ĝi; metrika ŝanĝo sur la IPv6-interfaco, aŭ NRPT-regulo por la entreprena nomspaco, konservas la familion kaj korektas la preferon. Elektu la pli mallarĝan, se vi ne decidis, ke tiu ligilo ne havu IPv6.

Kontrolu kun nomita fonto, kaj tenu unu posedanton

Kontrolu per iloj, kiuj raportas, kiu fonto validas, ne nur ĉu paĝo ŝargiĝas:

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

Poste apartigu filtradon de elekto, ĉar de interne de aplikaĵo ili aspektas identaj. block-outside-dns de OpenVPN blokas pordon 53 sur la aliaj adaptiloj; ĝi ne elektas solvilon. Se nun ĉiu demando malsukcesas, filtrilo eble blokas la sola atingeblan servilon; se la agordita solvilo estas ignorata, la ordo aŭ la nomspaca regulo estas malĝusta. Ŝanĝi ambaŭ samtempe igas blokitan demandon kaj ignoritan demandon nedistingeblaj.

Tenu unu posedanton por la DNS-politiko: la VPN-profilo, administra politiko aŭ NRPT-regulo, ne du el ili. Antaŭ ol vi fermos ĝin:

• La puŝita solvilo respondas, kiam oni nomas ĝin eksplicite, kaj ordinara serĉo uzas ĝin.
• La regulo aŭ metriko, kiun vi ŝanĝis, kovras la adresfamilion, kiu efektive portas la demandojn.
• La agordo postvivas malkonekton kaj rekonekton, aŭ vi movis ĝin en la konservitan profilon.
• Ekzakte unu mekanismo estas aŭtoritata, kaj la aliaj restis kiel ili estis.

Traktu la ordon kiel media stato, ne kiel aferon, kiun oni finas. Rekontrolu ĝin post rekonekto kaj post Windows-ĝisdatigo, kiu tuŝas la retan stakon, ĉar unu aŭ la alia povas remeti la fizikan adaptilon antaŭen.