DNS-Timeout mit Directory Server

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
Hallo zusammen,
seit gestern ist es leider nicht mehr möglich, sich an unserer Domäne anzumelden, die durch einen Synology Directory Server auf einer DS 1522+ unter DSM 7.2 verwaltet wird. Bis dahin war das System recht stabil gelaufen. Jetzt aber wird die Domäne nicht mehr gefunden, offensichtlich ein DNS-Problem.
Wenn ich in der DSM-Systemsteuerung unter "Domain/LDAP" den Test aufrufe, bekomme ich zuerst einmal Orange ("DNS-Einträge prüfen": Kein A/AAAA-Eintrag) und dreimal rot ("Netzwerk überprüfen": Drei Probleme, alle wegen eine falschen IP, dazu gleich mehr, "Domaindienst überprüfen": Keine Antwort von einem Domain Controller, "Domainfunktionalität überprüfen": Keine Antwort von einem Domain Controller).
Zur falschen IP: Eigentlich hat die DS 1522+ die Adresse 192.168.0.98. Diese müsste zutreffend sein für den DNS- wie auch für den Directory Server. Der erwähnte Test findet unter "Netzwerk überprüfen" aber die Nummer 192.168.0.95 (statt .98) und fordert mich auf, die richtige einzugeben. Wenn ich hier nun die 192.168.0.98 eingebe, startet der Test neu und liefert zwei grüne Häkchen (!), d. h. die Probleme mit dem fehlenden Eintrag und die drei Netzwerkprobleme sind behoben. Immer noch rot bleiben die Ergebnisse für Domaindienst und -Funktionalität. In den Details dort steht, der Domain Controller 192.168.0.98 (richtige Nummer!) sei nicht zu finden, ich solle diese IP doch korrigieren. Aber wie soll ich das machen, da sie ja schon richtig ist?
Zur Vorgeschichte:
Am Tag vor dem Problem hatte ich die Netzwerkverbindung der DS von einem 2er-Bond auf ein 3er-Bond geändert, um mehr Bandbreite zu bekommen. Dafür musste der 2er-Bond gelöscht und ein neuer über drei Buchsen erzeugt werden. Vielleicht sind dabei die DNS-Einstellungen beschädigt worden.
Außerdem, am selben Tag, habe ich eine zweite DS 1522+ aufgesetzt durch Kopieren von der ersten. Dazu habe ich ein Vollbackup der ersten DS, das ich sowieso hatte, mit HyperBackup auf die zweite zurückgesichert. Diese hatte zunächst die IP 192.168.0.95 und wurde von mir per Hand auf .98 geändert. Dabei waren, so befürchte ich, kurzzeitig beide DS online, beide mit derselben IP und beide als Domain Controller. Können sich die beiden dabei gegenseitig "beschädigt" haben mit den beschriebenen Folgen?

Nslookup auf Client-PCs liefert meistens Timeouts , manchmal nach längerer Zeit doch einen Treffer in Form des Domänennamens. Nslookup auf der DS selber (mit PuTTY) liefert sofort die korrekte Domäne, aber doppelt: einmal mit der falschen und einmal mit der richtigen IP.

Frage: Wie bekomme ich die korrekten DNS-Einstellungen für den Directory Server wieder hin?

Viele Grüße
Joachim
 

NSFH

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
4.162
Punkte für Reaktionen
611
Punkte
194
Also 2 identische DC gleichzeitig mit verschiedenen IPs laufen zu lassen hatte ich auch noch nicht. Welche Probleme das mitgebracht hat keine Ahnung, aber als erstes würde ich mal alle Caches der Syno löschen. Da könnten unterschiedliche Daten drin stehen.
Das Ändern der Netzwerkschnittstellen hatte schon öfters mal Probleme gemacht. Möglich, dass hier neben dem Bond noch die alten Einstellungen existieren.
Hilfreich wäre ein direkter Blick auf die Konfig der ETH0-4 direkt unter Linux, also als root ins System gehen.
Eine Hammermethode wäre evtl die gesamte Nw-Konfiguration zu löschen und neu einzustellen und danach den DC anpassen mit leeren des Cache und ggf. Neustart.
 

