Windows VPN DNS-szivárgás: miért nyer a metrika az útvonallal szemben

Egy lekérdezés elhagyja a gépet és eléri az otthoni útválasztót, miközben minden csomag az alagúton halad. A kézenfekvő következtetés egy hiányzó útvonal, és az útvonal rendszerint rendben van. A Windows az interfész metrikája alapján választhatja ki, melyik interfész feloldóját kérdezze, és az alagútadapter gyakran elveszíti ezt az összehasonlítást a vezeték nélkülivel szemben.

Két magyarázat egy szivárgásra

Az útvonal-magyarázat szerint a forgalom egy része kiszökik az alagútból, tehát az alapértelmezett útvonalnak vagy a felosztott alagút listájának hibásnak kell lennie. Ez a magyarázat egyetlen paranccsal tesztelhető, és amikor az alapértelmezett útvonal az alagútba mutat, a kérdés lezárult. Először ezt ellenőrizze, mert olcsó, majd tegye félre, amikor tisztán tér vissza.

A rangsor-magyarázat szerint a forgalom teljes egészében az alagútban van, és a lekérdezés mégis egy másik feloldóhoz megy. A Windows a feloldó kiválasztását sorrenddel rendelkező, interfészenkénti tulajdonságként kezeli, ezért egy jobb metrikájú fizikai adapter szolgálhat DNS-t egy névhez, miközben a feloldott címhez tartozó csomagok az alagúton mennek. Mindkét magyarázat ugyanazt a tünetet okozza egy szivárgásteszt-oldalon, ezért a teszt nem a diagnózis. Csak az egyiket javítja az útvonalak szerkesztése.

Hasonlítsa össze a metrikákat és a feloldókat együtt

Jegyezze fel az interfészeket, a metrikáikat és a beállított kiszolgálóikat, amíg az alagút aktív. Táblázatként olvassa őket, ne két külön listaként, mert a kérdés az, melyik feloldó következik előbb, nem az, milyen feloldók léteznek.

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

Ha az alagútadapter magasabb számot visel, mint a fizikai adapter, a feloldója nem élvez elsőbbséget, és egy belső név ahhoz megy, amit a fizikai oldal kínál. Az az útválasztó válaszolhat a gyorsítótárból, továbbíthatja a lekérdezést vagy elutasíthatja, és e kimenetelek egyike sem az a terv, amelyet szándékolt. A rangsor preferencia, ezért csendben veszít, ahelyett hogy hibát jelezne.

Az az alagútadapter, amelyen egyáltalán nincs beállított feloldó, ugyanilyen gyakori változat. Az ügyfél DNS továbbítása nélkül hozza fel az interfészt, így a rangsor kérdése fel sem merül.

Sorolja előre az alagutat, és ellenőrizze újra

Adja az alagút-interfésznek a legalacsonyabb metrikájú értéket, vagy emelje meg a fizikai adapter értékét egy emelt szintű parancsértelmezőben. Mindkettő interfészenkénti beállítás, és mindkettő visszafordítható, ami számít, amikor olyan gépet módosít, amely előtt talán nem ül.

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

A változás azonnal látható, a DNS-ügyfél és más fogyasztók pedig gyorsítótárazzák a már meghozott döntést. Csatlakoztassa újra az alagutat, vagy indítsa újra, mielőtt bármit is beolvasna egy lekérdezés eredményébe. Egy túl korán futtatott teszt megismétli a régi viselkedést, és sikertelen javításnak tűnik.

Ezután kérdezzen le egy belső és egy nyilvános nevet, és ellenőrizze, melyik kiszolgáló válaszolt. A Microsoft hivatkozása az automatikus metrikákról elmagyarázza, miért élvez elsőbbséget a legalacsonyabb érték, és hogyan vezethető le az automatikus hozzárendelés.

Tegye túlélőképessé az újracsatlakozáson

A kézi metrika egy minden kapcsolatnál újra létrehozott adapteren olyan beállítás, amely eltűnik. Ha az ügyfél újraépíti az interfészt, a felülbíráláshoz kapcsolat utáni szkriptre, szabályzatra vagy olyan ügyfélkonfigurációra van szükség, amely a kapcsolat ideje alatt birtokolja a DNS-t.

A fizikai adapteren statikusan beállított kiszolgálóknál ugyanez a tartóssági probléma fordítva jelentkezik. Addig válaszolnak azon interfész nevében, amíg el nem távolítják őket, és a DHCP a következő bérletből újra feltölti őket, ezért az eltávolításuk mérés, nem tervezés. A tartós megoldás névfeloldási szabályzat a belső névtérhez, vagy egy ügyfél, amely a kapcsolat idejére átveszi a DNS-t. Akárhogy is, jegyezze fel a feloldók listáját újracsatlakozás előtt és után, állítsa vissza az eredeti metrikát, amikor végzett a teszteléssel, és erősítse meg, hogy visszatért a korábbi viselkedés.