En forespørgsel forlader maskinen og når hjemmerouteren, mens hver pakke tunneleres. Den nærliggende konklusion er en manglende rute, og ruten er som regel i orden. Windows kan vælge, hvilket interface der skal spørges, ud fra interfacemetrikken, og en tunneladapter taber ofte den sammenligning til den trådløse.

To forklaringer på ét læk

Ruteforklaringen siger, at en del af trafikken undslipper tunnelen, så standardruten eller split-tunnel-listen må være forkert. Den forklaring kan testes med én kommando, og når standardruten peger ind i tunnelen, er den afgjort. Tjek den først, fordi den er billig, og læg den så til side, når den kommer tilbage ren.

Rangforklaringen siger, at trafikken er fuldt tunneleret, og at opslaget stadig sendes til en anden resolver. Windows behandler resolvervalget som en egenskab for hvert interface med en rækkefølge, så en fysisk adapter med bedre metrik kan levere DNS for et navn, selv om pakkerne til den opløste adresse går gennem tunnelen. Begge forklaringer giver samme symptom på en læk-testside, derfor er testen ikke diagnosen. Kun én af dem repareres ved at redigere ruter.

Sammenlign metrikker og resolvere samlet

Notér interface, deres metrikker og deres konfigurerede servere, mens tunnelen er oppe. Læs dem som en tabel og ikke som to separate lister, fordi spørgsmålet er, hvilken resolver der rangerer først, ikke hvilke resolvere der findes.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Hvis tunneladapteren har et højere tal end den fysiske adapter, er dens resolver ikke foretrukket, og et internt navn går til det, den fysiske side tilbyder. Den router kan svare fra cache, videresende forespørgslen eller afvise den, og ingen af de udfald er det design, du havde tænkt dig. Rækkefølgen er en præference, så den taber i det stille i stedet for at rejse en fejl.

En tunneladapter helt uden konfigureret resolver er en lige så almindelig variant. Klienten rejser interfacet uden at skubbe DNS, så spørgsmålet om rangering opstår slet ikke.

Rangér tunnelen højere og tjek igen

Giv tunnelinterfacet den laveste metrik, eller hæv den fysiske adapters værdi, i en shell med forhøjede rettigheder. Begge er indstillinger for hvert interface, og begge kan rulles tilbage, hvilket betyder noget, når du ændrer en maskine, du måske ikke sidder foran.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Ændringen ses med det samme, og DNS-klienten og andre forbrugere cacher det valg, de allerede har truffet. Genopret forbindelsen til tunnelen, eller genstart, før du læser noget ind i et forespørgselsresultat. En test, der køres for tidligt, gentager den gamle adfærd og ser ud som en mislykket rettelse.

Spørg derefter et internt og et offentligt navn og tjek, hvilken server der svarede. Microsofts reference om automatiske metrikker forklarer, hvorfor den laveste værdi foretrækkes, og hvordan den automatiske tildeling udledes.

Gør det holdbart over en genopkobling

En manuel metrik på en adapter, der genskabes ved hver forbindelse, er en indstilling, der forsvinder. Hvis klienten genopbygger interfacet, kræver tilsidesættelsen et script efter forbindelsen, en politik eller en klientkonfiguration, der ejer DNS, mens forbindelsen varer.

Statisk konfigurerede servere på den fysiske adapter har samme holdbarhedsproblem omvendt. De bliver ved med at svare for det interface, indtil de fjernes, og DHCP vil genopfylde dem fra næste leje, så at fjerne dem er en måling og ikke et design. Det holdbare design er en navneopløsningspolitik for det interne navnerum, eller en klient, der overtager DNS i forbindelsens levetid. Under alle omstændigheder skal du notere resolverlisten før og efter en genopkobling, gendanne den oprindelige metrik, når du er færdig med at teste, og bekræfte, at den tidligere adfærd er vendt tilbage.

Relaterede artikler