metalworker

Benutzer
Sehr erfahren
Mitglied seit
25. Apr 2023
Beiträge
3.796
Punkte für Reaktionen
1.547
Punkte
194
also 2 mal das System mit der gleichen IP Laufen ist nicht gut, sollte aber nicht das Problem bei der erzeugt haben.
Bonding ändern ist immer ein heißes Eisen .

Greifst du für die Verwaltung über ne 4. Verbindung auf die Synology zu?
 

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
Also 2 identische DC gleichzeitig mit verschiedenen IPs laufen zu lassen hatte ich auch noch nicht. Welche Probleme das mitgebracht hat keine Ahnung, aber als erstes würde ich mal alle Caches der Syno löschen. Da könnten unterschiedliche Daten drin stehen.
Das Ändern der Netzwerkschnittstellen hatte schon öfters mal Probleme gemacht. Möglich, dass hier neben dem Bond noch die alten Einstellungen existieren.
Hilfreich wäre ein direkter Blick auf die Konfig der ETH0-4 direkt unter Linux, also als root ins System gehen.
Eine Hammermethode wäre evtl die gesamte Nw-Konfiguration zu löschen und neu einzustellen und danach den DC anpassen mit leeren des Cache und ggf. Neustart.
An was für Caches denkst du da? Ich wüsste gar nicht, wo ich die suchen soll.
Meine Netzwerkkonfiguration sieht so aus (und enthält keine IP 192.168.0.95):

ifconfig
bond0 Link encap:Ethernet HWaddr 90:09:D0:1A:7C:CD
inet addr:192.168.0.98 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::9209:d0ff:fe1a:7ccd/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:714514 errors:0 dropped:0 overruns:0 frame:0
TX packets:901567 errors:0 dropped:14 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:90472309 (86.2 MiB) TX bytes:8634754447 (8.0 GiB)

eth0 Link encap:Ethernet HWaddr 90:09:D0:1A:7C:CC
inet addr:193.175.182.80 Bcast:193.175.182.127 Mask:255.255.255.128
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:57 base 0xe000

eth1 Link encap:Ethernet HWaddr 90:09:D0:1A:7C:CD
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:685497 errors:0 dropped:0 overruns:0 frame:0
TX packets:182068 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88151588 (84.0 MiB) TX bytes:20788777 (19.8 MiB)
Interrupt:56 base 0xc000

eth2 Link encap:Ethernet HWaddr 90:09:D0:1A:7C:CE
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:22861 errors:0 dropped:0 overruns:0 frame:0
TX packets:717041 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1563958 (1.4 MiB) TX bytes:8613579221 (8.0 GiB)
Interrupt:55 base 0xe000

eth3 Link encap:Ethernet HWaddr 90:09:D0:1A:7C:CF
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:6156 errors:0 dropped:0 overruns:0 frame:0
TX packets:2458 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:756763 (739.0 KiB) TX bytes:386449 (377.3 KiB)
Interrupt:58 base 0xc000
 

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
also 2 mal das System mit der gleichen IP Laufen ist nicht gut, sollte aber nicht das Problem bei der erzeugt haben.
Bonding ändern ist immer ein heißes Eisen .

Greifst du für die Verwaltung über ne 4. Verbindung auf die Synology zu?
Was meinst du mit einer "4. Verbindung"? Ich logge mich über PuTTY mit einem Root-Account ein.
 

metalworker

Benutzer
Sehr erfahren
Mitglied seit
25. Apr 2023
Beiträge
3.796
Punkte für Reaktionen
1.547
Punkte
194
ich meinte damit . Machst das über den Bond oder über die 193.175.182.80 ?

