Hibás DNS-kiszolgáló Windows VPN-ben: metrika, kötési sorrend vagy utótag

Egy Windows-ügyfélnek lehet működő alagútja, viheti a vállalati feloldót, és mégis a otthoni routerhez küldheti a belső neveket. Három különböző mechanizmus dönti el, melyik kiszolgáló válaszol, és ezek különböző módon hibáznak. Nem kell mindhármat megjavítani: a tünet megmondja, melyik van játékban. Az alábbi döntési fa néhány percet vesz igénybe, és megakadályozza a szokásos kimenetet, amikor egy metrikamódosítás, a beállításjegyzék átrendezése és egy NRPT-szabály egyszerre érkezik, és senki nem tudja, melyik tett bármit.

Három mechanizmus dönt, és általában az egyik hibás

Az interfész metrika adott címcsaládhoz rendezi az adaptereket. A kötési sorrend a Tcpip\Linkage alatt gépszintű interfész-azonosítók listája, amelyet a régebbi kódutak még mindig megkérdeznek. A névfeloldási házirend-tábla (NRPT) egy névteret adott kiszolgálókhoz köt, az utótaglista pedig eldönti, hogy egy rövid név egyáltalán kiterjesztődik-e. Ezek függetlenek, ezért a VPN-adapter helyes feloldója alulmarad egy máshol lévő elavult preferenciával szemben.

Egyik mechanizmus sem az alagút túloldala. Ha a kiszolgáló, amelyet a VPN betol, nem tudja feloldani a nevet, minden ügyféloldali beállítás csak díszítés, ezért az első döntés az, hogy maga a feloldó tud-e válaszolni, ha közvetlenül kérdezik.

Első döntés: tud-e egyáltalán válaszolni a betolt feloldó?

Kérdezze meg a kiszolgálót kifejezetten, és hasonlítsa össze egy közönséges lekérdezéssel. A válaszok közötti különbség elválasztja a kiválasztási problémát az elérhetőségi problémától, és itt ez a leggyorsabb elágazás:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Ha az első sikerül és a második nem, a feloldó elérhető, és a Windows rosszul választ; menjen az alábbi névtér- és sorrend-döntésekhez. Ha az első is meghiúsul, semmi sem segít az ügyfélen: ellenőrizze, hogy az UDP és a TCP 53 eléri-e a kiszolgálót az alagúton át, hogy a kiszolgálón lévő gazdagép-tűzfal nem dobja-e el a készletet, és hogy a kiszolgáló saját továbbítói egészségesek-e.

Álljon meg ennél az elágazásnál. Egy NRPT-szabály alkalmazása egy elérhetetlen feloldóra ugyanazt a hibát adja több visszavonható konfigurációval, és elrejti a valódi hibát egy tekintélyesnek látszó szabály mögé.

Második döntés: egy névtér, vagy minden lekérdezés?

A hatókör dönti el az eszközt. Ha csak a vállalati nevek hibáznak, kösse a névteret a gép átrendezése helyett: egy NRPT-szabály elküldi ezt az utótagot az alagút feloldójához, és minden mást békén hagy. Ha minden lekérdezés érintett, a probléma a globális adapterpreferencia, és a metrika a kezdőpont, mert nem változtat semmilyen kiszolgálóbeállítást.

Címcsaládonként állítsa be a metrikát, mindkét interfészen, majd ellenőrizze a sorrendet:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Cserélje a 11-et az alagútadapter ifIndexére a fenti sorból; ha a 11 a LAN-adapter, ugyanaz a parancs a rossz útvonalat csökkenti. A LAN-adapter emelése helyette ugyanahhoz a sorrendhez vezet a másik oldalról: netsh int ip set interface interface="Ethernet" metric=15, és a második címcsaládhoz netsh int ipv6 set interface interface="Ethernet" metric=15, mert a int ip csak az IPv4-et érinti.

