Waarom nslookup via de VPN werkt, maar de browser niet

nslookup stuurt een query naar de server die u noemt en drukt het antwoord af, daarom kan het slagen terwijl elk browsertabblad faalt. Een browser vraagt het besturingssysteem om te resolven, en het besturingssysteem weegt resolvers per interface, regels voor naamresolutiebeleid en de netwerklocatie van de adapter. Daarna kan de browser zijn eigen versleutelde DNS eroverheen leggen. Drie verschillende paden, één symptoom, en de tunnel is meestal niet het kapotte deel.

De controles hieronder volgen die paden van het systeem naar buiten. Wijzig het VPN-profiel pas als u weet welk pad antwoordde en welk pad faalde.

Drie beleidsregels bepalen het antwoord

Elke interface draagt zijn eigen resolverlijst en zoekachtervoegsels. Een VPN-adapter voegt servers toe terwijl de fysieke adapter de zijne houdt, en het systeem kan degene nemen die het eerst antwoordt, dus een lookup kan buiten de tunnel worden bediend zonder dat iemand dat koos. Regels uit de naamresolutiebeleidstabel kunnen geselecteerde domeinen naar geselecteerde servers sturen, en zo wordt split DNS op Windows meestal uitgedrukt. En de VPN-client of gateway kan een resolveradres pushen dat alleen binnen het privénetwerk bestaat.

Die drie werken op manieren samen die vanuit een browser willekeurig lijken. Een gepushte resolver op een privéadres zonder route door de split-tunnel laat elke lookup vastlopen en daarna falen. Een beleidsregel die het interne achtervoegsel dekt en naar een uitgevallen server wijst, levert dezelfde zichtbare fout als een ontbrekende route. Een zoekachtervoegsel dat op de VPN-adapter ontbreekt maakt van een korte naam een openbare query voor het verkeerde domein. Elk ervan vraagt een andere reparatie.

Waarom de browser een andere vraag stelt

nslookup stuurt zijn eigen query naar de server die het kiest en volgt noch het naamruimtebeleid noch de instelling voor versleutelde DNS van de browser. Daarom antwoordt een handmatige query naar een openbare resolver terwijl de browser meldt dat de site niet bestaat. U vergelijkt twee programma's, niet twee toestanden van één programma.

Adresfamilievoorkeur verklaart vertraging en geen storing. Een browser die eerst IPv6-records opvraagt op een tunnel die alleen IPv4 draagt, wacht op een time-out voordat hij terugvalt. Firefox heeft hiervoor precies een voorkeur gehad, en die uitschakelen is een diagnosestap, geen reparatie.

Lees de resolverlijst en de regels

Dump op Windows wat het systeem vasthoudt voordat u theoriseert. Get-DnsClientServerAddress toont de servers per interface, Get-DnsClientNrptRule somt de naamruimteregels op, en Resolve-DnsName beantwoordt de exacte naam via het systeempad. Vergelijk dat antwoord met een rechtstreekse query naar de server van de VPN op adres. Als Resolve-DnsName faalt en de rechtstreekse query slaagt, zijn de resolverlijst of een naamruimteregel de verdachte.

Controleer ook de naam zelf. Een interne korte naam heeft misschien het privéachtervoegsel nodig dat alleen de VPN-adapter levert, terwijl de volledig gekwalificeerde naam prima resolvet. Een certificaatwaarschuwing na een geslaagde lookup hoort bij een ander probleem.

De onbereikbare gepushte resolver

Een gateway of client kan een resolveradres pushen, en dat adres moet via de tunnel bereikbaar zijn. Op een split-tunnel staat het privébereik met de resolver misschien niet in de inbegrepen routes, wat een lookup oplevert die nooit antwoord krijgt. Bevestig dat de route bestaat en vraag dan specifiek dat adres op, via de tunnel. Dit is de fout achter een domeinfout in de browser terwijl een openbare resolver nog antwoordt.

Als de resolver onbereikbaar is, is de reparatie een route of een inbegrepen subnet, geen andere DNS-server.

Versleutelde DNS omzeilt het hele pad

Browsers met DNS-over-HTTPS resolven namen zelf via een HTTPS-verbinding naar een gekozen provider. Met dat aan worden de systeemresolver en de split-DNS-regels voor die lookups volledig omzeild, dus interne namen falen in de browser terwijl het besturingssysteem ze correct resolvet. Het omgekeerde gebeurt ook: interne namen slagen in de browser via een provider die ze nooit had mogen zien, en dat is een beleidsprobleem en geen connectiviteitsprobleem.

Bepaal bewust of versleutelde DNS is toegestaan op beheerde apparaten, en configureer het dan via het beheeropervlak van de browser zodat de keuze zichtbaar is. Het aan individuele voorkeur overlaten levert een vloot op waarin dezelfde VPN op elke laptop anders werkt.

Reparaties die bij de storing passen

Als de VPN zijn resolver pusht, zorg dan dat de tunnel verkeer ernaartoe draagt en dat dezelfde instelling zichtbaar is op de adapters die aan resolutie deelnemen. Als lokale sites niet meer resolven terwijl u verbonden bent, voeg dan expliciete naamruimte-uitzonderingen of een voorwaardelijke doorstuurder toe in plaats van de resolver in zijn geheel te vervangen. Als de versleutelde DNS van de browser het beleid omzeilt, is dat de instelling die moet veranderen. Voeg nooit een openbare resolver toe om een interne naam te repareren: het lekt privéquery's en resolvet de naam niet.

Scheid daarna de lookup van de verbinding. Een naam die naar het juiste adres resolvet maar een verbinding weigert, is een dienst-, firewall- of certificaatprobleem, en DNS-wijzigingen lossen dat niet op.

Noteer welk pad antwoordde, welk faalde en wat u wijzigde. Het volgende rapport over hetzelfde symptoom kost dan één commando in plaats van een middag.