Windows VPN-DNS-lek: waarom die metrieke waarde die roete klop

’n Navraag verlaat die masjien en bereik die tuisrouter terwyl elke pakket deur die tonnel gestuur word. Die natuurlike gevolgtrekking is ’n ontbrekende roete, en die roete is gewoonlik heeltemal reg. Windows kan deur middel van die koppelvlakmetriek kies watter koppelvlak se oplosser geraadpleeg word, en ’n tonneladapter verloor dié vergelyking dikwels teen die draadlose een.

Twee verklarings vir een lek

Die roeteverklaring sê dat ’n deel van die verkeer uit die tonnel ontsnap, so die verstekroete of die lys vir verdeelde tonnel moet verkeerd wees. Daardie verklaring kan met een opdrag getoets word, en wanneer die verstekroete in die tonnel in wys, is dit afgehandel. Kontroleer dit eerste omdat dit goedkoop is, en skuif dit dan opsy wanneer dit skoon terugkom.

Die rangskikkingsverklaring sê die verkeer is heeltemal deur die tonnel en die opsoektog word steeds na ’n ander oplosser gestuur. Windows behandel die keuse van die oplosser as ’n eienskap per koppelvlak met ’n volgorde, so ’n fisiese adapter met ’n beter metriek kan DNS vir ’n naam voorsien selfs al reis die pakkette vir die opgeloste adres deur die tonnel. Albei verklarings lewer dieselfde simptoom op ’n lektetoetsblad, daarom is die toets nie die diagnose nie. Slegs een van hulle word deur die wysiging van roetes herstel.

Vergelyk metrieke en oplossers saam

Teken die koppelvlakke, hul metrieke en hul gekonfigureerde bedieners aan terwyl die tonnel op is. Lees dit as ’n tabel eerder as twee afsonderlike lyste, want die vraag is watter oplosser eerste gerangskik is, nie watter oplossers bestaan nie.

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

As die tonneladapter ’n hoër getal as die fisiese adapter dra, word sy oplosser nie voorkeur gegee nie, en ’n interne naam sal na alles gaan wat die fisiese kant bied. Daardie router kan uit die kas antwoord, dit aanstuur of weier, en nie een van dié uitkomste is die ontwerp wat jy bedoel het nie. Die rangorde is ’n voorkeur, so dit verloor stilweg eerder as om ’n fout te veroorsaak.

’n Tonneladapter waarop glad geen oplosser gekonfigureer is nie, is ’n ewe algemene variant. Die kliënt bring die koppelvlak op sonder om DNS te stoot, so die rangskikkingsvraag kom nooit eers ter sprake nie.

Rangskik die tonnel en kontroleer weer

Gee die tonnelkoppelvlak die laagste metriek, of verhoog die fisiese adapter se waarde, in ’n opdragskulp met verhoogde regte. Albei is instellings per koppelvlak en albei is omkeerbaar, wat saak maak wanneer jy ’n masjien verander waar jy dalk nie voor sit nie.

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

Die verandering verskyn dadelik, en die DNS-kliënt en ander verbruikers kas die keuse wat hulle reeds gemaak het. Herverbind die tonnel, of herbegin, voordat jy iets uit ’n navraaguitkoms aflei. ’n Toets wat te vroeg uitgevoer word, sal die ou gedrag herhaal en soos ’n mislukte herstelling lyk.

Vra dan een interne naam en een openbare naam en kyk watter bediener geantwoord het. Microsoft se naslaanwerk oor outomatiese metrieke verduidelik waarom die laagste waarde voorkeur kry en hoe die outomatiese toewysing afgelei word.

Maak dit bestendig oor ’n herverbinding

’n Handmatige metriek op ’n adapter wat by elke verbinding herskep word, is ’n instelling wat verdwyn. As die kliënt die koppelvlak herbou, het die oorskrywing ’n skrip ná die verbinding, ’n beleid of ’n kliëntkonfigurasie nodig wat DNS besit terwyl daar verbinding is.

Staties gekonfigureerde bedieners op die fisiese adapter het dieselfde duursaamheidsprobleem in omgekeerde rigting. Hulle bly vir daardie koppelvlak antwoord totdat hulle verwyder word, en DHCP sal hulle uit die volgende huur hervul, so om hulle te verwyder is ’n meting eerder as ’n ontwerp. Die bestendige ontwerp is ’n naamoplossingsbeleid vir die interne naamruimte, of ’n kliënt wat DNS vir die duur van die verbinding oorneem. Hoe dit ook al sy, teken die oplosserlys voor en ná ’n herverbinding aan, herstel die oorspronklike metriek wanneer jy klaar getoets het, en bevestig dat die vorige gedrag teruggekeer het.