VPN tog över DNS och bröt lokala namn: reparera listan

Tunneln kommer upp, intranätet laddas och skrivarens namn slutar lösas upp. Eller tvärtom: lokala namn fungerar fortfarande medan allt inne i företagsnätet får tidsutfall. Båda symtomen kommer från samma ställe, en resolverlista som VPN-klienten skrev om när den anslöt.

Reparera listan medvetet och ta sedan push-mekanismen separat. Rutter är ett tredje ämne och inte det som repareras här.

Vilken lista programmen faktiskt använder

Windows löser upp via inställningar på gränssnittsnivå och inte via det en dialog visar, så börja med de effektiva listorna per gränssnitt. Aliaset betyder mer än det visade namnet, eftersom varje kommando nedan vänder sig till ett gränssnitt. Tar du fel alias landar reparationen på fel adapter. Det ser ut att fungera till nästa återanslutning, när tunnelns egen post kommer tillbaka.

Frågan är vilka servrar som hamnade först och om de kom som statiska poster eller som DHCP-lease. Båda fakta avgör vilken reparation du har tillgång till.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Läs utdata för tunneladaptern och för den fysiska, och anteckna varje adress på var och en. En statisk post kan tas bort av en policy eller ett skript; en DHCP-levererad post är bunden till leasen och kommer tillbaka, vilket ändrar reparationen du bör välja. Namn i fjärrnätet löses av den annonserade resolvern, namn på det lokala LAN-et av den fysiska adaptern, och frågan går till den lista som konsulteras först.

Ta bort de pushade servrarna, eller rangordna dem lägre

Radera de pushade servrarna när inget inne i tunneln behöver dem, eftersom den fysiska adapterns egna resolvrar tar över igen. Behåll dem bara om fjärrnätet äger zoner som bara dess servrar kan svara på, och sätt i så fall en lokal resolver framför dem. De två kommandona nedan täcker båda valen, så välj det som passar situationen i stället för att köra båda.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Index 1 konsulteras först, så de pushade adresserna förblir tillgängliga men slutar vara standardsvaret på varje fråga. Flaggan validate=no hoppar över ett tillgänglighetstest som ofta misslyckas medan tunneln fortfarande stabiliseras, så bekräfta resultatet med kommandot show i stället för att lita på utgångskoden.

Två gränser är värda att känna till innan du litar på detta. Windows raderar inte servrar som kom via DHCP genom netsh, och dessa värden består som DhcpNameServer under gränssnittets registernyckel, så en registerändring är en sista utväg som måste kontrolleras igen efter nästa lease. Inte heller adaptrarnas bindningsordning är en pålitlig rangordningsmekanism, eftersom en VPN-klient kan sätta in sin egen post högst upp i listan.

Var pushen kan filtreras

En bättre reparation tar bort valet innan det tillämpas. Community OpenVPN-klienten kan filtrera ett pushat direktiv efter namn, vilket lämnar serverns konfiguration orörd.

pull-filter ignore "dhcp-option DNS "

Mellanslaget i slutet hör till matchningen och filtret namnger valet och inte en serveradress. Om profilen också innehåller ett block-outside-dns-direktiv ändrar borttagningen av det läckskyddet och inte namnmatchningen, så avgör det separat i stället för att slå ihop de två ändringarna.

För ett enda envis värdnamn är en rad i Windows hosts-fil mer stabilt än att ordna om resolvrar för hela maskinen. Det är också osynligt för nästa person, så anteckna det där maskinens konfiguration dokumenteras.

Få reparationen att överleva en återanslutning

Namnmatchningen måste testas två gånger, en gång mot en vald server och en gång i den form ett program använder. Det paret skiljer ett resolver-ordningsproblem från en server som inte svarar alls. Hoppar du över det första testet blir de två orsakerna sammanflätade.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Anslut tunneln igen och upprepa båda kommandona. Det du ändrade för hand håller bara till nästa anslutning, eftersom klienten bygger upp sitt resolverläge på nytt medan den reser adaptern. Sätt netsh-raderna i klientens stödda anslutningsskript, låt skriptet avslutas med framgång och lägg till en kort väntan innan det körs. En klient som tillämpar DNS efter skriptet skriver över resultatet ändå.

Om offentliga namn löses upp och interna fortfarande misslyckas efter reparationen är resolverlistan inte längre den misstänkta. Frågan når förmodligen inte servern alls, vilket pekar på routing eller en brandväggsregel och inte på ännu en DNS-inställning. Anteckna gränssnittets alias och adresserna du landade på, eftersom båda varierar mellan maskiner och ingen av dem överlever en ombyggnad på egen hand.