VPN nam DNS over en brak lokale namen: herstel de lijst

De tunnel komt op, het intranet laadt en de naam van de printer wordt niet meer opgelost. Of omgekeerd: lokale namen werken nog terwijl alles binnen het bedrijfsnetwerk in een time-out loopt. Beide symptomen komen van dezelfde plek, een resolverslijst die de VPN-client herschreef toen hij verbond.

Herstel de lijst bewust en behandel daarna het push-mechanisme apart. Routes zijn een derde onderwerp en niet wat hier wordt hersteld.

Welke lijst toepassingen echt gebruiken

Windows lost op via instellingen op interfaceniveau en niet via wat een dialoog toont, dus begin met de effectieve lijsten per interface. De alias telt meer dan de weergegeven naam, omdat elk commando hieronder een interface aanspreekt. Vergis je in de alias, dan landt de reparatie op de verkeerde adapter. Het lijkt te werken tot de volgende herverbinding, wanneer de eigen vermelding van de tunnel terugkomt.

De vraag is welke servers vooraan zijn beland en of ze als statische vermeldingen of als DHCP-lease kwamen. Beide feiten bepalen welke reparatie je ter beschikking hebt.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lees de uitvoer voor de tunneladapter en voor de fysieke adapter, en noteer elk adres op elk van beide. Een statische vermelding kan door een beleid of een script worden verwijderd; een door DHCP geleverde vermelding is aan de lease gebonden en komt terug, wat de te kiezen reparatie verandert. Namen in het externe netwerk worden opgelost door de aangekondigde resolver, namen op het lokale LAN door de fysieke adapter, en de query gaat naar de lijst die het eerst wordt geraadpleegd.

Verwijder de gepushte servers, of rangschik ze lager

Verwijder de gepushte servers wanneer niets binnen de tunnel ze nodig heeft, omdat de eigen resolvers van de fysieke adapter het weer overnemen. Houd ze alleen als het externe netwerk zones bezit die alleen zijn servers kunnen beantwoorden, en zet in dat geval een lokale resolver ervoor. De twee commando's hieronder dekken beide keuzes, dus kies degene die bij de situatie past in plaats van beide uit te voeren.

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 wordt het eerst geraadpleegd, dus de gepushte adressen blijven beschikbaar maar zijn niet langer het standaardantwoord op elke query. De vlag validate=no slaat een bereikbaarheidstest over die vaak mislukt terwijl de tunnel nog tot rust komt, dus bevestig het resultaat met het commando show in plaats van de exitcode te vertrouwen.

Twee grenzen zijn de moeite waard om te kennen voordat je hierop vertrouwt. Windows verwijdert geen servers die via DHCP door netsh kwamen, en die waarden blijven bestaan als DhcpNameServer onder de registersleutel van de interface, dus een registerwijziging is een laatste redmiddel dat na de volgende lease opnieuw moet worden gecontroleerd. Ook de bindingsvolgorde van adapters is geen betrouwbaar rangschikkingsmechanisme, omdat een VPN-client zijn eigen vermelding bovenaan de lijst kan zetten.

Waar de push kan worden gefilterd

Een betere reparatie haalt de optie weg voordat die wordt toegepast. De Community OpenVPN-client kan een gepushte richtlijn op naam filteren, waardoor de configuratie van de server onaangeroerd blijft.

pull-filter ignore "dhcp-option DNS "

De spatie aan het eind hoort bij de overeenkomst en het filter noemt de optie en niet een serveradres. Als het profiel ook een richtlijn block-outside-dns bevat, verandert het verwijderen daarvan de lekbescherming en niet de naamresolutie, dus beslis dat apart in plaats van de twee bewerkingen te bundelen.

Voor één koppige hostnaam is één regel in het Windows hosts-bestand stabieler dan het herordenen van resolvers voor de hele machine. Die is ook onzichtbaar voor de volgende persoon, dus leg het vast waar de configuratie van de machine wordt gedocumenteerd.

Zorg dat de reparatie een herverbinding overleeft

Naamresolutie moet twee keer worden getest, een keer tegen een gekozen server en een keer in de vorm die een toepassing gebruikt. Dat paar scheidt een probleem met de resolvervolgorde van een server die helemaal niet antwoordt. Wordt de eerste test overgeslagen, dan blijven de twee oorzaken verstrengeld.

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

Verbind de tunnel opnieuw en herhaal beide commando's. Wat je met de hand hebt gewijzigd, houdt alleen stand tot de volgende verbinding, omdat de client zijn resolverstatus opnieuw opbouwt terwijl hij de adapter omhoog brengt. Zet de regels van netsh in het ondersteunde verbindingsscript van je client, laat dat script met succes eindigen en voeg een korte wachttijd toe voordat het wordt uitgevoerd. Een client die DNS na het script toepast, overschrijft het resultaat toch.

Als openbare namen worden opgelost en interne namen na de reparatie nog steeds falen, is de resolverslijst niet langer de verdachte. De query bereikt de server waarschijnlijk helemaal niet, wat wijst op routering of een firewallregel en niet op nog een DNS-instelling. Noteer de alias van de interface en de adressen waarop je uitkwam, want beide verschillen per machine en geen van beide overleeft een herbouw alleen.