Die IP Config sieht erstmal gut aus . ABer was ist der Anschluss mit der 193.175.182.80 ?
 

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
eth0 mit der IP 193.175.182.80 ist ein Zugang zum Internet, der normalerweise gar nicht genutzt wird und zurzeit auch nicht angeschlossen ist. Wichtig ist der Zugang zu unserer privaten Labordomäne mit 192.168.0.98, der über den Bond geht.
 
Zuletzt bearbeitet von einem Moderator:

NSFH

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
4.162
Punkte für Reaktionen
611
Punkte
194
Hast du dein Bond als Standard Gw definiert?
Cache findest du in der Syno unter Dateidienste > SMB Cache
 

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
Ja, der Bond ist bei mir auch Standard Gateway - war es vorher und ist es auch jetzt. Sollte das so sein oder lieber nicht?
Das Löschen des SMB-Caches hat nichts geändert, wenn es denn überhaupt erfolgt ist: Als ich den "Löschen"-Knopf betätigt habe, kam die Meldung, in der Folge dieses Befehls würde das Netzwerk der DS neu gestartet. Das ist aber nicht passiert, es lief normal weiter. Ich weiß also nicht, ob der Cache wirklich geleert wurde. Wie auch immer, ich habe die DS dann komplett neu gestartet, aber das Problem ist unverändert da.
 
Zuletzt bearbeitet von einem Moderator:

NSFH

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
4.162
Punkte für Reaktionen
611
Punkte
194
Das zeitweise 2 gleiche DC am Start waren hat sicher für Probleme gesorgt aber glaube nicht, dass das die Ursache für das DNS Problem ist. Ich vermute noch immer die Schnittstellen Config als Ursache.
Ich würde die Schnittstellen alle auflösen nur ETH3 offen lassen um auf DSM zugreifen zu können. Wenn ETH3 klappt ETH0-1 löschen und Neustart. Dann diese neu als Bond mit der gewünschten IP konfigurieren und als Standard Gw definieren.

Wegen Switch: Hast du im Switch auch die drei Ports als BOND konfiguriert? Wenn du da einen Fehler gemacht hast kann das auch zu reichlich fehlerhaftem traffic sorgen.
 

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
Um ein paar Fehlerquellen auszuschließen, habe ich zuletzt nur noch ein Netzwerkkabel verwendet. Von daher glaube ich nicht mehr so recht, das der Bond Schuld ist.
Ich bin aber auf andere Weise deutlich weitergekommen, glaube ich: In den Ressourceneiträgen der AD-Zone des DNS-Servers auf der DS waren ganz viele Einträge doppelt vorhanden, je einmal mit IP ...95 und einmal mit ...98. Die 95er-Doubletten habe ich alle gelöscht, da diese IP eigentlich gar nicht vorkommen sollte, und bekomme jetzt eine saubere Antwort auf nslookup, auf der DS selber wie auch bei den Clients. Keine Timeouts mehr.
Leider wird die Domäne aber von den Clients nach wie vor nicht gefunden: Man kann sich nicht bei ihr anmelden und z. B. auch mit einem neuen Client nicht der Domäne beitreten.
Schade, ich hatte wirklich gehofft, das wär es jetzt gewesen...
 
Zuletzt bearbeitet von einem Moderator:

