Uhajanje DNS pri VPN v Windows: zakaj metrika premaga pot

Poizvedba zapusti stroj in doseže domači usmerjevalnik, medtem ko vsak paket potuje skozi tunel. Naravna ugotovitev je manjkajoča pot, pot pa je običajno v redu. Windows lahko po metriki vmesnika izbere, kateri resolver bo vprašan, in tunelski vmesnik v tej primerjavi pogosto izgubi proti brezžičnemu.

Dve razlagi za eno uhajanje

Razlaga s potmi pravi, da del prometa uhaja iz tunela, zato morata biti privzeta pot ali seznam razdeljenega tunela napačna. To je mogoče preveriti z enim ukazom, in ko privzeta pot kaže v tunel, je stvar zaključena. Preverite jo najprej, ker je poceni, nato pa jo odložite, ko se vrne čista.

Razlaga z razvrstitvijo pravi, da je promet v celoti v tunelu in poizvedba se vseeno pošilja drugemu resolverju. Windows obravnava izbiro resolverja kot lastnost vsakega vmesnika z vrstnim redom, zato lahko fizični vmesnik z boljšo metriko zagotovi DNS za ime, čeprav paketi do razrešenega naslova gredo skozi tunel. Obe razlagi dajeta na strani za preizkus uhajanja enak simptom, zato preizkus ni diagnoza. Le eno od njiju je mogoče popraviti z urejanjem poti.

Primerjajte metrike in resolverje skupaj

Zapišite vmesnike, njihove metrike in nastavljene strežnike, dokler je tunel aktiven. Berite jih kot tabelo in ne kot dva ločena seznama, ker je vprašanje, kateri resolver je prvi, ne kateri resolverji obstajajo.

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

Če ima tunelski vmesnik višje število kot fizični, njegov resolver ni prednostni, in notranje ime bo šlo tja, kar ponuja fizična stran. Ta usmerjevalnik lahko odgovori iz predpomnilnika, poizvedbo posreduje ali jo zavrne, in noben od teh izidov ni zasnova, ki ste jo nameravali. Razvrstitev je prednost, zato tiho izgubi, namesto da bi sprožila napako.

Tunelski vmesnik brez kakršnega koli nastavljenega resolverja je enako pogosta različica. Odjemalec dvigne vmesnik brez potiskanja DNS, zato se vprašanje razvrstitve sploh ne pojavi.

Dvignite tunel in znova preverite

Dajte tunelskemu vmesniku najnižjo metriko ali povečajte vrednost fizičnega vmesnika v lupini z dvignjenimi pravicami. Oboje so nastavitve za posamezni vmesnik in oboje je mogoče razveljaviti, kar je pomembno, ko spreminjate stroj, pred katerim morda ne sedite.

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

Sprememba je vidna takoj, odjemalec DNS in drugi porabniki pa si shranijo že izbrano možnost. Znova povežite tunel ali znova zaženite, preden iz rezultata poizvedbe kaj sklepate. Preizkus, izveden prezgodaj, bo ponovil staro vedenje in bo videti kot neuspešno popravilo.

Nato vprašajte za eno notranje in eno javno ime in preverite, kateri strežnik je odgovoril. Microsoftova referenca o samodejnih metrikah razloži, zakaj je prednostna najnižja vrednost in kako se izpelje samodejna dodelitev.

Naredite ga obstojnega ob ponovni povezavi

Ročna metrika na vmesniku, ki se ob vsaki povezavi ustvari znova, je nastavitev, ki izgine. Če odjemalec vmesnik znova zgradi, prepis potrebuje skript po povezavi, pravilnik ali konfiguracijo odjemalca, ki ima DNS med povezavo.

Statično nastavljeni strežniki na fizičnem vmesniku imajo enako težavo s trajnostjo obrnjeno. Odgovarjajo za ta vmesnik, dokler jih ne odstranite, DHCP pa jih bo znova napolnil iz naslednjega najema, zato je njihova odstranitev meritev in ne zasnova. Trajna zasnova je pravilnik razreševanja imen za notranji imenski prostor, ali odjemalec, ki prevzame DNS za čas povezave. Kakor koli, zapišite seznam resolverjev pred ponovno povezavo in po njej, obnovite prvotno metriko, ko končate s preizkušanjem, in potrdite, da se je prejšnje vedenje vrnilo.