DNS-Timeout mit Directory Server

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Joachim_S

Benutzer
Registriert
18. Aug. 2023
Beiträge
49
Reaktionspunkte
9
Punkte
8
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
 
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.
 
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?
 
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
 
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.
 
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 ?
 
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:
Hast du dein Bond als Standard Gw definiert?
Cache findest du in der Syno unter Dateidienste > SMB Cache
 
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:
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.
 
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:
Hast du schon mal mit RSAT direkt in die Konfiguration geschaut?
 
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:
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.
 
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!
 
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ß.
 
Mit Protokoll meinte ich das des DC, nicht den PC

RSAT: Mit RSAT werden zusätzliche Tools angeboten, auf für DNS Einstellungen. Die solltest du mal nutzen, weil sie mehr anzeigen als das was Synology anbietet.
 
*GELÖST*!
Wie es aussieht, ist das Problem jetzt wohl behoben. In den Ressourceneiträgen der Active Directory-Zone des DNS-Servers auf der DS1522+ fehlte ein Typ A-Eintrag für den Domain Controller selbst (er heißt bei uns "CAENAS" ):

caenas.<unsere Domäne>, Typ=A, TTL=900, Info=192.168.0.98

Tatsächlich war das Fehlen dieser Zeile beim DNS-Test als erstes bemängelt worden. Mein Fehler war, dass ich dort zuerst den zweiten Fehler behoben habe (Netzwerkeinstellungen) mit dem Nebeneffekt, dass der erste Fehler auch als behoben galt (grüner Haken), was leider nicht stimmte. Warum die Zeile verschwunden war, bleibt unklar, denn das System war ja vorher einwandfrei gelaufen. Vermutlich haben sich meine beiden DC-Synologies (Haupt- und Notfallgerät), als sie kurzzeitig (aus Versehen) beide liefen, gegenseitig die DNS-Settings zerschossen.
Die Lösung besteht also im Bereinigen der DNS-Ressourceneinträge für die AD-Zone von doppelten Fehleinträgen und Wiederhinzufügen der oben zitierten Zeile.

Herzlichen Dank, dass Ihr euch so viel Zeit genommen habt, mich bei der Problemlösung zu unterstützen!
 
  • Like
Reaktionen: NSFH

Additional post fields

 

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