Scurgere de DNS prin VPN pe Windows: de ce metrica învinge ruta
Windows alege resolverul după metrica interfeței, nu doar după rută. Un adaptor de tunel clasat sub Wi-Fi poate scurge interogări în timp ce fiecare pachet trece tot prin tunel.
O interogare părăsește mașina și ajunge la routerul de acasă în timp ce fiecare pachet este tunelat. Concluzia firească este o rută lipsă, iar ruta este de obicei în regulă. Windows poate alege după metrica interfeței pe care resolver să întrebe, iar un adaptor de tunel pierde des această comparație în fața celui wireless.
Două explicații pentru o scurgere
Explicația prin rute spune că o parte din trafic scapă din tunel, deci ruta implicită sau lista de tunel divizat trebuie să fie greșite. Acea explicație se verifică cu o singură comandă, iar când ruta implicită arată în tunel, problema e închisă. Verificați-o prima pentru că este ieftină, apoi lăsați-o deoparte când se întoarce curată.
Explicația prin ierarhie spune că traficul este în întregime în tunel, iar interogarea este totuși trimisă la alt resolver. Windows tratează alegerea resolverului ca o proprietate pe interfață, cu o ordine, așa că un adaptor fizic cu metrică mai bună poate furniza DNS pentru un nume chiar dacă pachetele către adresa rezolvată merg prin tunel. Ambele explicații produc același simptom pe o pagină de testare a scurgerilor, de aceea testul nu este diagnosticul. Doar una dintre ele se repară editând rute.
Comparați metricile și resolverii împreună
Notați interfețele, metricile lor și serverele configurate cât timp tunelul este activ. Citiți-le ca pe un tabel, nu ca pe două liste separate, fiindcă întrebarea este care resolver vine primul, nu care resolvere există.
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses
Dacă adaptorul de tunel are un număr mai mare decât adaptorul fizic, resolverul lui nu este preferat, iar un nume intern va merge la ce oferă partea fizică. Routerul respectiv poate răspunde din cache, poate trimite mai departe interogarea sau o poate refuza, și niciunul dintre aceste rezultate nu este proiectul la care v-ați gândit. Ierarhia este o preferință, așa că pierde în tăcere în loc să ridice o eroare.
Un adaptor de tunel fără niciun resolver configurat este o variantă la fel de obișnuită. Clientul ridică interfața fără să împingă DNS, așa că întrebarea despre ierarhie nici nu apare.
Urcați tunelul în ierarhie și verificați din nou
Dați interfeței tunelului cea mai mică metrică, sau creșteți valoarea adaptorului fizic, într-un shell cu privilegii. Ambele sunt setări pe interfață și ambele sunt reversibile, ceea ce contează când modificați o mașină în fața căreia poate nu stați.
Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric
Schimbarea se vede imediat, iar clientul DNS și alți consumatori memorează alegerea deja făcută. Reconectați tunelul, sau reporniți, înainte de a trage vreo concluzie dintr-un rezultat de interogare. Un test rulat prea devreme va reproduce comportamentul vechi și va părea o remediere eșuată.
Apoi întrebați un nume intern și unul public și verificați ce server a răspuns. referința despre metricile automate de la Microsoft explică de ce este preferată cea mai mică valoare și cum se derivă alocarea automată.
Faceți-l să reziste la o reconectare
O metrică manuală pe un adaptor recreat la fiecare conexiune este o setare care dispare. Dacă clientul reconstruiește interfața, suprascrierea are nevoie de un script după conectare, de o politică sau de o configurație de client care deține DNS cât durează conexiunea.
Servere configurate static pe adaptorul fizic au aceeași problemă de durabilitate invers. Continuă să răspundă pentru acea interfață până sunt eliminate, iar DHCP le va completa din nou la următoarea închiriere, așa că eliminarea lor este o măsurare, nu un proiect. Proiectul durabil este o politică de rezolvare a numelor pentru spațiul de nume intern, sau un client care preia DNS pe durata conexiunii. În orice caz, notați lista de resolvere înainte și după o reconectare, restaurați metrica inițială când terminați testarea și confirmați că comportamentul anterior a revenit.