Zakaj se ime strežnika po dial-inu razreši v njegov naslov VPN

Pisarniški strežnik datotek celo jutro odgovarja na svojem naslovu LAN, nato se oddaljeni uporabnik poveže prek dial-ina in ime se začne razreševati v naslov tunela. V DNS ni bilo ročno urejeno nič, in to je namig: zapis je objavil sam stroj. Trije pogoji odločijo, ali popravite registrarja, zapis ali pogled odjemalca, in napačen vrstni red pomeni, da se zapis po naslednji povezavi vrne.

Dva naslova, eno ime, trije pogoji

Strežnik Windows z več vmesniki ima lahko naslov LAN, enega ali več naslovov dial-in in včasih drugo omrežno kartico. Vsak vmesnik lahko registrira svoje naslove v DNS, če je zanj dovoljena dinamična registracija. Ko se adapter PPP registrira, isto ime gostitelja dobi naslov, ki ga lahko doseže le partner tunela, in odjemalci LAN ga prejmejo kot veljaven odgovor.

Trije pogoji odločijo o popravilu. Prvič, ali je dodatni naslov dosegljiv odjemalcem, ki ga prejmejo? Drugič, ali je še kak potrošnik odvisen od te registracije? Tretjič, ali je zapis dinamičen in se zato lahko vrne, ali statičen in zato nameren vnos?

Na to odgovorite, preden se česa dotaknete. Če naslov ni dosegljiv iz omrežja, ki poizveduje, nobeno čiščenje predpomnilnika odjemalca tega ne popravi za dolgo. Če je kaj odvisno od njega, na primer pot upravljanja, ki jo uporabljajo sami partnerji tunela, odstranitev namesto tega pokvari to pot. In dinamičen zapis, izbrisan brez urejanja njegovega izdajatelja, se bo ob naslednjem dogodku registracije znova pojavil.

Preberite zapis, preden spremenite registrarja

Poizvedite po točnem polno kvalificiranem imenu iz omrežja, ki poroča o težavi, in primerjajte odgovore z dejanskimi vmesniki in poslušalci strežnika. Eno ime, ki vrne več naslovov, je običajno; vprašanje je, ali je vsak od njih uporaben za odjemalca, ki ga prejme.

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

Prva poizvedba uporabi krajevni razreševalnik, druga neposredno vpraša določen strežnik DNS, tretja pa stori isto iz PowerShella v Windows. Njihova primerjava loči zastarel predpomnilnik odjemalca od verodostojnega odgovora. Če neposredna poizvedba že vrne naslov tunela, je težava v objavljenih podatkih, ne v krajevnem predpomnjenju.

Zapišite časovni žig zapisa in ali ga konzola DNS prikazuje kot dinamičnega. Ta edini atribut vam pove, kateri od treh pogojev zgoraj velja, in to je razlika med petminutnim čiščenjem in popravilom, ki zdrži.

Popravite izdajatelja ali zapis, a vedite katerega

Če je zapis dinamičen in neželen, je trajna rešitev preprečiti temu vmesniku registracijo. Windows ponuja nastavitve registracije za vsak vmesnik, odjemalska storitev DNS pa znova objavi ob naslednji povezavi ali spremembi naslova. Izklop registracije za adapter dial-in pusti registracijo adapterja LAN nedotaknjeno, kar je običajno tisto, kar želite.

Bodite previdni s stikali, ki veljajo za celoten stroj. Globalna nastavitev, ki onemogoči dinamično posodabljanje, vpliva na vsak vmesnik na tem gostitelju, tudi na tistega, na katerega registracijo se zanašajo drugi odjemalci. Na krmilniku domene velja enaka previdnost z večjo močjo, ker ima lahko gostitelj tudi zapise lokacije storitev, od katerih so odjemalci odvisni pri prijavi.

Če je zapis statičen, je bil tja postavljen namerno in pogovor je s tistim, ki ga je postavil. Brisanje statičnega zapisa, ker je danes nepriročen, odstrani edini dokaz, zakaj obstaja. V obeh primerih izbrišite zastarel odgovor šele potem, ko je izdajatelj urejen, in zapišite, kaj ste spremenili, da bo naslednja oseba lahko ločila nameren vnos od nesreče.

Preverite iz odjemalskega omrežja, ki je odpovedalo

Preverjanje spada v omrežje, ki je poročalo o simptomu, ne na strežnik. Počistite predpomnilnik razreševalnika odjemalca po njegovem podprtem mehanizmu in nato ponovite prvotno iskanje in prvotno povezavo s storitvijo po imenu.

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

Prvi ukaz počisti predpomnilnik razreševalnika Windows, drugi pa pokaže, ali je ime znova v predpomnilniku in kateri naslov je bil shranjen. Uspešna povezava strežnika s samim seboj ne dokaže ničesar o odjemalcu LAN, odstranitev usmeritve do neželenega naslova pa ne popravi tega, kar objavlja DNS.

Nazadnje ponovite dogodek, ki je prej vnašal naslov: znova povežite odjemalca VPN ali obnovite sejo dial-in. Znova preverite objavljeno ime po tej spremembi življenjskega cikla. Popravilo, ki zdrži le do naslednje povezave, je bilo čiščenje in ne popravilo, in vedeti, katero od obeh ste izvedli, je razlika med zaprtjem zahtevka in njegovim ponovnim odprtjem naslednji teden.