Hvorfor et servernavn slår opp på VPN-adressen etter innringing

En kontorfileserver svarer på LAN-adressen sin hele formiddagen, så logger en fjernbruker på via innringing, og navnet begynner å slå opp på en tunneladresse i stedet. Ingenting ble redigert i DNS for hånd, og det er ledetråden: posten ble publisert av maskinen selv. Tre betingelser avgjør om du retter registraren, posten eller klientens bilde, og feil rekkefølge betyr at posten kommer tilbake etter neste tilkobling.

To adresser, ett navn, tre betingelser

En Windows-server med flere grensesnitt kan ha en LAN-adresse, én eller flere innringingsadresser og noen ganger et ekstra nettverkskort. Hvert grensesnitt kan registrere sine egne adresser i DNS hvis dynamisk registrering er tillatt for det. Når PPP-adapteren registrerer seg, får samme vertsnavn en adresse som bare tunnelens motpart kan nå, og LAN-klienter mottar den som et gyldig svar.

Tre betingelser avgjør reparasjonen. For det første, kan tilleggsadressen nås fra klientene som mottar den? For det andre, er det fortsatt noen forbruker som er avhengig av den registreringen? For det tredje, er posten dynamisk og dermed i stand til å komme tilbake, eller statisk og dermed en bevisst oppføring?

Svar på det før du rører noe. Hvis adressen ikke kan nås fra nettverket som spør, hjelper det ikke lenge å tømme klientbufferen. Hvis noe er avhengig av den, for eksempel en administrasjonsvei som tunnelens motparter selv bruker, ødelegger fjerningen i stedet den veien. Og en dynamisk post som slettes uten at utgiveren håndteres, dukker opp igjen ved neste registreringshendelse.

Les posten før du endrer registraren

Spør på det nøyaktige fullt kvalifiserte navnet fra nettverket som rapporterer problemet, og sammenlign svarene med serverens faktiske grensesnitt og lyttere. At ett navn returnerer flere adresser er normalt; spørsmålet er om hver av dem er brukbar for klienten som mottar 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 spørringen bruker den lokale resolvertjenesten, den andre spør en bestemt DNS-server direkte, og den tredje gjør det samme fra PowerShell på Windows. Å sammenligne dem skiller en foreldet klientbuffer fra et autoritativt svar. Hvis den direkte spørringen allerede returnerer tunneladressen, er problemet publiserte data og ikke lokal bufreing.

Skriv ned tidsstemplet til posten og om DNS-konsollen viser den som dynamisk. Den ene egenskapen forteller deg hvilken av de tre betingelsene ovenfor som gjelder, og det er forskjellen mellom en opprydding på fem minutter og en reparasjon som holder.

Rett utgiveren eller posten, men vit hvilken

Hvis posten er dynamisk og uønsket, er den varige løsningen å hindre det grensesnittet i å registrere seg. Windows tilbyr registreringsinnstillinger per grensesnitt, og DNS-klienttjenesten publiserer på nytt ved neste tilkobling eller adresseendring. Å slå av registrering for innringingsadapteren lar LAN-adapterens registrering være intakt, som vanligvis er det du ønsker.

Vær forsiktig med brytere som gjelder hele maskinen. En global innstilling som deaktiverer dynamisk oppdatering påvirker hvert grensesnitt på den verten, inkludert det hvis registrering andre klienter er avhengige av. På en domenekontroller gjelder samme forsiktighet med større kraft, fordi verten også kan eie tjenestestedsregistreringer som klienter er avhengige av for pålogging.

Hvis posten er statisk, ble den plassert der med vilje, og samtalen er med den som plasserte den. Å slette en statisk post fordi den er upraktisk i dag fjerner det eneste beviset på hvorfor den finnes. I begge tilfeller skal du slette det foreldede svaret først etter at utgiveren er håndtert, og notere hva du endret slik at neste person kan skille en bevisst oppføring fra en ulykke.

Verifiser fra klientnettverket som feilet

Verifiseringen hører til nettverket som rapporterte symptomet, ikke på serveren. Tøm klientens resolverbuffer via den støttede mekanismen, og gjenta deretter det opprinnelige oppslaget og den opprinnelige tjenestetilkoblingen ved navn.

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

Den første kommandoen tømmer Windows-resolverbufferen, og den andre viser om navnet er bufret igjen og hvilken adresse som ble lagret. En vellykket tilkobling fra serveren til seg selv beviser ingenting om en LAN-klient, og fjerning av en rute til den uønskede adressen retter ikke det DNS publiserer.

Til slutt, gjenta hendelsen som pleide å introdusere adressen: koble VPN-klienten til på nytt, eller forny innringingsøkten. Kontroller det publiserte navnet igjen etter den livssyklusendringen. En reparasjon som bare holder til neste tilkobling, var en opprydding og ikke en reparasjon, og å vite hvilken av de to du utførte er forskjellen mellom å lukke saken og åpne den igjen neste uke.