Kvifor eit servernamn slår opp på VPN-adressa etter innringing

Ein kontorfilserver svarar på LAN-adressa si heile formiddagen, så loggar ein fjernbrukar på via innringing, og namnet byrjar å slå opp på ei tunneladresse i staden. Ingenting vart redigert i DNS for hand, og det er leiartråden: posten vart publisert av maskinen sjølv. Tre vilkår avgjer om du rettar registraren, posten eller biletet til klienten, og feil rekkjefølgje betyr at posten kjem tilbake etter neste tilkopling.

To adresser, eitt namn, tre vilkår

Ein Windows-server med fleire grensesnitt kan ha ei LAN-adresse, éi eller fleire innringingsadresser og stundom eit ekstra nettverkskort. Kvart grensesnitt kan registrere sine eigne adresser i DNS dersom dynamisk registrering er tillaten for det. Når PPP-adapteren registrerer seg, får same vertsnamn ei adresse som berre motparten i tunnelen kan nå, og LAN-klientar mottek henne som eit gyldig svar.

Tre vilkår avgjer reparasjonen. For det første, kan tilleggsadressa nærmast frå klientane som mottek henne? For det andre, er det framleis nokon forbrukar som er avhengig av den registreringa? For det tredje, er posten dynamisk og dermed i stand til å kome tilbake, eller statisk og dermed ein medviten oppføring?

Svar på det før du rører noko. Dersom adressa ikkje kan nærmast frå nettverket som spør, hjelper det ikkje lenge å tøme klientbufferen. Dersom noko er avhengig av henne, til dømes ein administrasjonsveg som tunnelmotpartane sjølve brukar, øydelegg fjerninga i staden den vegen. Og ein dynamisk post som blir sletta utan at utgjevaren blir handsama, dukkar opp att ved neste registreringshending.

Les posten før du endrar registraren

Spør på det nøyaktige fullt kvalifiserte namnet frå nettverket som rapporterer problemet, og samanlikn svara med dei faktiske grensesnitta og lyttarane til serveren. At eitt namn returnerer fleire adresser er normalt; spørsmålet er om kvar av dei er brukbar for klienten som mottek henne.

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ørjinga brukar den lokale resolvaren, den andre spør ein bestemd DNS-server direkte, og den tredje gjer det same frå PowerShell på Windows. Å samanlikne dei skil ein forelda klientbuffer frå eit autoritativt svar. Dersom den direkte spørjinga allereie returnerer tunneladressa, er problemet publiserte data og ikkje lokal bufreing.

Skriv ned tidsstempelet til posten og om DNS-konsollen viser han som dynamisk. Den eine eigenskapen fortel deg kva av dei tre vilkåra ovanfor som gjeld, og det er skilnaden mellom ein opprydding på fem minutt og ein reparasjon som held.

Rett utgjevaren eller posten, men vit kva ein

Dersom posten er dynamisk og uønskt, er den varige løysinga å hindre det grensesnittet i å registrere seg. Windows tilbyr registreringsinnstillingar per grensesnitt, og DNS-klienttenesta publiserer på nytt ved neste tilkopling eller adresseendring. Å slå av registrering for innringingsadapteren lèt registreringa til LAN-adapteren vere intakt, som vanlegvis er det du ønskjer.

Ver varsam med brytarar som gjeld heile maskinen. Ei global innstilling som slår av dynamisk oppdatering påverkar kvart grensesnitt på den verten, òg det kva registreringa andre klientar er avhengige av. På ein domenekontroller gjeld same varsemd med større kraft, fordi verten òg kan eige tenestestadregistreringar som klientar er avhengige av for pålogging.

Dersom posten er statisk, vart han plassert der med vilje, og samtalen er med den som plasserte han. Å slette ein statisk post fordi han er upraktisk i dag fjernar det einaste beviset på kvifor han finst. I begge tilfelle skal du slette det forelda svaret først etter at utgjevaren er handsama, og notere kva du endra slik at neste person kan skilje ein medviten oppføring frå ei ulukke.

Stadfest frå klientnettverket som feila

Stadfestinga høyrer til nettverket som rapporterte symptomet, ikkje på serveren. Tøm klientresolvarbufferen via den støtta mekanismen, og gjer deretter om att det opphavlege oppslaget og den opphavlege tenestetilkoplinga ved namn.

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

Den første kommandoen tømmer Windows-resolvarbufferen, og den andre viser om namnet er bufra igjen og kva adresse som vart lagra. Ein vellukka tilkopling frå serveren til seg sjølv beviser ingenting om ein LAN-klient, og fjerning av ei rute til den uønskt adressa rettar ikkje det DNS publiserer.

Til slutt, gjer om hendinga som brukte å innføre adressa: kopla VPN-klienten til på nytt, eller forny innringingsøkta. Kontroller det publiserte namnet igjen etter den livssyklusendringa. Ein reparasjon som berre held til neste tilkopling, var ein opprydding og ikkje ein reparasjon, og å vite kva av dei to du utførte er skilnaden mellom å lukke saka og opne henne att neste veke.