NSFH

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
4.162
Punkte für Reaktionen
611
Punkte
194
Hast du schon mal mit RSAT direkt in die Konfiguration geschaut?
 

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
Oha,
das ist jetzt ziemlich global formuliert... da bräuchte ich noch ein paar Details, was wo nachzusehen wäre. Die RSAT kenne ich bis jetzt nur vom automatischen Einhängen von Netzlaufwerken, sonst habe ich die noch nie gebraucht.
- Eben habe ich übrigens wieder versucht, mich als Domänenbenutzer im Labor anzumelden. Ergebnis: Benutzer1 - geht! Abgemeldet, nochmal Benutzer1 - geht wieder! Benutzer2 - geht nicht, Domäne nicht gefunden. Nächster PC, wieder Benutzer1 - geht nicht, Domäne nicht gefunden. Am zweiten PC, Benutzer3 - geht! Zurück zum ersten PC, Benutzer3 - geht nicht, Domäne nicht gefunden.
Ich halte fest: Einige Benutzer können sich an bestimmten Domain Clients anmelden, aber an jedem Client sind das andere Benutzer. Das immerhin reproduzierbar. Mir schwirrt der Kopf!
Um auszuschließen, dass das Problem mit irgendwelchen Netzwerkkomponenten zu tun hat, habe ich gestern auch schon einen Testaufbau gemacht mit einem neuen Switch, an dem nur der Server und ein Client hingen. Auch dort wurde die Domäne nicht gefunden. Es muss also am Syno-Server liegen.
Die Kernfrage lautet jetzt: Warum wird eine Domäne problemlos über nslookup gefunden, nicht aber beim Anmelde- oder Beitrittsversuch?
 
Zuletzt bearbeitet von einem Moderator:

NSFH

Benutzer
Sehr erfahren
Mitglied seit
09. Nov 2016
Beiträge
4.162
Punkte für Reaktionen
611
Punkte
194
1. was steht denn im Protokoll bei den Fehlanmeldungen?
2. Überprüfe im DNS Server unter den zwei msdcs.... und domainname@activdirectory alle Eintragungen ob hier die Clients noch passen oder bei einem Gerät oder Zone ein falscher Eintrag steht.
3. Melde mal einen neuen PC an der Domäne an oder lösche einen nicht funktionierenden Client im AD, dann im betroffenen PC Rückkehr zur Workgroup und melde ihn dann erneut an.
 

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
1. was steht denn im Protokoll bei den Fehlanmeldungen?
2. Überprüfe im DNS Server unter den zwei msdcs.... und domainname@activdirectory alle Eintragungen ob hier die Clients noch passen oder bei einem Gerät oder Zone ein falscher Eintrag steht.
3. Melde mal einen neuen PC an der Domäne an oder lösche einen nicht funktionierenden Client im AD, dann im betroffenen PC Rückkehr zur Workgroup und melde ihn dann erneut an.
In der Ereignisanzeige unter "Windows-Protokolle - System" steht nur wieder die schon bekannte Fehlermeldung: "Sie können mit diesen Anmeldeinformationen nicht angemeldet werden, weil Ihre Domäne nicht verfügbar ist...", ansonsten nichts, das mit dem Problem zu tun hätte.
Die Ressourceneinträge des DNS-Servers sehen nach meiner Aufräumaktion von gestern sauber aus mit einer Ausnahme: Der letzte Eintrag lautet "de.<meine Domäne>, Typ A, TTL 1200, 192.168.0.239". Die IP mit ...239 gehört zu einem ganz normalen Client. Ich habe das mal gelöscht, aber geändert hat es nichts.
Einen neuen PC an der Domäne anmelden kann ich nicht, da die Domäne nicht gefunden wird - das ist ja eben mein Problem!
 

Joachim_S

Benutzer
Mitglied seit
18. Aug 2023
Beiträge
25
Punkte für Reaktionen
1
Punkte
3
Eben habe ich nochmal auf der DS den Test unter "Systemsteuerung - Domain/LDAP" gemacht: Dort stehen immer wieder die alten, oben schon zitierten Fehler, einschließlich der falschen IP ...95. Wenn ich dort die richtige (...98) eingebe, startet der Test und gibt nun sogar drei grüne Häkchen aus (DNS-Einträge, Netzwerk, Domainfunktionalität), aber noch rot für Domaindienst. Wenn ich das Fenster in diesem Zustand schließe und den Test erneut aufrufe, ist alles wieder falsch und alles wieder rot. So macht das keinen Spaß.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat