Verkeerde DNS-server in Windows VPN: metriek, bindingsvolgorde of suffix

Een Windows-client kan een werkende tunnel hebben, de bedrijfsresolver dragen en toch interne namen naar de thuisrouter sturen. Drie verschillende mechanismen bepalen welke server antwoordt, en ze falen op verschillende manieren. Je hoeft niet alle drie te repareren: het symptoom vertelt je welke in het spel is. De beslisboom hieronder kost een paar minuten en voorkomt de gebruikelijke uitkomst, waarbij een metriekwijziging, een herordening van het register en een NRPT-regel samen landen en niemand weet welke iets deed.

Drie mechanismen beslissen, en meestal is er één fout

De interfacemetriek ordent adapters voor een bepaalde adresfamilie. De bindingsvolgorde onder Tcpip\Linkage is een machinebrede lijst met interface-identificaties die oudere codepaden nog raadplegen. De naamresolutie-beleidstabel (NRPT) koppelt een naamruimte aan specifieke servers, en de suffixlijst bepaalt of een korte naam überhaupt wordt uitgebreid. Ze zijn onafhankelijk, en daarom verliest een correcte resolver op de VPN-adapter tegen een verouderde voorkeur elders.

Geen van deze mechanismen is de andere kant van de tunnel. Als de server die de VPN pusht de naam niet kan resolven, is elke instelling aan de clientkant versiering, dus de eerste beslissing is of de resolver zelf kan antwoorden als je hem rechtstreeks vraagt.

Beslissing één: kan de gepushte resolver überhaupt antwoorden?

Vraag het de server expliciet en vergelijk dat met een gewone lookup. Het verschil tussen de antwoorden scheidt een selectieprobleem van een bereikbaarheidsprobleem, en het is hier de snelste splitsing:

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

Als de eerste slaagt en de tweede faalt, is de resolver bereikbaar en kiest Windows slecht; ga naar de beslissingen over naamruimte en volgorde hieronder. Als de eerste ook faalt, helpt niets op de client: controleer of UDP en TCP 53 de server via de tunnel bereiken, of geen host-firewall op de server de pool laat vallen, en of de eigen doorstuurders van de server gezond zijn.

Stop bij deze splitsing. Een NRPT-regel toepassen op een resolver die je niet kunt bereiken levert dezelfde storing op met meer configuratie om terug te draaien, en het verbergt de echte fout achter een regel die gezaghebbend lijkt.

Beslissing twee: één naamruimte of elke query?

De omvang bepaalt het gereedschap. Als alleen bedrijfsnamen falen, bind dan de naamruimte in plaats van de machine te herordenen: een NRPT-regel stuurt dat suffix naar de resolver van de tunnel en laat al het andere met rust. Als elke lookup geraakt wordt, is het probleem globale adaptervoorkeur, en de metriek is het startpunt omdat die geen enkele serverinstelling wijzigt.

Stel de metriek per adresfamilie in, op beide interfaces, en bevestig daarna de volgorde:

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

Vervang 11 door de ifIndex van de tunneladapter uit de regel hierboven; als 11 de LAN-adapter is, verlaagt dezelfde opdracht het verkeerde pad. De LAN-adapter juist verhogen bereikt dezelfde volgorde vanaf de andere kant: netsh int ip set interface interface="Ethernet" metric=15, en netsh int ipv6 set interface interface="Ethernet" metric=15 voor de tweede familie, omdat int ip alleen IPv4 raakt.

De bindingsvolgorde is het laatste redmiddel en niet de eerste zet. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage bevat een Bind-lijst met apparaat-id's, en de tunnel-id naar voren halen verandert echt welke adapter eerst wordt gevraagd, maar het is een machinebrede registerwaarde zonder bereik per naamruimte. Exporteer hem voor het bewerken en verbind de tunnel daarna opnieuw, zodat de volgorde geldt in de toestand die de client verwacht.

Voor één naamruimte: gebruik het smallere instrument:

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

Beslissing drie: overleeft de fix een herverbinding?

Een metriek die werkt tot de volgende inbelverbinding is nooit opgeslagen. L2TP/IPsec en andere verbindingsprofielen worden opnieuw gemaakt wanneer de verbinding start, dus de opgeslagen waarde leeft in het telefoonboekitem als IpInterfaceMetric, niet alleen op de live interface. Sommige omgevingen scripten dat veld precies daarom; andere pushen de voorkeur vanuit een beheerbeleid en laten het eindpunt met rust.

Cache en registratie zijn een aparte laag. Deze na het opkomen van de tunnel uitvoeren repareert verouderde items en registreert de client opnieuw, maar geen van beide herordent een adapter:

ipconfig /registerdns
ipconfig /flushdns

Er is een uitschakelaar in dezelfde laag. Dynamische registratie op de fysieke adapter uitzetten voorkomt dat de client zijn adres aan de VPN-kant onder de verkeerde naam aankondigt, en dat is een andere reparatie dan de vernieuwing hierboven.

IPv6 verdient een eigen regel in de beslissing. Als de fysieke adapter een globaal IPv6-adres heeft terwijl de tunnel alleen IPv4 draagt, kan Windows het niet-getunnelde pad verkiezen voor naamresolutie. Controleer die familie apart, want een metriek die voor IPv4 is ingesteld zegt niets over haar:

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

IPv6 uitzetten op de LAN-adapter verwijdert dat pad en het protocol ermee; een metriekwijziging op de IPv6-interface, of een NRPT-regel voor de bedrijfsnaamruimte, behoudt de familie en repareert de voorkeur. Kies de smallere, tenzij je hebt besloten dat die link geen IPv6 hoort te hebben.

Verifieer met de genoemde bron, en houd één eigenaar

Verifieer met gereedschappen die melden welke bron van kracht is, niet alleen of een pagina laadt:

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

Scheid dan filteren van selecteren, want vanuit een applicatie zien ze er identiek uit. block-outside-dns van OpenVPN blokkeert poort 53 op de andere adapters; het kiest geen resolver. Als nu elke query faalt, blokkeert mogelijk een filter de enige bereikbare server; als de geconfigureerde resolver wordt genegeerd, is de volgorde of de naamruimteregel fout. Beide tegelijk wijzigen maakt een geblokkeerde query en een genegeerde query niet te onderscheiden.

Houd één eigenaar voor het DNS-beleid: het VPN-profiel, een beheerbeleid of een NRPT-regel, niet twee ervan. Voordat je het afsluit:

• De gepushte resolver antwoordt als hij expliciet wordt genoemd, en een gewone lookup gebruikt hem.
• De regel of metriek die je wijzigde dekt de adresfamilie die de queries werkelijk draagt.
• De instelling overleeft een verbreking en herverbinding, of je hebt hem naar het opgeslagen profiel verplaatst.
• Precies één mechanisme is gezaghebbend, en de andere zijn gelaten zoals ze waren.

Behandel de volgorde als omgevingstoestand en niet als iets dat je afmaakt. Controleer hem opnieuw na een herverbinding en na een Windows-update die de netwerkstack raakt, want beide kunnen de fysieke adapter weer vooraan zetten.