A kötési sorrend az utolsó eszköz, nem az első lépés. A HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage tartalmazza az eszközazonosítók Bind listáját, és az alagút azonosítójának előre mozgatása valóban megváltoztatja, melyik adaptert kérdezik először, de ez gépszintű beállításjegyzék-érték névtérenkénti hatókör nélkül. Exportálja szerkesztés előtt, majd csatlakoztassa újra az alagutat, hogy a sorrend abban az állapotban érvényesüljön, amelyet az ügyfél elvár.

Egyetlen névtérhez a szűkebb eszközt válassza:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Harmadik döntés: túléli-e a javítás az újracsatlakozást?

Egy metrika, amely a következő telefonvonalas újracsatlakozásig működik, soha nem lett elmentve. Az L2TP/IPsec és más kapcsolatprofilok a kapcsolat indításakor újra létrejönnek, ezért a mentett érték a telefonkönyv-bejegyzésben él IpInterfaceMetric néven, nem csak az élő interfészen. Egyes környezetek éppen ezért szkriptelik ezt a mezőt; mások felügyeleti házirendből tolják a preferenciát, és békén hagyják a végpontot.

A gyorsítótár és a regisztráció külön réteg. Ezek futtatása az alagút felállása után javítja az elavult bejegyzéseket és újraregisztrálja az ügyfelet, de egyik sem rendez át adaptert:

ipconfig /registerdns
ipconfig /flushdns

Ugyanabban a rétegben van egy kapcsoló. A dinamikus regisztráció letiltása a fizikai adapteren megakadályozza, hogy az ügyfél a VPN oldali címét rossz néven hirdesse, ami más javítás, mint a fenti frissítés.

Az IPv6 saját sort érdemel a döntésben. Ha a fizikai adapter globális IPv6-címmel rendelkezik, miközben az alagút csak IPv4-et visz, a Windows a névfeloldáshoz előnyben részesítheti az alagút nélküli útvonalat. Ellenőrizze ezt a címcsaládot külön, mert az IPv4-hez beállított metrika semmit sem mond róla:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Az IPv6 letiltása a LAN-adapteren eltávolítja azt az útvonalat és vele a protokollt; az IPv6-interfész metrikájának módosítása vagy egy NRPT-szabály a vállalati névtérhez megtartja a címcsaládot és kijavítja a preferenciát. A szűkebbet válassza, hacsak nem döntött úgy, hogy annak a kapcsolatnak nem kell IPv6-ot tartalmaznia.

A megnevezett forrással ellenőrizzen, és tartson egy tulajdonost

Olyan eszközökkel ellenőrizzen, amelyek jelentik, melyik forrás van érvényben, nem csak azt, hogy betöltődik-e egy lap:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Ezután válassza szét a szűrést a kiválasztástól, mert egy alkalmazás belsejéből azonosnak látszanak. Az OpenVPN block-outside-dns beállítása blokkolja az 53-as portot a többi adapteren; nem választ feloldót. Ha most minden lekérdezés meghiúsul, egy szűrő blokkolhatja az egyetlen elérhető kiszolgálót; ha a beállított feloldót figyelmen kívül hagyják, a sorrend vagy a névtérszabály hibás. Mindkettő egyszerre történő módosítása megkülönböztethetetlenné teszi a blokkolt és a figyelmen kívül hagyott lekérdezést.

Tartson egy tulajdonost a DNS-házirendhez: a VPN-profil, egy felügyeleti házirend vagy egy NRPT-szabály, ne kettő ezek közül. Mielőtt lezárja:

• A betolt feloldó válaszol, ha kifejezetten megnevezik, és egy közönséges lekérdezés használja.
• A módosított szabály vagy metrika lefedi azt a címcsaládot, amely ténylegesen viszi a lekérdezéseket.
• A beállítás túléli a bontást és az újracsatlakozást, vagy átvitte a mentett profilba.
• Pontosan egy mechanizmus mérvadó, a többi pedig úgy maradt, ahogy volt.

Kezelje a sorrendet környezeti állapotként, nem befejezhető dologként. Ellenőrizze újra újracsatlakozás után és olyan Windows-frissítés után, amely a hálózati vermet érinti, mert bármelyik visszahelyezheti a fizikai adaptert az élre.