Miks serveri nimi pärast sissehelistamist VPN-aadressile laheneb

Kontori failiserver vastab kogu hommiku oma LAN-aadressil, siis helistab kaugkasutaja sisse ja nimi hakkab hoopis tunneliaadressile lahenema. DNS-is ei muudetud midagi käsitsi ja see on vihje: kirje avaldas masin ise. Kolm tingimust otsustavad, kas parandate registraatori, kirje või kliendi vaate, ja vale järjekord tähendab, et kirje naaseb pärast järgmist ühendust.

Kaks aadressi, üks nimi, kolm tingimust

Mitme liidesega Windowsi serveril võib olla LAN-aadress, üks või mitu sissehelistamisaadressi ja mõnikord teine võrgukaart. Iga liides võib registreerida oma aadressid DNS-is, kui selle jaoks on dünaamiline registreerimine lubatud. Kui PPP-adapter registreerub, saab sama hostinimi aadressi, millele pääseb ligi ainult tunneli partner, ja LAN-kliendid saavad selle kehtiva vastusena.

Paranduse otsustavad kolm tingimust. Esiteks, kas lisaaadress on kättesaadav klientidele, kes selle saavad? Teiseks, kas mõni tarbija sõltub endiselt sellest registreerimisest? Kolmandaks, kas kirje on dünaamiline ja seega võib naasta, või staatiline ja seega tahtlik kirje?

Vastake sellele enne, kui midagi puudutate. Kui aadress ei ole päritavast võrgust kättesaadav, ei paranda kliendi vahemälu tühjendamine seda kauaks. Kui midagi sõltub sellest, näiteks haldustee, mida kasutavad tunnelipartnerid ise, siis selle eemaldamine katkestab hoopis selle tee. Ja dünaamiline kirje, mis kustutatakse selle avaldajat käsitlemata, ilmub uuesti järgmisel registreerimissündmusel.

Lugege kirjet enne registraatori muutmist

Pärige täpne täielikult kvalifitseeritud nimi võrgust, mis probleemist teada annab, ja võrrelge vastuseid serveri tegelike liideste ja kuulajatega. Üks nimi, mis tagastab mitu aadressi, on tavaline; küsimus on, kas igaüht neist saab vastuvõttev klient kasutada.

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

Esimene päring kasutab kohalikku lahendajat, teine küsib otse kindlalt DNS-serverilt ja kolmas teeb sama Windowsis PowerShellist. Nende võrdlemine eristab vananenud kliendi vahemälu autoriteetsest vastusest. Kui otsepäring tagastab juba tunneliaadressi, on probleem avaldatud andmetes, mitte kohalikus vahemällu salvestamises.

Kirjutage üles kirje ajatempel ja see, kas DNS-konsool näitab seda dünaamilisena. See üks atribuut ütleb, milline kolmest ülaltoodud tingimusest kehtib, ja see on vahe viie minuti puhastuse ning kestva paranduse vahel.

Parandage avaldajat või kirjet, aga teadke, kumba

Kui kirje on dünaamiline ja soovimatu, on püsiv parandus takistada sellel liidesel registreerumast. Windows pakub liidesepõhiseid registreerimissätteid ja DNS-i klienditeenus avaldab uuesti järgmisel ühendusel või aadressimuutusel. Sissehelistamisadapteri registreerimise väljalülitamine jätab LAN-adapteri registreerimise puutumata, mis on tavaliselt soovitu.

Olge ettevaatlik kogu masinat hõlmavate lülititega. Globaalne säte, mis keelab dünaamilise värskendamise, mõjutab iga liidest sellel hostil, sealhulgas seda, mille registreerimisele teised kliendid tuginevad. Domeenikontrolleril kehtib sama ettevaatus suurema jõuga, sest host võib omada ka teenuseasukoha kirjeid, millest kliendid sisselogimisel sõltuvad.

Kui kirje on staatiline, pandi see sinna tahtlikult ja vestlus käib sellega, kes selle pani. Staatilise kirje kustutamine, sest see on täna ebamugav, eemaldab ainsa tõendi selle kohta, miks see olemas on. Mõlemal juhul kustutage vananenud vastus alles pärast seda, kui avaldaja on käsitletud, ja kirjutage üles, mida muutsite, et järgmine inimene suudaks eristada tahtlikku kirjet õnnetusest.

Kontrollige ebaõnnestunud kliendivõrgust

Kontrollimine kuulub võrku, mis sümptomist teada andis, mitte serverisse. Tühjendage kliendi lahendaja vahemälu selle toetatud mehhanismi kaudu, seejärel korrake algset päringut ja algset teenuseühendust nime järgi.

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

Esimene käsk tühjendab Windowsi lahendaja vahemälu ja teine näitab, kas nimi on uuesti vahemällu salvestatud ja milline aadress salvestati. Serveri edukas ühendus iseendaga ei tõesta LAN-kliendi kohta midagi ja marsruudi eemaldamine soovimatu aadressi suunas ei paranda seda, mida DNS avaldab.

Lõpuks korrake sündmust, mis varem aadressi tõi: ühendage VPN-klient uuesti või uuendage sissehelistamissessiooni. Kontrollige avaldatud nime uuesti pärast seda elutsükli muutust. Parandus, mis püsib ainult järgmise ühenduseni, oli puhastus, mitte parandus, ja teadmine, kummaga tegelesite, on vahe pileti sulgemise ja selle järgmisel nädalal uuesti avamise vahel.