Ferkearde DNS-server yn Windows VPN: metryk, biningsoarder of efterheaksel
Trije Windows-meganismen kieze de DNS-resolver, en se mislearje ferskillend. Beslis op berik fan de nammromte, globale oarder of oft in repaasje in werferbining oerlibbet.
In Windows-klant kin in wurkjende tunnel hawwe, de bedriuwsresolver drage en dochs ynterne nammen nei de thúsrouter stjoere. Trije ferskillende meganismen beslisse hokker server antwurdet, en se mislearje op ferskillende wizen. Do hoechst net alle trije te reparearjen: it symptoom fertelt dy hokker yn it spul is. De beslissingsbeam hjirûnder kostet in pear minuten en foarkomt de gewoane útslach, wêrby't in metrykwiziging, in weromriffeling fan it register en in NRPT-regel tegearre lânje en nimmen wit hokker oft wat die.
Trije meganismen beslisse, en meastentiids is ien ferkeard
De ynterfacemetryk oardert adapters foar in opjûne adresfamylje. De biningsoarder ûnder Tcpip\Linkage is in masinebrede list fan ynterface-identifikaasjes dy't âldere kodepaden noch hieltyd rieplachtsje. De Namme-oplossingsbeliedstabel (NRPT) bynt in nammromte oan spesifike servers, en de efterheaksel-list beslút oft in koarte namme hielendal útwreide wurdt. Se binne ûnôfhinklik, en dêrom ferliest in korrekte resolver op de VPN-adapter tsjin in ferâldere foarkar earne oars.
| 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 |
Net ien fan dizze meganismen is de oare kant fan de tunnel. As de server dy't de VPN triuwt de namme net oplosse kin, is elke ynstelling oan de kliïntkant fersiering, dus de earste beslissing is oft de resolver sels antwurdzje kin as do it direkt freget.
Beslissing ien: kin de triuwde resolver hielendal antwurdzje?
Freegje de server eksplisyt en fergelykje dat mei in gewoane syktocht. It gat tusken de antwurden skiedt in seleksjeprobleem fan in berikberensprobleem, en it is hjir de fluchste splitsing:
Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type AAs de earste slagget en de twadde mislearret, is de resolver berikber en kiest Windows min; gean nei de beslissings oer nammromte en oarder hjirûnder. As de earste ek mislearret, helpt neat op de kliïnt: kontrolearje oft UDP en TCP 53 de server troch de tunnel berikke, oft gjin host-firewall op de server de pool falle lit, en oft de eigen trochstjoerders fan de server sûn binne.
Stop by dizze splitsing. In NRPT-regel tapasse op in resolver dy't do net berikke kinst, jout deselde flater mei mear konfiguraasje om werom te draaien, en it ferberget de wiere fout efter in regel dy't gesachhawwend liket.
Beslissing twa: ien nammromte, of elke oanfrage?
It berik beslút it ark. As allinnich bedriuwsnammen mislearje, bynt de nammromte yn stee fan de masine te weromriffeljen: in NRPT-regel stjoert dat efterheaksel nei de resolver fan de tunnel en lit al it oare gewurde. As elke syktocht rekke wurdt, is it probleem globale adapterfoarkar, en de metryk is it plak om te begjinnen, want it feroaret gjin serverynstelling.
Set de metryk per adresfamylje, op beide ynterfaces, en befêstigje dêrnei de oarder:
Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6Ferfang 11 troch de ifIndex fan de tunneladapter út de rigel hjirboppe; as 11 de LAN-adapter is, ferleget deselde opdracht it ferkearde paad. De LAN-adapter ferheegje berikt deselde oarder fan de oare kant: netsh int ip set interface interface="Ethernet" metric=15, en netsh int ipv6 set interface interface="Ethernet" metric=15 foar de twadde famylje, want int ip rekket allinnich IPv4.
De biningsoarder is it lêste middel en net de earste stap. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage hâldt in Bind-list fan apparaat-identifikaasjes, en it identifikaasje fan de tunnel nei foaren helje feroaret wol hokker adapter oft earst frege wurdt, mar it is in masinebrede registerwearde sûnder berik per nammromte. Eksportearje it foar it bewurkjen en ferbyn de tunnel dêrnei op 'e nij, sadat de oarder jildt yn de tastân dy't de kliïnt ferwachtet.
Foar ien nammromte, foarkar foar it smelste ynstrumint:
Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServersBeslissing trije: oerlibbet de repaasje in werferbining?
In metryk dy't wurket oant de folgjende ynbelferbining wer ferbynt, wie nea bewarre. L2TP/IPsec en oare ferbiningsprofylen wurde op 'e nij makke as de ferbining begjint, dus de bewarre wearde libbet yn 'e telefoanboek-yngong as IpInterfaceMetric, net allinnich op 'e libbene ynterface. Guon omjouwings skriptsje dat fjild krekt dêrom; oaren triuwe de foarkar fan belied ôf en litte it einpunt gewurde.
Cache en registraasje binne in aparte laach. Dizze rinne litte nei't de tunnel omheech kaam is, reparearret ferâldere yngongen en registrearret de kliïnt op 'e nij, mar gjin fan beide oardert in adapter wer:
ipconfig /registerdns
ipconfig /flushdnsDer is in útskeakelder yn deselde laach. Dynamyske registraasje op 'e fysike adapter útskeakelje stopet de kliïnt om syn adres oan de VPN-kant ûnder de ferkearde namme oan te kundigjen, wat in oare repaasje is as de ferfrissing hjirboppe.
IPv6 fertsjinnet syn eigen rigel yn 'e beslissing. As de fysike adapter in globale IPv6-adres hat wylst de tunnel allinnich IPv4 draacht, kin Windows it paad sûnder tunnel foarkar jaan foar namme-oplossing. Kontrolearje dy famylje apart, want in metryk dy't foar IPv4 set is, seit neat oer dy:
Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetricIPv6 útskeakelje op de LAN-adapter hellet dat paad en it protokol der mei wei; in metrykwiziging op 'e IPv6-ynterface, of in NRPT-regel foar de bedriuwsnammromte, hâldt de famylje en reparearret de foarkar. Kies de smelste, útsein as do besletten hast dat dy ferbining gjin IPv6 hawwe moat.
Ferifiearje mei de neamde boarne, en hâld ien eigner
Ferifiearje mei ark dy't rapportearje hokker boarne jildt, net allinnich oft in side lade wurdt:
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type ASkied dan filterjen fan seleksje, want fanút in applikaasje lykje se identyk. block-outside-dns fan OpenVPN blokkearret poarte 53 op 'e oare adapters; it kiest gjin resolver. As no elke oanfrage mislearret, blokkearret in filter miskien de iennichste berikbere server; as de konfigurearre resolver negearre wurdt, is de oarder of de nammromteregel ferkeard. Beide tagelyk feroarje makket in blokkearre oanfrage en in negearre oanfrage net te ûnderskieden.
Hâld ien eigner foar DNS-belied: it VPN-profyl, in behearbelied of in NRPT-regel, net twa dêrfan. Foardat do it slútst:
- De triuwde resolver antwurdet as er eksplisyt neamd wurdt, en in gewoane syktocht brûkt him.
- De regel of metryk dy't do feroare hast, dekt de adresfamylje dy't de oanfragen wier draacht.
- De ynstelling oerlibbet in ôfbrekking en werferbining, of do hast him nei it bewarre profyl ferpleatst.
- Krekt ien meganisme is gesachhawwend, en de oare binne litten sa't se wiene.
Behannelje de oarder as omjouwingstastân en net as iets dat do ôfmeitsje. Kontrolearje him op 'e nij nei in werferbining en nei in Windows fernijing dy't de netwurkstapel rekket, want elk fan beide kin de fysike adapter wer foaroan sette.