Varför ett servernamn slår upp på sin VPN-adress efter inringning

En kontorsfilserver svarar på sin LAN-adress hela förmiddagen, sedan loggar en fjärranvändare in via inringning och namnet börjar slå upp på en tunneladress i stället. Ingenting redigerades i DNS för hand, och det är ledtråden: posten publicerades av maskinen själv. Tre villkor avgör om du rättar registraren, posten eller klientens bild, och fel ordning innebär att posten kommer tillbaka efter nästa anslutning.

Två adresser, ett namn, tre villkor

En Windows-server med flera gränssnitt kan ha en LAN-adress, en eller flera inringningsadresser och ibland ett extra nätverkskort. Varje gränssnitt kan registrera sina egna adresser i DNS om dynamisk registrering är tillåten för det. När PPP-adaptern registrerar sig får samma värdnamn en adress som bara tunnelns motpart kan nå, och LAN-klienter tar emot den som ett giltigt svar.

Tre villkor avgör reparationen. För det första, går det att nå tilläggsadressen från de klienter som får den? För det andra, är någon konsument fortfarande beroende av den registreringen? För det tredje, är posten dynamisk och därmed kan komma tillbaka, eller statisk och därmed en avsiktlig post?

Svara på det innan du rör något. Om adressen inte går att nå från nätverket som frågar, hjälper det inte länge att rensa klientcachen. Om något är beroende av den, till exempel en administrationsväg som tunnelns motparter själva använder, bryter borttagningen i stället den vägen. Och en dynamisk post som raderas utan att utgivaren hanteras dyker upp igen vid nästa registreringshändelse.

Läs posten innan du ändrar registraren

Fråga på det exakta fullt kvalificerade namnet från nätverket som rapporterar problemet, och jämför svaren med serverns faktiska gränssnitt och lyssnare. Att ett namn returnerar flera adresser är normalt; frågan är om var och en är användbar för klienten som tar emot 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örsta frågan använder den lokala resolvern, den andra frågar en specifik DNS-server direkt, och den tredje gör samma sak från PowerShell på Windows. Att jämföra dem skiljer en föråldrad klientcache från ett auktoritativt svar. Om den direkta frågan redan returnerar tunneladressen är problemet publicerade data och inte lokal cachning.

Skriv ned postens tidsstämpel och om DNS-konsolen visar den som dynamisk. Den enda egenskapen talar om vilket av de tre villkoren ovan som gäller, och det är skillnaden mellan en städning på fem minuter och en reparation som håller.

Rätta utgivaren eller posten, men vet vilken

Om posten är dynamisk och oönskad är den varaktiga lösningen att hindra det gränssnittet från att registrera sig. Windows erbjuder registreringsinställningar per gränssnitt, och DNS-klienttjänsten publicerar igen vid nästa anslutning eller adressändring. Att stänga av registreringen för inringningsadaptern lämnar LAN-adapterns registrering intakt, vilket vanligtvis är det du vill.

Var försiktig med strömbrytare som gäller hela maskinen. En global inställning som inaktiverar dynamisk uppdatering påverkar varje gränssnitt på den värden, inklusive det vars registrering andra klienter förlitar sig på. På en domänkontrollant gäller samma försiktighet med större kraft, eftersom värden också kan äga tjänstelokaliseringposter som klienter är beroende av för inloggning.

Om posten är statisk placerades den där med avsikt och samtalet är med den som placerade den. Att radera en statisk post för att den är obekväm i dag tar bort det enda beviset på varför den finns. I båda fallen ska du bara radera det föråldrade svaret efter att utgivaren har hanterats, och anteckna vad du ändrade så att nästa person kan skilja en avsiktlig post från en olycka.

Verifiera från klientnätverket som misslyckades

Verifieringen hör hemma i nätverket som rapporterade symptomet, inte på servern. Rensa klientens resolvercache via den stödda mekanismen och upprepa sedan den ursprungliga sökningen och den ursprungliga tjänsteanslutningen med namn.

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

Det första kommandot rensar Windows resolverbuffert, och det andra visar om namnet är cachelagrat igen och vilken adress som lagrades. En lyckad anslutning från servern till sig själv bevisar ingenting om en LAN-klient, och att ta bort en rutt till den oönskade adressen korrigerar inte det DNS publicerar.

Upprepa slutligen händelsen som tidigare introducerade adressen: anslut VPN-klienten igen eller förnya inringningssessionen. Kontrollera det publicerade namnet igen efter den livscykeländringen. En reparation som bara håller till nästa anslutning var en städning, inte en reparation, och att veta vilken av de två du utförde är skillnaden mellan att stänga ärendet och öppna det igen nästa vecka.