Miért oldódik fel egy kiszolgálónév a VPN-címére betárcsázás után

Egy irodai fájlkiszolgáló egész délelőtt a LAN-címén válaszol, majd egy távoli felhasználó betárcsáz, és a név elkezd inkább alagútcímre feloldódni. A DNS-ben semmit nem szerkesztettek kézzel, és ez a nyom: a rekordot maga a gép tette közzé. Három feltétel dönti el, hogy a regisztrálót, a rekordot vagy az ügyfél nézetét javítja-e, és a rossz sorrend azt jelenti, hogy a rekord a következő kapcsolat után visszatér.

Két cím, egy név, három feltétel

Egy több interfészes Windows-kiszolgálónak lehet LAN-címe, egy vagy több betárcsázási címe és néha második hálózati kártyája. Minden interfész regisztrálhatja a saját címeit a DNS-ben, ha az dinamikus regisztráció engedélyezett számára. Amikor a PPP-adapter regisztrál, ugyanaz a gazdanév olyan címet kap, amelyet csak az alagút partnere érhet el, és a LAN-ügyfelek érvényes válaszként kapják meg.

Három feltétel dönti el a javítást. Először, elérhető-e a további cím azoktól az ügyfelektől, amelyek megkapják? Másodszor, függ-e még valamilyen fogyasztó ettől a regisztrációtól? Harmadszor, dinamikus-e a rekord, és ezért visszatérhet, vagy statikus, és ezért szándékos bejegyzés?

Válaszoljon erre, mielőtt bármihez nyúlna. Ha a cím nem érhető el a kérdező hálózatból, az ügyfél-gyorsítótár tisztítása nem javítja hosszú távon. Ha valami függ tőle, például az alagút partnerei által használt felügyeleti útvonal, az eltávolítás inkább megtöri azt az útvonalat. És a közzétevő kezelése nélkül törölt dinamikus rekord a következő regisztrációs eseménynél újra megjelenik.

Olvassa el a rekordot, mielőtt módosítja a regisztrálót

Kérdezze le a pontos teljesen minősített nevet a problémát jelentő hálózatból, és hasonlítsa össze a válaszokat a kiszolgáló tényleges interfészeivel és figyelőivel. Az, hogy egy név több címet ad vissza, normális; a kérdés az, hogy mindegyik használható-e a fogadó ügyfél számára.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

Az első lekérdezés a helyi feloldót használja, a második közvetlenül egy adott DNS-kiszolgálót kérdez, a harmadik pedig ugyanezt teszi PowerShellből Windowson. Összehasonlításuk elválasztja az elavult ügyfél-gyorsítótárat a mérvadó választól. Ha a közvetlen lekérdezés már az alagútcímet adja vissza, a probléma a közzétett adatokban van, nem a helyi gyorsítótárazásban.

Jegyezze fel a rekord időbélyegét és azt, hogy a DNS-konzol dinamikusként mutatja-e. Ez az egyetlen attribútum megmondja, hogy a fenti három feltétel közül melyik érvényes, és ez a különbség az ötperces tisztítás és a tartós javítás között.

Javítsa a közzétevőt vagy a rekordot, de tudja, melyiket

Ha a rekord dinamikus és nem kívánatos, a tartós javítás az, hogy megakadályozza azt az interfészt a regisztrációban. A Windows interfészenkénti regisztrációs beállításokat kínál, és a DNS-ügyfélszolgáltatás a következő kapcsolatnál vagy címváltozásnál újra közzétesz. A betárcsázási adapter regisztrációjának kikapcsolása érintetlenül hagyja a LAN-adapter regisztrációját, ami általában a kívánt eredmény.

Legyen óvatos a teljes gépre vonatkozó kapcsolókkal. A dinamikus frissítést letiltó globális beállítás a gazdagép minden interfészére hatással van, beleértve azt is, amelynek regisztrációjára más ügyfelek támaszkodnak. A tartományvezérlőn ugyanez az óvatosság nagyobb erővel érvényes, mert a gazdagép olyan szolgáltatáshely-rekordokkal is rendelkezhet, amelyektől az ügyfelek bejelentkezése függ.

Ha a rekord statikus, szándékosan helyezték oda, és a beszélgetés azzal folyik, aki odahelyezte. Egy statikus rekord törlése azért, mert ma kényelmetlen, eltávolítja létének egyetlen bizonyítékát. Mindkét esetben csak a közzétevő kezelése után törölje az elavult választ, és jegyezze fel, mit változtatott, hogy a következő személy meg tudja különböztetni a szándékos bejegyzést a balesettől.

Ellenőrizze a meghibásodott ügyfélhálózatból

Az ellenőrzés a tünetet jelentő hálózathoz tartozik, nem a kiszolgálóhoz. Tisztítsa meg az ügyfél feloldójának gyorsítótárát a támogatott mechanizmusával, majd ismételje meg az eredeti keresést és az eredeti szolgáltatáskapcsolatot név szerint.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

Az első parancs törli a Windows feloldójának gyorsítótárát, a második pedig megmutatja, hogy a név ismét gyorsítótárba került-e, és melyik címet tárolta. A kiszolgáló sikeres kapcsolata önmagával semmit nem bizonyít egy LAN-ügyfélről, és a nem kívánt címhez vezető útvonal eltávolítása nem javítja azt, amit a DNS közzétesz.

Végül ismételje meg az eseményt, amely korábban behozta a címet: csatlakoztassa újra a VPN-ügyfelet, vagy újítsa meg a betárcsázási munkamenetet. Ellenőrizze újra a közzétett nevet ezen életciklus-változás után. Az a javítás, amely csak a következő kapcsolatig tart, tisztítás volt, nem javítás, és tudni, melyiket végezte el, a különbség a jegy lezárása és a jövő heti újranyitása között.