Hvorfor et servernavn slår op på sin VPN-adresse efter dial-in

En kontorfileserver svarer på sin LAN-adresse hele formiddagen, så logger en fjernbruger ind via dial-in, og navnet begynder at slå op på en tunneladresse i stedet. Der er ikke redigeret noget i DNS manuelt, og det er ledetråden: posten blev udgivet af maskinen selv. Tre betingelser afgør, om du retter registraren, posten eller klientens billede, og forkert rækkefølge betyder, at posten vender tilbage efter den næste forbindelse.

To adresser, ét navn, tre betingelser

En Windows-server med flere netværkskort kan have en LAN-adresse, en eller flere dial-in-adresser og nogle gange et ekstra netværkskort. Hver grænseflade kan registrere sine egne adresser i DNS, hvis dynamisk registrering er tilladt for den. Når PPP-adapteren registrerer sig, får det samme værtsnavn en adresse, som kun tunnelens modpart kan nå, og LAN-klienter modtager den som et gyldigt svar.

Tre betingelser afgør reparationen. For det første, kan den ekstra adresse nås fra de klienter, der modtager den? For det andet, afhænger nogen forbruger stadig af den registrering? For det tredje, er posten dynamisk og dermed i stand til at vende tilbage, eller statisk og dermed en bevidst post?

Svar på det, før du rører noget. Hvis adressen ikke kan nås fra det netværk, der spørger, hjælper det ikke længe at rydde klientcachen. Hvis noget afhænger af den, for eksempel en administrationsvej, som tunnelens modparter selv bruger, ødelægger fjernelsen i stedet den vej. Og en dynamisk post, der slettes uden at håndtere dens udgiver, dukker op igen ved den næste registreringshændelse.

Læs posten, før du ændrer registraren

Forespørg på det præcise fuldt kvalificerede navn fra det netværk, der rapporterer problemet, og sammenlign svarene med serverens faktiske grænseflader og lyttere. At ét navn returnerer flere adresser er normalt; spørgsmålet er, om hver af dem kan bruges af den klient, der modtager den.

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

Den første forespørgsel bruger den lokale resolver, den anden spørger en bestemt DNS-server direkte, og den tredje gør det samme fra PowerShell på Windows. At sammenligne dem adskiller en forældet klientcache fra et autoritativt svar. Hvis den direkte forespørgsel allerede returnerer tunneladressen, er problemet udgivne data og ikke lokal caching.

Skriv postens tidsstempel ned, og om DNS-konsollen viser den som dynamisk. Den ene egenskab fortæller dig, hvilken af de tre betingelser ovenfor der gælder, og det er forskellen mellem en oprydning på fem minutter og en reparation, der holder.

Ret udgiveren, eller ret posten, men vid hvilken

Hvis posten er dynamisk og uønsket, er den holdbare løsning at forhindre den grænseflade i at registrere sig. Windows udstiller registreringsindstillinger pr. grænseflade, og DNS-klienttjenesten udgiver igen ved den næste forbindelse eller adresseændring. Slår du registrering fra for dial-in-adapteren, forbliver LAN-adapterens registrering intakt, hvilket normalt er det, du ønsker.

Vær forsigtig med kontakter, der gælder hele maskinen. En global indstilling, der deaktiverer dynamisk opdatering, påvirker hver grænseflade på den vært, inklusive den, hvis registrering andre klienter er afhængige af. På en domænecontroller gælder samme forsigtighed med større kraft, fordi værten også kan eje placeringstjenesteposter, som klienter afhænger af til logon.

Hvis posten er statisk, blev den placeret der med vilje, og samtalen er med den, der placerede den. At slette en statisk post, fordi den er ubelejlig i dag, fjerner det eneste bevis på, hvorfor den findes. I begge tilfælde skal du først slette det forældede svar, når udgiveren er håndteret, og notere, hvad du ændrede, så den næste person kan skelne en bevidst post fra et uheld.

Verificer fra det klientnetværk, der fejlede

Verifikation hører til på det netværk, der rapporterede symptomet, ikke på serveren. Ryd klientens resolvercache via dens understøttede mekanisme, og gentag derefter det oprindelige opslag og den oprindelige tjenesteforbindelse ved navn.

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

Den første kommando rydder Windows-resolvercachen, og den anden viser, om navnet er cachet igen, og hvilken adresse der blev gemt. En vellykket forbindelse fra serveren til sig selv beviser intet om en LAN-klient, og fjernelse af en rute til den uønskede adresse retter ikke det, DNS udgiver.

Gentag til sidst den hændelse, der plejede at indføre adressen: tilslut VPN-klienten igen, eller forny dial-in-sessionen. Kontroller det udgivne navn igen efter den livscyklusændring. En reparation, der kun holder til den næste forbindelse, var en oprydning, ikke en reparation, og at vide, hvilken du udførte, er forskellen mellem at lukke sagen og genåbne den i næste uge.