DNS-leki í Windows VPN: hvers vegna mælikvarðinn vinnur á leiðinni

Fyrirspurn yfirgefur vélina og nær heimaleiðaranum á meðan hver pakki er settur í tunnil. Eðlileg ályktun er leið sem vantar, og leiðin er yfirleitt í lagi. Windows getur valið hvaða leysi tengisins er spurður eftir mælikvarða tengisins, og tunnilmilli tapar þessum samanburði oft gegn þráðlausa tenginu.

Tvær skýringar á einu leki

Leiðarskýringin segir að hluti umferðarinnar sleppi út úr tunnilnum, þannig að sjálfgefna leiðin eða listinn yfir skiptan tunnil hlýtur að vera rangur. Þá skýringu má prófa með einni skipun, og þegar sjálfgefna leiðin bendir inn í tunnilinn er málinu lokið. Athugaðu hana fyrst því hún er ódýr, og leggðu hana svo til hliðar þegar hún kemur hrein til baka.

Röðunarskýringin segir að umferðin sé öll í tunnilnum og fyrirspurnin sé samt send til annars leysis. Windows líta á val leysis sem eiginleika hvers tengis með röð, svo líkamlegur milli með betri mælikvarða getur veitt DNS fyrir nafn þótt pakkarnir að leystu vistfangi fari í gegnum tunnilinn. Báðar skýringar gefa sama einkenni á lekaprófunarsíðu, þess vegna er prófið ekki greiningin. Aðeins önnur þeirra er lögfærð með því að breyta leiðum.

Berðu saman mælikvarða og leysa saman

Skráðu tengin, mælikvarða þeirra og stilltu þjónana meðan tunnilinn er uppi. Lestu þau sem töflu en ekki tvo aðskilda lista, því spurningin er hvaða leysir kemur fyrstur, ekki hvaða leysar eru til.

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

Ef tunnilmillið ber hærri tölu en líkamlegi millinn er leysir hans ekki valinn fram yfir, og innra nafn fer til þess sem líkamlega hliðin býður. Sá leiðari getur svarað úr skyndiminni, sent fyrirspurnina áfram eða hafnað henni, og engin þessara útkoma er hönnunin sem þú ætlaðir þér. Röðunin er val, svo hún tapar hljóðlega í stað þess að gefa villu.

Tunnilmilli með engan leysi stilltan er jafn algeng afbrigði. Biðlarinn ræsir tengið án þess að ýta DNS, svo spurningin um röðun kemur ekki einu sinni upp.

Raðaðu tunnilnum ofar og athugaðu aftur

Gefðu tunniltenginu lægsta mælikvarðann, eða hækkaðu gildi líkamlega millsins, í skel með auknum réttindum. Bæði eru stillingar fyrir hvert tengi og bæði eru afturkræf, sem skiptir máli þegar þú breytir vél sem þú situr kannski ekki við.

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

Breytingin birtist strax, og DNS-biðlarinn og aðrir notendur skyndimynna valið sem þeir hafa þegar gert. Tendu aftur á tunnilnum, eða endurræstu, áður en þú lest nokkuð inn í niðurstöðu fyrirspurnar. Próf sem er keyrt of fljótt endurtekur gamla hegðun og lítur út eins og misheppnuð lagfæring.

Spyrðu þá eitt innra nafn og eitt opinbert nafn og athugaðu hvaða þjónn svaraði. viðmiðin um sjálfvirka mælikvarða Microsoft útskýrir hvers vegna lægsta gildið er valið og hvernig sjálfvirka úthlutunin er leidd út.

Gerðu það endingargott yfir endurtengingu

Handvirkur mælikvarði á milli sem er búið til aftur við hverja tengingu er stilling sem hverfur. Ef biðlarinn byggir tengið upp aftur þarf yfirskriftin skrift eftir tengingu, stefnu eða biðlarastillingu sem á DNS meðan tengingin stendur.

Þjónar sem eru stilltir kyrrt á líkamlega millinum hafa sama endinguarvandamálið öfugt. Þeir halda áfram að svara fyrir það tengi þar til þeir eru fjarlægðir, og DHCP fyllir þá aftur úr næsta leigu, svo að fjarlægja þá er mæling en ekki hönnun. Endingargóða hönnunin er stefnu um nafnaupplausn fyrir innra nafnrýmið, eða biðlari sem tekur yfir DNS meðan tengingin varir. Hvað sem er, skráðu leysalistann fyrir og eftir endurtengingu, settu upprunalega mælikvarðann aftur þegar þú hefur lokið prófun og staðfestu að fyrri hegðun hafi snúið til baka.