Tre udgivere kan sætte en domænecontrollers VPN-adresse i DNS

Tre forskellige komponenter på en domænecontroller med flere netværkskort kan sætte den samme VPN-adresse i DNS, og de fejler uafhængigt af hinanden. Sammenlign, hvad hver af dem offentliggør, i stedet for at stole på afkrydsningsfeltet på netværkskortet, som kun styrer én af dem. Symptomet er det samme i alle tilfælde: en klient slår navnet op, modtager tunneladressen og kan ikke nå domænecontrolleren. Hvem der offentliggjorde den, afgør, hvordan man stopper det.

Én indstilling, én tjeneste og én rolle; tre udgivere, tre kontakter.

Start med posten, ikke afkrydsningsfeltet

Forespørg på den berørte servers fulde navn via den DNS-server, som klienterne faktisk bruger, og notér hver adresse, der returneres. Hold hver returneret adresse op mod serverens faktiske LAN- og tunnelinterfaces og mod de netværk, klienterne sidder på. En adresse kan være helt gyldig lokalt og utilgængelig for de klienter, der betyder noget. Periodiske godkendelsesfejl er et almindeligt symptom, fordi klienter modtager eller vælger forskellige adresser ved forskellige forsøg.

At maskinen slår sit eget navn korrekt op beviser meget lidt. Den test, der betyder noget, kører fra klientnetværkene.

Netværkskortet er kun én udgiver

Netværkskortets TCP/IP-egenskaber har et afkrydsningsfelt til at registrere forbindelsens adresse, og når du fjerner markeringen, bringer det præcis én udgiver til tavshed. Det stopper ikke de andre, og derfor kan posten dukke op igen efter en genstart. Hvis domænecontrolleren også kører DNS-tjenesten, har den tjeneste sin egen lyttekonfiguration og sine egne navneserverposter. Microsofts vejledning til miljøer med flere netværkskort behandler interfaceadfærd, DNS-tjenesten og Netlogon som separate relevante udgivere.

Tre kontakter, tre ejere, og kun én af dem bor på netværkskortets egenskabsside.

DNS-tjenesten har sine egne adresser

En DNS-server, der får besked om at lytte på en VPN-adresse, bliver ved med at offentliggøre den i sine egne poster, uanset hvad afkrydsningsfeltet på netværkskortet påstår. Afstem tjenestens lytteadresser med de tilsigtede interfaces, og gennemgå samtidig zonens navneserverposter. Ændrede lyttere kan afbryde klienter, der netop nu bruger en adresse, du fjerner, så fastslå først, hvem der afhænger af hver enkelt. At slette en lytter, blot fordi det er en VPN-adresse, kan afskære de klienter, du prøvede at hjælpe.

Netlogon og domænecontrollerfund i almindelighed registrerer også adresser som en del af deres egne pligter. Undertryk ikke registreringer i hele domænet, og kopiér ikke en gammel registreringsløsning til fjernadgang uden at bekræfte, at den gælder for din version og rolle.

Ejerskab før oprydning

Ret udgiveren, før du fjerner posten, ellers sætter den næste registreringshændelse den tilbage, og øvelsen gentages. Fjern forældede poster via DNS-ejerens proces, og tag højde for cache og alder. Kontroller fra klientnetværkene, både domænefund og det program, der oprindeligt fejlede, og udløs derefter den samme VPN-hændelse, som først frembragte adressen.

Det, du vil have til sidst, er et kendt sæt offentliggjorte adresser og lyttere, mens den daglige domæneregistrering stadig gør sit arbejde. En maskine, hvis navn tilfældigvis slår rigtigt op lige efter manuel oprydning, er ikke det.

Notér, hvilken udgiver der var ansvarlig, hvilke poster der blev ændret, og hvilke klienter der blev testet. Den næste server med flere netværkskort vil have de samme tre mistænkte.