11
Probleme mit Multihomed DCs vermeiden
In bestimmten Szenarios kann es notwendig sein, dass ein Domain Controller mehrere IP-Adressen hat.
Und das kann einige Probleme nach sich ziehen...
Während dieser Anleitungen werden Änderungen an der Registry und am DNS-Server vorgenommen. Beides kann, wenn es falsch durchgeführt wird zu Störungen, Datenverlust oder einem Totalausfall der Domäne führen. Diese Anleitung ist nach bestem Wissen und Gewissen entstanden. Ich übernehme dennoch keine Garantie für die Richtigkeit der Angaben oder Verantwortung für eventuell entstandene Schäden.
Diese Anleitung sollte nur von Personen mit Erfahrungen im Umgang mit der Registry und dem Microsoft DNS-Server befolgt werden.
Als "multihomed DC" bezeichnet man Domain Controller, die mehrere IP-Adressen haben, also in mehreren Subnets "zuhause" sind.
Dies macht zum Beispiel bei folgenden Szenarios sinn:
Active Directory macht sehr ausgiebig Nutzen von DNS. Dabei registrieren sich standardmäßig auch alle Computer mit allen ihren IPs im DNS-Server.
Wenn nun ein Client eine Anfrage an den Server stellt erhält er wiederum alle diese IPs mitgeteilt:
Zwar sollte sich ein Client nicht mehr Mühe machen als unbedingt notwendig und darum immer die IP-Adresse benutzen, die in seinem eigenen Subnetz liegt, dies ist allerdings nicht automatisch garantiert.
Praktisch macht sich dass dann durch Verzögerungen von bis zu mehreren Minuten und Verbindungsfehler bemerkbar.
Diese Anleitung zeigt einige wichtige Schritte auf, um diese Probleme zu vermeiden.
Wichtig: Diese Anleitung sollte zwar auch dann funktionieren, wenn man mehrere Netzwerke benutzt in denen die AD-Funktionalität des Servers wichtig ist, getestet habe ich sie aber nur für das Szenario eines AD-Netzwerks und mehreren sekundären Hintergrundnetzwerken.
Also, dann wollen wir mal:
Zuerst müssen wir die automatische DNS-Registrierung aller Netzwerkkarten unterbinden, die nicht zum Subnetz mit dem primären DNS-Suffix gehören.
Bei folgender Konfiguration:
Muss entsprechend für alle Netzwerkkarten außer Nr. 1 die automatische DNS-Registrierung deaktiviert werden.
Das geht so:
Wenn der Server, auf dem diese Anleitung durchgeführt wird, auch noch einen DNS-Dienst hat waren die obigen Schritte noch nicht ausreichend!
Zusätzlich muss nun noch Methode A oder B durchgeführt werden:
Methode A
Vorsicht: Diese Methode hat einen enormen Nachteil. Es ist danach nämlich nicht mehr möglich die DNS-Funktionalität dieses Servers in den anderen Subnetzen außer dem primären zu verwenden.
Soll der DNS-Server aber für alle Subnets verwendet werden empfiehlt sich Methode B!
Methode B
Damit haben wir zwar schon einmal verhindert, dass sich ein Domänen-Controller unter seinem eigenen Namen mit allen seinen IP-Adressen automatisch registriert, aber es gibt noch andere Orte im DNS an dem sich der Domänencontroller registriert. Diese automatische Registrierung werden wir jetzt unterbinden:
Diese Methode ist alternativ zu Methode A
Bevor wir weiter machen müssen wir den DNS-Server-Dienst neustarten
Nachdem wir jetzt einiges umgestellt haben müssen wir die DNS-Einträge kontrollieren.
Wichtig
Wer jetzt noch Lust hat kann zusätzlich noch die Einträge unter
Zum Schluss ist es noch ganz Sinnvoll die Priorität der Netzwerkkarten richtig zu ordnen:
Mit dieser Anleitung haben wir erst einmal sichergestellt, dass das primäre Subnetz problemlos funktioniert.
Man könnte nun im DNS-Server noch Zonen für die anderen Subnets einrichten um die Server auch dort über DNS-Namen ansprechbar zu machen.
Wichtig ist auch, dass wir mit diesen Schritten einen großen Teil der Dynamik von AD entfernt haben.
Ändert sich z.B. nun die IP-Adresse eines Servers so sollte die Anleitung noch einmal durchgegangen werden um sicherzustellen, dass sich nicht noch eine alte IP-Adresse festgesetzt hat.
http://support.wftx.us/Multihomed_Reg_Fix.txt
Microsoft KB 246804
Microsoft KB 295328
Dies ist meine erste Anleitung, ich bin dahher für alle Ratschläge, Tipps und Korrekturen dankbar
Und das kann einige Probleme nach sich ziehen...
Inhaltsverzeichnis
Wichtig
Während dieser Anleitungen werden Änderungen an der Registry und am DNS-Server vorgenommen. Beides kann, wenn es falsch durchgeführt wird zu Störungen, Datenverlust oder einem Totalausfall der Domäne führen. Diese Anleitung ist nach bestem Wissen und Gewissen entstanden. Ich übernehme dennoch keine Garantie für die Richtigkeit der Angaben oder Verantwortung für eventuell entstandene Schäden.
Diese Anleitung sollte nur von Personen mit Erfahrungen im Umgang mit der Registry und dem Microsoft DNS-Server befolgt werden.
Was sind multihomed DCs?
Als "multihomed DC" bezeichnet man Domain Controller, die mehrere IP-Adressen haben, also in mehreren Subnets "zuhause" sind.
Dies macht zum Beispiel bei folgenden Szenarios sinn:
- Man hat neben dem normalen Netzwerk in dem sich die Clients befinden ein Backup-Netzwerk in dem sich nur die Server befinden und dort ihre Daten gegenseitig sichern/replizieren.
- Alle Clients im Produktivnetz können nur über einen Proxy ins Internet, der zur Sicherheit z.B. alle exe-Dateien filtert - die Server müssen aber für WSUS Updates herunterladen und brauchen darum einen direkten Internetzugriff
- Man hat mehrere nicht gegeneinander geroutete VLANs
Was für Probleme können entstehen?
Active Directory macht sehr ausgiebig Nutzen von DNS. Dabei registrieren sich standardmäßig auch alle Computer mit allen ihren IPs im DNS-Server.
Wenn nun ein Client eine Anfrage an den Server stellt erhält er wiederum alle diese IPs mitgeteilt:
Zwar sollte sich ein Client nicht mehr Mühe machen als unbedingt notwendig und darum immer die IP-Adresse benutzen, die in seinem eigenen Subnetz liegt, dies ist allerdings nicht automatisch garantiert.
Praktisch macht sich dass dann durch Verzögerungen von bis zu mehreren Minuten und Verbindungsfehler bemerkbar.
Diese Anleitung zeigt einige wichtige Schritte auf, um diese Probleme zu vermeiden.
Wichtig: Diese Anleitung sollte zwar auch dann funktionieren, wenn man mehrere Netzwerke benutzt in denen die AD-Funktionalität des Servers wichtig ist, getestet habe ich sie aber nur für das Szenario eines AD-Netzwerks und mehreren sekundären Hintergrundnetzwerken.
Die Lösung des Problems
Also, dann wollen wir mal:
DNS-Registrierung der IP-Adressen unterbinden
Zuerst müssen wir die automatische DNS-Registrierung aller Netzwerkkarten unterbinden, die nicht zum Subnetz mit dem primären DNS-Suffix gehören.
Bei folgender Konfiguration:
| Netzwerkkarte | Subnetz | Maske | DNS-Suffix |
|---|---|---|---|
| 1 | 172.16.0.0 | 255.255.0.0 | firma.local (dies ist das primäre DNS-Suffix = der Name der AD-Domäne) |
| 2 | 172.17.0.0 | 255.255.255.0 | inet.firma.local |
| 3 | 172.18.0.0 | 255.255.255.0 | dev.firma.local |
Muss entsprechend für alle Netzwerkkarten außer Nr. 1 die automatische DNS-Registrierung deaktiviert werden.
Das geht so:
- "Start" > "Einstellungen" > "Netzwerkverbindungen"
- Wähle die Netzwerkkarte aus, auf der die DNS-Registrierung deaktiviert werden soll
- Rechtsklick > "Eigenschaften"
- Wähle aus der Liste "Internetprotokoll (TCP/IP)" (Bei Server 2008 muss dieser Schritt für IPv4 und IPv6 ausgeführt werden, sofern aktiviert) > Eigenschaften
- "Erweitert..." > "DNS"
- Unten: "Adressen dieser Verbindung in DNS registrieren" > Haken entfernen
- Ab Schritt 2 für alle Karten wiederholen, die deaktiviert werden sollen
Zusätzliche Schritte auf dem DNS-Server
Wenn der Server, auf dem diese Anleitung durchgeführt wird, auch noch einen DNS-Dienst hat waren die obigen Schritte noch nicht ausreichend!
Zusätzlich muss nun noch Methode A oder B durchgeführt werden:
Methode A- "Start" > "Ausführen..." > "dnsmgmt.msc" > OK
- Rechtklick auf den Namen des DNS-Servers > "Eigenschaften" > Reiter "Schnittstellen"
- Dort die Option "Nur folgende IP-Adressen:" auswählen
- Auf Server 2008: Entferne alle Haken, außer die der primären IP-Adresse.
- Auf Server 2003: Wähle nacheinander alle IP-Adressen außer die der primären Netzwerkkarte aus und klicke auf "Entfernen"
Vorsicht: Diese Methode hat einen enormen Nachteil. Es ist danach nämlich nicht mehr möglich die DNS-Funktionalität dieses Servers in den anderen Subnetzen außer dem primären zu verwenden.
Soll der DNS-Server aber für alle Subnets verwendet werden empfiehlt sich Methode B!
Methode B- Öffne den Registry Editor
- Navigiere zum Key:
HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters - Dort Rechtsklick > "Neu" > "Zeichenfolge" (REG_SZ)
- Der Name ist
PublishAddresses - Per Doppelklick öffnen und bei Wert die IP-Adresse der primären Verbindung eintragen (mehrere IP-Adressen werden mit Leerzeichen getrennt).
DNS-Registrierung von NETLOGON unterbinden
Damit haben wir zwar schon einmal verhindert, dass sich ein Domänen-Controller unter seinem eigenen Namen mit allen seinen IP-Adressen automatisch registriert, aber es gibt noch andere Orte im DNS an dem sich der Domänencontroller registriert. Diese automatische Registrierung werden wir jetzt unterbinden:
Methode A
- Öffne den Registry Editor
- Navigiere zum Key:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters - Dort "Rechtsklick > "Neu" > "Wert der mehrteiligen Zeichenfolge" (REG_MULTI_SZ)
- Der Name ist
DnsAvoidRegisterRecords - Per Doppelklick öffnen und folgenden Wert eintragen:
LdapIpAddress - Hat der Domain Controller auch noch einen GC (Globalen Katalog) muss in eine neue Zeile zusätzlich noch folgender Wert:
GcIpAddress
Methode B
Diese Methode ist alternativ zu Methode A
- Öffne den Registry Editor
- Navigiere zum Key:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters - Dort "Rechtsklick > "Neu" > "DWORD-Wert" (REG_DWORD)
- Der Name ist
RegisterDnsARecords - Per Doppelklick öffnen und folgenden Wert eintragen:
0(sollte automatisch dort stehen
Dienst neu starten
Bevor wir weiter machen müssen wir den DNS-Server-Dienst neustarten
- "Start" > "Ausführen" > "dnsmgmt.msc" > "OK"
- Rechtsklick auf den Namen des Servers in der linken Ansicht > "Alle Aufgaben" > "Neu starten"
DNS-Einträge kontrollieren
Nachdem wir jetzt einiges umgestellt haben müssen wir die DNS-Einträge kontrollieren.
| Name | Typ | Daten |
|---|---|---|
| (identisch mit übergeordneten Ordner) | Host (A) | Primäre IP-Adresse des DC |
| (identisch mit übergeordneten Ordner) | Nameserver (NS) | DNS-Name des DNS-Servers (z.b. dc1.firma.local.) |
| Name des DC | Host (A) | Primäre IP-Adresse des DC |
Wichtig
- Finger Weg vom "Autoritätsursprung (SOA)"-Eintrag. Der bleibt wie er ist
- Wenn der Server auch IPv6-Adressen hat muss es auch entsprechende "Host (AAAA)"-Einträge geben
- Wenn man mehrere DCs/DNS-Server hat gibt es die obigen Einträge für jeden jeweils einmal
Zusätzlich müssen für einen GC noch folgende Einträge kontrolliert werden:
| Name | Typ | Daten |
|---|---|---|
| (identisch mit übergeordneten Ordner) | Host (A) | Primäre IP-Adresse des DC |
Wer jetzt noch Lust hat kann zusätzlich noch die Einträge unter
DomainDnsZones.<domänenname> und ForestDnsZones.<domänenname> kontrollieren. Das Schema ist das Gleiche.Reihenfolge der Netzwerkkarte korrigieren
Zum Schluss ist es noch ganz Sinnvoll die Priorität der Netzwerkkarten richtig zu ordnen:
- "Start" > "Einstellungen" > "Netzwerkverbindungen"
- Im Menü: "Erweitert" > "Erweiterte Einstellungen..."
- Sortiere die Verbindungen so, dass die primäre ganz oben ist.
- Zusätzlich macht es noch Sinn für die Netzwerkkarten, auf denen Dateifreigaben und NetBIOS nicht benötigt wird im Feld "Bindungen für <Netzwerkkarte>" die Einträge "Datei- und Druckerfreigabe für Microsoft-Netzwerke" und "Client für Microsoft-Netzwerke zu deaktivieren
Wie geht's weiter?
Mit dieser Anleitung haben wir erst einmal sichergestellt, dass das primäre Subnetz problemlos funktioniert.
Man könnte nun im DNS-Server noch Zonen für die anderen Subnets einrichten um die Server auch dort über DNS-Namen ansprechbar zu machen.
Wichtig ist auch, dass wir mit diesen Schritten einen großen Teil der Dynamik von AD entfernt haben.
Ändert sich z.B. nun die IP-Adresse eines Servers so sollte die Anleitung noch einmal durchgegangen werden um sicherzustellen, dass sich nicht noch eine alte IP-Adresse festgesetzt hat.
Quellen
http://support.wftx.us/Multihomed_Reg_Fix.txt
Microsoft KB 246804
Microsoft KB 295328
Schlussbemerkung
Dies ist meine erste Anleitung, ich bin dahher für alle Ratschläge, Tipps und Korrekturen dankbar
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 113672
Url: https://administrator.de/tutorial/probleme-mit-multihomed-dcs-vermeiden-113672.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
11 Kommentare
Neuester Kommentar
du glaubst gar nicht, wie unendlich dankbar ich dir gerade für diese anleitung bin! hatte ein riesenchaos nach dem einbau zweier zusätzlicher netzwerkkarten in zwei bestehende domänencontroller. habe mich dumm und dämlich konfiguriert, getestet und so weiter. jetzt läuft endlich alles wieder absolut sauber, hab vielen dank!
Hallo dog,
auch von meiner Seite aus einen Dank für diese Anleitung. Ich fand sie sehr hilfreich. Ich arbeite gerade an einem Showcase Exchange 2003 zu Exchange 2010 in einer Hyper-V Umgebung und konnte dies genau "jetzt" brauchen.
Gruß
Thomas
auch von meiner Seite aus einen Dank für diese Anleitung. Ich fand sie sehr hilfreich. Ich arbeite gerade an einem Showcase Exchange 2003 zu Exchange 2010 in einer Hyper-V Umgebung und konnte dies genau "jetzt" brauchen.
Gruß
Thomas
... super Anleitung, hat mir sehr geholfen - wir haben allerdings unter bestimmten Bedingungen Probleme feststellen können:
Wir haben eine geroutete Windows Umgebung. Das heißt Clients sitzen in verschiedenen Subnetzen.
z.B.
192.168.xx1.0/24 -> Client Netzwerk
192.168.xx2.0/24 -> Server Netzwerk
192.168.xx3.0/24 -> Client Netzwerk an einem anderen Standort welcher per VPN angebunden ist
Nach den Änderungen bezüglich des Netlogons
"DNS-Registrierung von NETLOGON unterbinden" -> "Methode A"
konnten die Clients die Netzwerkfreigaben nicht mehr aufrufen. Es ist anzunehmen (habe ich nicht weiter kontrolliert), daß die Clients sich auch mit einem zwischengespeicherten Profil angemeldet haben (das würde also spätestens nach 10 Anmeldungen am zwischen gespeicherten Profil ebenfalls Probleme machen). Weiter konnten die Clients die DNS Domäne des AD nicht pingen.
Meine Vermutung ist, daß durch die Einstellungen "DNS-Registrierung von NETLOGON unterbinden" -> "Methode A" kein Global Catalog sowie ldap für die Domäne verfügbar war.
Ich habe also diese Einstellungen Rückgängig gemacht und seit dem läuft alles wieder einwandfrei.
Mir ist auch nicht ganz klar warum diese Einstellungen gemacht werden sollten, da sich in unserer Config die SRV Einträge für _ldap immer auf einen DNS Namen zeigen und dieser ja durch die Einstellungen "DNS-Registrierung der IP-Adressen unterbinden" sowie "Zusätzliche Schritte auf dem DNS-Server" -> "Methode A" jetzt eindeutig ist. Desweiteren scheint sich die Einstellung "DNS-Registrierung der IP-Adressen unterbinden" sowie "Zusätzliche Schritte auf dem DNS-Server" -> "Methode A" auch auf die gc registrierung auszuwirken. Zumindest habe ich nun hier auch nur die IP Adresse der "primären" Netzwerkkarte"
Für Feedback wäre ich dankbar - evtl habe ich ja auch nur einen Fehler gemacht
Wir haben eine geroutete Windows Umgebung. Das heißt Clients sitzen in verschiedenen Subnetzen.
z.B.
192.168.xx1.0/24 -> Client Netzwerk
192.168.xx2.0/24 -> Server Netzwerk
192.168.xx3.0/24 -> Client Netzwerk an einem anderen Standort welcher per VPN angebunden ist
Nach den Änderungen bezüglich des Netlogons
"DNS-Registrierung von NETLOGON unterbinden" -> "Methode A"
konnten die Clients die Netzwerkfreigaben nicht mehr aufrufen. Es ist anzunehmen (habe ich nicht weiter kontrolliert), daß die Clients sich auch mit einem zwischengespeicherten Profil angemeldet haben (das würde also spätestens nach 10 Anmeldungen am zwischen gespeicherten Profil ebenfalls Probleme machen). Weiter konnten die Clients die DNS Domäne des AD nicht pingen.
Meine Vermutung ist, daß durch die Einstellungen "DNS-Registrierung von NETLOGON unterbinden" -> "Methode A" kein Global Catalog sowie ldap für die Domäne verfügbar war.
Ich habe also diese Einstellungen Rückgängig gemacht und seit dem läuft alles wieder einwandfrei.
Mir ist auch nicht ganz klar warum diese Einstellungen gemacht werden sollten, da sich in unserer Config die SRV Einträge für _ldap immer auf einen DNS Namen zeigen und dieser ja durch die Einstellungen "DNS-Registrierung der IP-Adressen unterbinden" sowie "Zusätzliche Schritte auf dem DNS-Server" -> "Methode A" jetzt eindeutig ist. Desweiteren scheint sich die Einstellung "DNS-Registrierung der IP-Adressen unterbinden" sowie "Zusätzliche Schritte auf dem DNS-Server" -> "Methode A" auch auf die gc registrierung auszuwirken. Zumindest habe ich nun hier auch nur die IP Adresse der "primären" Netzwerkkarte"
Für Feedback wäre ich dankbar - evtl habe ich ja auch nur einen Fehler gemacht
Wir haben eine geroutete Windows Umgebung
Dann ist die Anleitung eigentlich auch nicht für dich gedacht.
Das ganze über Routing zu lösen ist der wesentlich bessere Weg.
Die Anleitung ist ja nur für genau den Fall gedacht, dass ein Server in mehreren Subnets ist (wenn du ihn z.B. zu mehreren VLANs hinzufügst), die untereinander nicht kommunizieren können.
Mir ist auch nicht ganz klar warum diese Einstellungen gemacht werden sollten
Die DNS-Bäume
gc._msdcs.domain (hierauf bezieht sich GcIpAddress) und domain (hierauf bezieht sich LdapIpAddress) enthalten die IP-Adressen von DCs als (identisch mit übergeordnetem Ordner).Methode A verhindert dabei nur die vorgegeben Einträge, Methode B alle (also auch die SRV-Einträge).
konnten die Clients die Netzwerkfreigaben nicht mehr aufrufen.
Hast du denn einen Test per
nslookup servername UND nslookup servername.domain und nslookup domain gemacht?Grade die Schritte zur Kontrolle sind sehr wichtig, denn die Einträge müssen passen!
Grüße
Max
Hi Max,
danke für dein Feedback.
Bezüglich der gerouteten Umgebung habe ich mich wohl etwas missverständlich ausgedrückt:
Die Server haben 2 Netzwerkkarten. Eine für das Netzwerk zu den Clients hin und eine für ein SAN. In das SAN Netz haben die Clients keinen Zugriff. Mit gerouteter Umgebung wollte ich ausdrücken, dass nicht alle Clients im Subnet der Server sitzen.
"Die DNS-Bäume gc._msdcs.domain (hierauf bezieht sich GcIpAddress) und domain (hierauf bezieht sich LdapIpAddress) enthalten die IP-Adressen von DCs als (identisch mit übergeordnetem Ordner)." erklärt ja dann auch warum dieser Fehler entstanden ist.
Vielen Dank
danke für dein Feedback.
Bezüglich der gerouteten Umgebung habe ich mich wohl etwas missverständlich ausgedrückt:
Die Server haben 2 Netzwerkkarten. Eine für das Netzwerk zu den Clients hin und eine für ein SAN. In das SAN Netz haben die Clients keinen Zugriff. Mit gerouteter Umgebung wollte ich ausdrücken, dass nicht alle Clients im Subnet der Server sitzen.
"Die DNS-Bäume gc._msdcs.domain (hierauf bezieht sich GcIpAddress) und domain (hierauf bezieht sich LdapIpAddress) enthalten die IP-Adressen von DCs als (identisch mit übergeordnetem Ordner)." erklärt ja dann auch warum dieser Fehler entstanden ist.
Vielen Dank
Der Artikel ist nach wie vor aktuell (zumindest mit SBS 2011 Essentials Server + Windows 7 Professional Clients).
Ich habe eine kleine Domäne eingerichtet, bei der die Client Rechner über ein reines 10Gb Netzwerk (mit Intel X540-T1 Karten) mit dem Server verbunden sind (Netz 176.16.1.x), während der Internetzugang und der Zugriff auf langsame Peripherie Geräte über die eingebauten 1Gb Motherboard IP Schnittstellen (Netz 192.168.10.x) erfolgt. Ich habe die Anleitung befolgt, und es funktioniert soweit alles prima (Fileserver- und LDAP Zugriff erfolgen nur über das schnelle 176.16.1.x Netz).
Allerdings wollte ich noch eine Bemerkung loswerden:
Man muss unbedingt den Dienst
"Windows Server LAN Configuration"
deaktivieren, ansonsten gehen die manuell gemachten Einstellungen teilweise wieder verloren, wenn man einen Client Rechner einaml mit ausgeschaltetem DC gebootet hat.
In meinem Fall wurde die Einstellung "Adressen dieser Verbindung in DNS registrieren" wieder auf true gesetzt, ausserdem hatte ich als DNS Server für das 192'er Netz die IP meines Netgear Routers (192.168.10.1) eingestellt, stattdessen wurde als DNS Server für das 192'er Netz die IP Nummer meines DC Servers im 192'er Netz (192.168.10.5) eingesetzt, was natürlich nicht funktioniert hat (und eigentlich auch gar nicht passieren dürfte), da der DNS Server auf dem DC nur am 172'er Netz lauscht, und ich auf dem DC keinen DHCP Server laufen habe.
Deaktiviert man jedoch den obigen Service, bleiben alle manuellen Einstellungen erhalten, ich kann sogar die IP Nummern des 192'er Netzes automatisch per DHCP vom Netgear Router vergeben lassen.
Ich habe eine kleine Domäne eingerichtet, bei der die Client Rechner über ein reines 10Gb Netzwerk (mit Intel X540-T1 Karten) mit dem Server verbunden sind (Netz 176.16.1.x), während der Internetzugang und der Zugriff auf langsame Peripherie Geräte über die eingebauten 1Gb Motherboard IP Schnittstellen (Netz 192.168.10.x) erfolgt. Ich habe die Anleitung befolgt, und es funktioniert soweit alles prima (Fileserver- und LDAP Zugriff erfolgen nur über das schnelle 176.16.1.x Netz).
Allerdings wollte ich noch eine Bemerkung loswerden:
Man muss unbedingt den Dienst
"Windows Server LAN Configuration"
deaktivieren, ansonsten gehen die manuell gemachten Einstellungen teilweise wieder verloren, wenn man einen Client Rechner einaml mit ausgeschaltetem DC gebootet hat.
In meinem Fall wurde die Einstellung "Adressen dieser Verbindung in DNS registrieren" wieder auf true gesetzt, ausserdem hatte ich als DNS Server für das 192'er Netz die IP meines Netgear Routers (192.168.10.1) eingestellt, stattdessen wurde als DNS Server für das 192'er Netz die IP Nummer meines DC Servers im 192'er Netz (192.168.10.5) eingesetzt, was natürlich nicht funktioniert hat (und eigentlich auch gar nicht passieren dürfte), da der DNS Server auf dem DC nur am 172'er Netz lauscht, und ich auf dem DC keinen DHCP Server laufen habe.
Deaktiviert man jedoch den obigen Service, bleiben alle manuellen Einstellungen erhalten, ich kann sogar die IP Nummern des 192'er Netzes automatisch per DHCP vom Netgear Router vergeben lassen.
Meine Frage steht jetzt hier: DNS Host (A) Eintrag fehlt
Hallo - gute Anleitung!
Was ist aber wenn meine Domänencontroller in zwei unterschiedlichen Netzen nur die IP Adresse in dem jeweiligem Subnetz anzeigen sollen?
Ich habe folgendes Szenario: Die Domänecontroller haben ein Frontend Interface um Verbindung zu unserem Intranet zu haben. Über dieses registrieren sie sich an den DNS Servern die halt im Intranet stehen. Sagen wir mal das Netz liegt im 10.x.x.x Bereich.
Das zweite Interface befindet sich im Admin-Subnetz. Dieses Netz ist nur intern, von dort aus sollen sich Clients an der Domäne anmelden, die keinen Zugriff in das Intranet haben dürfen. Dieses Netz hat z.B. 172.16.x.x als IP-Bereich.
Nun antworten die Domänencontroller aber mit beiden IP-Adressen, wenn ich mit einem Client ein nslookup mache. Kann man als DNS Antwort nur eine IP Adresse nur für das jeweilige Subnetz zulassen? Wie gesagt, beide Netze werden für die DNS Auflösung gebraucht..
LG Johannes
Was ist aber wenn meine Domänencontroller in zwei unterschiedlichen Netzen nur die IP Adresse in dem jeweiligem Subnetz anzeigen sollen?
Ich habe folgendes Szenario: Die Domänecontroller haben ein Frontend Interface um Verbindung zu unserem Intranet zu haben. Über dieses registrieren sie sich an den DNS Servern die halt im Intranet stehen. Sagen wir mal das Netz liegt im 10.x.x.x Bereich.
Das zweite Interface befindet sich im Admin-Subnetz. Dieses Netz ist nur intern, von dort aus sollen sich Clients an der Domäne anmelden, die keinen Zugriff in das Intranet haben dürfen. Dieses Netz hat z.B. 172.16.x.x als IP-Bereich.
Nun antworten die Domänencontroller aber mit beiden IP-Adressen, wenn ich mit einem Client ein nslookup mache. Kann man als DNS Antwort nur eine IP Adresse nur für das jeweilige Subnetz zulassen? Wie gesagt, beide Netze werden für die DNS Auflösung gebraucht..
LG Johannes
Was ist aber wenn meine Domänencontroller in zwei unterschiedlichen Netzen nur die IP Adresse in dem jeweiligem Subnetz anzeigen sollen?
Das bekommst du mit Windows Bordmitteln nicht hin.
Solche Szenarios kann BIND über DNS Views abbilden, aber ehrlich gesagt ist es da deutlich leichter einen Router mit Firewall dazwischen zu hängen und den DC dann in ein eigenes Netz zu stellen.
Danke dir für deine Antwort. Ich habe hier zur Sicherheit mal ein Bild gemacht, falls es da noch Unklarheiten gibt. Eine Firewall / Router zwischen den Netzen ist definitiv gegeben:
http://img5.fotos-hochladen.net/uploads/dnstizvg2c4hp.png
Wenn man hier nichts machen kann dann ist das halt so. Es funktioniert ja auch. Allerdings mache ich mir etwas Sorgen dass es zukünftig zu irgendwelchen DNS Auflösungsproblemen kommen könnte, die man bei der jetzigen Einrichtung noch nicht bedacht hat.
http://img5.fotos-hochladen.net/uploads/dnstizvg2c4hp.png
Wenn man hier nichts machen kann dann ist das halt so. Es funktioniert ja auch. Allerdings mache ich mir etwas Sorgen dass es zukünftig zu irgendwelchen DNS Auflösungsproblemen kommen könnte, die man bei der jetzigen Einrichtung noch nicht bedacht hat.
Kurze Frage - Kann man den DNS Dienst im laufendem Produktivbetrieb einfach so neustarten, ohne das Client-Verbindungen wegbrechen oder sowas?
