35
DNS Auflösung wird immer vergessen
Hallo Allerseits,
leider ist mir kein besserer Titel eingefallen, da das Thema schwer greifbar ist.
Wir kämpfen seit einem Jahr mit der Umstellung von unserer alten Struktur auf die neue. Haben die meisten Baustellen inzwischen abgeschlossen, aber werden immer wieder von irgendwelchen kleinen Problemen geplagt. Eins davon, wo wir echt am Ende mit unserem Latein sind, ist die DNS Auflösung. DNS Probleme haben wir seit beginn der Umstellung immer wieder mal gehabt, aber konnten Sie in den Griff bekommen. Dieses jedoch hält sich zäh.
Jeden morgen sind unsere Kollegen gezwungen "ipconfig /renew" einzugeben, damit der git client via SSH unseren internen Gitlab-Server ansprechen kann. Ansonsten kommt ein "Host could not resolved" Fehler. Interessanterweise lässt sich das Webinterface auf dem gleichen Server problemlos öffnen. Das hält dann immer ca. 24 h, gleiches aus dem Homeoffice via VPN, ob nun Wireguard oder L2TP. Leider bekommen wir nirgends aussagekräftige Logs, weder von Windows, noch vom DNS Package der Synology oder sonstwo auf dem Server.
Meine Vermutung ist, dass in Unifi irgendetwas vermurkst wird, denn die Unifi-Software hat schon öfter uns Ärger gemacht. Eine Mischung aus Bedienfehler, schlechte Beschreibung / Dokumentation und Softwarefehler.
Wireshark hatte ich auch schon im Einsatz via SSH direkt am Router, aber wirklich schlau bin ich daraus auch nicht geworden.
Wir haben seit ewigkeiten update 'domain/IN' denied Fehler wegen invalider TSIG Signatur. Aber diese Warnungen und Fehler hatten wir auch schon beim alten Server, ohne das wir davon irgendetwas im Alltagsgebrauch gespürt hätten.
Zur Struktur:
Wir haben in der Firma ein Netzwerk mit ca. 15 Windows-Clients (Mischbetrieb Win 10 und 11) + fliegende Laptops unendlich viele Wifi-Geräte. Wir nutzen Synology Active Directory mit High Availability auf DSM 7.2. Im Docker auf Synology läuft Gitlab.
Die Netzwerkinfrastruktur besteht aus PYUR Glasfaser Router Alcatel irgendwas, Ubiquiti Dreammachine Pro SE, USW Pro 48, USW Pro 24 alles im Serverraum wunderbar gepatcht.
Dazu haben wir noch eine ältere Synology Diskstation, welche bis zum letzten Jahr den AD stellte und Gitlab über DSM 6. Da ein Update auf DSM 7 nicht ganz unproblematisch war, da diese Diskstation mehr oder weniger der Single Point of Failure war, haben wir gleich alles modernisiert. Die Netzwerkinfrastruktur lief über einen TP Link Archer C7, ein weiterer als Repeater und einem Unifi ( USW Pro 48 ) und war den Ansprüchen ohnehin nicht mehr gewachsen. Da wir einmal Unifi hatten, wollten wir das auch konsuequent erweitern.
Via DHCP wird der DNS ausgerollt, welcher ja gleichzeitig der AD ist, als secondary haben wir 8.8.8.8 genommen.
Wir sind ja leider gezwungen für AD den internen DNS zu nutzen. Auflösungen ins Internet laufen problemlos. nslookup auf unseren DNS geht ja auch problemlos.
Gern hätte ich einfach einen pihole dazwischen gesetzt, welcher die DNS Einträge repliziert. Aber das löst ja unser Problem nicht und verkompliziert alles nur. Ich bin mittlerweile der Auffassung, dass das Problem weniger direkt beim DNS liegt, sondern irgendwas in Unifi nicht stimmt bzw. in der Mischung aus Unifi und Synology.
Aber ich weiß nicht mehr, wie ich noch herausfinden kann, wo das Problem liegt ohne unsere Mitarbeiter tagelang arbeitsunfähig zu machen.
Vielleicht hatte jemand schon ähnliches erlebt oder eine Ahnung, die mich vielleicht auf den richtigen Weg bringen kann?
Bei Bedarf kann ich noch Settings beisteuern, wollte nur keine unendlich lange Wall of Text produzieren ;).
leider ist mir kein besserer Titel eingefallen, da das Thema schwer greifbar ist.
Wir kämpfen seit einem Jahr mit der Umstellung von unserer alten Struktur auf die neue. Haben die meisten Baustellen inzwischen abgeschlossen, aber werden immer wieder von irgendwelchen kleinen Problemen geplagt. Eins davon, wo wir echt am Ende mit unserem Latein sind, ist die DNS Auflösung. DNS Probleme haben wir seit beginn der Umstellung immer wieder mal gehabt, aber konnten Sie in den Griff bekommen. Dieses jedoch hält sich zäh.
Jeden morgen sind unsere Kollegen gezwungen "ipconfig /renew" einzugeben, damit der git client via SSH unseren internen Gitlab-Server ansprechen kann. Ansonsten kommt ein "Host could not resolved" Fehler. Interessanterweise lässt sich das Webinterface auf dem gleichen Server problemlos öffnen. Das hält dann immer ca. 24 h, gleiches aus dem Homeoffice via VPN, ob nun Wireguard oder L2TP. Leider bekommen wir nirgends aussagekräftige Logs, weder von Windows, noch vom DNS Package der Synology oder sonstwo auf dem Server.
Meine Vermutung ist, dass in Unifi irgendetwas vermurkst wird, denn die Unifi-Software hat schon öfter uns Ärger gemacht. Eine Mischung aus Bedienfehler, schlechte Beschreibung / Dokumentation und Softwarefehler.
Wireshark hatte ich auch schon im Einsatz via SSH direkt am Router, aber wirklich schlau bin ich daraus auch nicht geworden.
Wir haben seit ewigkeiten update 'domain/IN' denied Fehler wegen invalider TSIG Signatur. Aber diese Warnungen und Fehler hatten wir auch schon beim alten Server, ohne das wir davon irgendetwas im Alltagsgebrauch gespürt hätten.
Zur Struktur:
Wir haben in der Firma ein Netzwerk mit ca. 15 Windows-Clients (Mischbetrieb Win 10 und 11) + fliegende Laptops unendlich viele Wifi-Geräte. Wir nutzen Synology Active Directory mit High Availability auf DSM 7.2. Im Docker auf Synology läuft Gitlab.
Die Netzwerkinfrastruktur besteht aus PYUR Glasfaser Router Alcatel irgendwas, Ubiquiti Dreammachine Pro SE, USW Pro 48, USW Pro 24 alles im Serverraum wunderbar gepatcht.
Dazu haben wir noch eine ältere Synology Diskstation, welche bis zum letzten Jahr den AD stellte und Gitlab über DSM 6. Da ein Update auf DSM 7 nicht ganz unproblematisch war, da diese Diskstation mehr oder weniger der Single Point of Failure war, haben wir gleich alles modernisiert. Die Netzwerkinfrastruktur lief über einen TP Link Archer C7, ein weiterer als Repeater und einem Unifi ( USW Pro 48 ) und war den Ansprüchen ohnehin nicht mehr gewachsen. Da wir einmal Unifi hatten, wollten wir das auch konsuequent erweitern.
Via DHCP wird der DNS ausgerollt, welcher ja gleichzeitig der AD ist, als secondary haben wir 8.8.8.8 genommen.
Wir sind ja leider gezwungen für AD den internen DNS zu nutzen. Auflösungen ins Internet laufen problemlos. nslookup auf unseren DNS geht ja auch problemlos.
Gern hätte ich einfach einen pihole dazwischen gesetzt, welcher die DNS Einträge repliziert. Aber das löst ja unser Problem nicht und verkompliziert alles nur. Ich bin mittlerweile der Auffassung, dass das Problem weniger direkt beim DNS liegt, sondern irgendwas in Unifi nicht stimmt bzw. in der Mischung aus Unifi und Synology.
Aber ich weiß nicht mehr, wie ich noch herausfinden kann, wo das Problem liegt ohne unsere Mitarbeiter tagelang arbeitsunfähig zu machen.
Vielleicht hatte jemand schon ähnliches erlebt oder eine Ahnung, die mich vielleicht auf den richtigen Weg bringen kann?
Bei Bedarf kann ich noch Settings beisteuern, wollte nur keine unendlich lange Wall of Text produzieren ;).
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: 81445165809
Url: https://administrator.de/contentid/81445165809
Ausgedruckt am: 23.11.2024 um 15:11 Uhr
35 Kommentare
Neuester Kommentar
Achja, wenn ich den Eintrag in der hosts datei mache, ist das Problem weg. Aber das kann nicht die Lösung sein.
Moin,
Das ist falsch. Im AD dürfen nur und ausschließlich DNS-Server genutzt werden, die zu diesem AD gehören bzw. die internen Domainteilnehmer auflösen können. Wenn man halt nur einen in der Domain hat, dann gibt es eben keinen zweiten.
hth
Erik
Zitat von @pfcAndre:
Via DHCP wird der DNS ausgerollt, welcher ja gleichzeitig der AD ist, als secondary haben wir 8.8.8.8 genommen.
Via DHCP wird der DNS ausgerollt, welcher ja gleichzeitig der AD ist, als secondary haben wir 8.8.8.8 genommen.
Das ist falsch. Im AD dürfen nur und ausschließlich DNS-Server genutzt werden, die zu diesem AD gehören bzw. die internen Domainteilnehmer auflösen können. Wenn man halt nur einen in der Domain hat, dann gibt es eben keinen zweiten.
hth
Erik
2
und wenn du dann nur auf den internen DNS zeigst (was korrekt ist) - dann auf dem INTERNEN DNS halt nen forwarder einrichten. Dann klappts auch mit der Auflösung... Ob man jetzt da zwingend Google nutzen will ist ne Geschmacksfrage die jeder für sich entscheiden muss... Ich würde halt den provider-dns nehmen - einfach schon weil der eben nicht von jedem eingetragen wird und Google natürlich ein permanentes Ziel von Angriffen ist (und egal wie gut die sind, irgendwann is halt auch mal jemand erfolgreich...)
2
Also ich hab im Router die DHCP Settings:
x.x.x.x für den Synology / DNS / AD Server
als secondary 8.8.8.8, falls der Synology mal ausfallen sollte (was wir ja öfter schon hatten), damit wenigstens Internet funktioniert und alle arbeitsfähig bleiben. Ist das wirklich ein Problem?
Im DNS des Synology haben wir zwei Forwarder
213.187.64.1 DNS vom ISP
8.8.8.8 Google
nur weiterleiten
letzteren könnte man die Forwarder natürlich rausschmeißen und auf den ISP beschränken, aber wir wollten auf Nummer sicher gehen.
x.x.x.x für den Synology / DNS / AD Server
als secondary 8.8.8.8, falls der Synology mal ausfallen sollte (was wir ja öfter schon hatten), damit wenigstens Internet funktioniert und alle arbeitsfähig bleiben. Ist das wirklich ein Problem?
Im DNS des Synology haben wir zwei Forwarder
213.187.64.1 DNS vom ISP
8.8.8.8 Google
nur weiterleiten
letzteren könnte man die Forwarder natürlich rausschmeißen und auf den ISP beschränken, aber wir wollten auf Nummer sicher gehen.
nun das problem bei deinem Setup ist halt: Wenn dein DNS aus welchem Grund auch immer mal zu langsam ragiert wird die Station auf den 2ten DNS wechseln... und ich glaube nicht das Google <deinADServer>.<deineDomain> kennt ... damit wird das dann Spass...
Da du aber ja in sofern keinen richtigen MS-DC betreibst könnte das noch ok sein, bei ner reinen MS-Domäne würde ich das nicht unbedingt machen...
Da du aber ja in sofern keinen richtigen MS-DC betreibst könnte das noch ok sein, bei ner reinen MS-Domäne würde ich das nicht unbedingt machen...
1
Und was spricht dagegen, zur Redundanz einen 2. internen DNS-Server einzurichten?
Mit einem Linux-Samba-Server hättest du auch Redundanz für das AD.
Jürgen
Mit einem Linux-Samba-Server hättest du auch Redundanz für das AD.
Jürgen
1
Hmm, ich werd das mal ausprobieren und berichten ob es erfolgreich war. Danke erst mal für die Ideen und Gedanken 
.
.
Moin,
Ja, das ist wirklich ein Problem. 8.8.8.8 kennt Deine Domain nicht. Wie soll er dann die internen Namen in interne IPs auflösen?
Leider ist das Dokument, das das erklärt hat, bei Microsoft gelöscht. Deshalb aus dem Kopf:
Ein Windows-Client nutzt den ersten Eintrag. Sollte dieser nicht erreichbar sein, wird der zweite Eintrag genutzt. Danach wird weiter der zweite genutzt bis der Rechner neu gestartet wird oder der zweite nicht erreichbar ist. Erreicht also einer Deiner Clients warum auch immer den internen DNS-Server nicht, dann schaltet er auf den Google-DNS um und bleibt dabei. Somit gehen also alle weiteren Abfragen hinsichtlich Deiner Domain schief.
hth
Erik
Zitat von @pfcAndre:
x.x.x.x für den Synology / DNS / AD Server
als secondary 8.8.8.8, falls der Synology mal ausfallen sollte (was wir ja öfter schon hatten), damit wenigstens Internet funktioniert und alle arbeitsfähig bleiben. Ist das wirklich ein Problem?
x.x.x.x für den Synology / DNS / AD Server
als secondary 8.8.8.8, falls der Synology mal ausfallen sollte (was wir ja öfter schon hatten), damit wenigstens Internet funktioniert und alle arbeitsfähig bleiben. Ist das wirklich ein Problem?
Ja, das ist wirklich ein Problem. 8.8.8.8 kennt Deine Domain nicht. Wie soll er dann die internen Namen in interne IPs auflösen?
Leider ist das Dokument, das das erklärt hat, bei Microsoft gelöscht. Deshalb aus dem Kopf:
Ein Windows-Client nutzt den ersten Eintrag. Sollte dieser nicht erreichbar sein, wird der zweite Eintrag genutzt. Danach wird weiter der zweite genutzt bis der Rechner neu gestartet wird oder der zweite nicht erreichbar ist. Erreicht also einer Deiner Clients warum auch immer den internen DNS-Server nicht, dann schaltet er auf den Google-DNS um und bleibt dabei. Somit gehen also alle weiteren Abfragen hinsichtlich Deiner Domain schief.
hth
Erik
1
Ich probiers auch mal. Du hast ein DHCP Problem, sonst würdest du mit jedem Client sofort ein Lease bekommen soviel steht fest. Hast du auf deinem Coreswitch die DHCP Server eingetragen?
Gibts am WLAN/VPN einen extra DHCP Server oder läuft da forwarding?
Ich glaub nicht das es externen secondary dns liegt, da müsste das interne Netz schon ziemlich langsam sein.
Bekommt der Client überhaupt inital eine IP Adresse? falls ja, wie sieht das ergebnis von tracert IP/DnsServer aus?
service dhcp
ip helper-address 192.168.x.4
ip helper-address 192.168.x.15
!
ip dhcp relay information option82Gibts am WLAN/VPN einen extra DHCP Server oder läuft da forwarding?
Ich glaub nicht das es externen secondary dns liegt, da müsste das interne Netz schon ziemlich langsam sein.
Bekommt der Client überhaupt inital eine IP Adresse? falls ja, wie sieht das ergebnis von tracert IP/DnsServer aus?
1
@pfcAndre:
Die lokale hosts-Datei wird noch vor DNS ausgewertet. Deshalb funktioniert das. Aber, wie Du richtig schreibst, ist das nicht die Lösung, wäre mir selbst für nur 3 PCs zu doof.
Viele Grüße
von
departure69
Achja, wenn ich den Eintrag in der hosts datei mache, ist das Problem weg. Aber das kann nicht die Lösung sein.
Die lokale hosts-Datei wird noch vor DNS ausgewertet. Deshalb funktioniert das. Aber, wie Du richtig schreibst, ist das nicht die Lösung, wäre mir selbst für nur 3 PCs zu doof.
Viele Grüße
von
departure69
1
Moin,
weil das hier so durcheinander geht. Der zweite Eintrag des DNS-Servers in der IP-Konfiguration hat nichts mit einem Secondary DNS-Server zu tun. Das ist was vollkommen anderes. Der Secondary DNS-Server ist ein zweiter Server innerhalb einer Domain, der eine Kopie der Zonendatei des Primary DNS-Servers erhält und so beim Ausfall des Primary Auskunft über die Namen und ihre IPs der Zone geben kann.
https://ns1.com/resources/what-exactly-is-secondary-dns
Liebe Grüße
Erik
weil das hier so durcheinander geht. Der zweite Eintrag des DNS-Servers in der IP-Konfiguration hat nichts mit einem Secondary DNS-Server zu tun. Das ist was vollkommen anderes. Der Secondary DNS-Server ist ein zweiter Server innerhalb einer Domain, der eine Kopie der Zonendatei des Primary DNS-Servers erhält und so beim Ausfall des Primary Auskunft über die Namen und ihre IPs der Zone geben kann.
https://ns1.com/resources/what-exactly-is-secondary-dns
Liebe Grüße
Erik
2
Hallo,
fange doch mal strukturiert mit der Fehlersuche an.
mach mal ein ipconfig /all auf einem lokalen Clients und poste das Ergebnis.
dann prüfe und poste mal die Netzwerkeinstellungen, DNS und DHCP Einstellungen von der Synology und der Dreammaschine. Ebenso die AD/SMB Einstellungen auf der Synology.
Wie versucht ihr euch mit dem Git Server zu verbinden ?
git://Servername oder git://servername.domain.xy ?
mach mal vom Client aus ein nslookup Servername und ein nslookup servername.domain.xy und poste das Ergebnis.
Anhand diesen Informationen sollte sich der Fehler eingrenzen und auch hoffentlich beheben lassen.
Gruß
CH
fange doch mal strukturiert mit der Fehlersuche an.
mach mal ein ipconfig /all auf einem lokalen Clients und poste das Ergebnis.
dann prüfe und poste mal die Netzwerkeinstellungen, DNS und DHCP Einstellungen von der Synology und der Dreammaschine. Ebenso die AD/SMB Einstellungen auf der Synology.
Wie versucht ihr euch mit dem Git Server zu verbinden ?
git://Servername oder git://servername.domain.xy ?
mach mal vom Client aus ein nslookup Servername und ein nslookup servername.domain.xy und poste das Ergebnis.
Anhand diesen Informationen sollte sich der Fehler eingrenzen und auch hoffentlich beheben lassen.
Gruß
CH
1
So, hier kommt eine ganze Wand aus Screenshots von Settings und ipconfig.
Interessant ist, dass es nicht jeden Rechner im Netzwerk betrifft. Kollegen sind sowohl im Office als auch Homeoffice betroffen, bei mir weder noch.
Wir verbinden uns via ssh://git@git.pfc.office.
Nur nochmal zur Klarstellung. Wir haben keinerlei DHCP Probleme. Die DNS Auflösung gelingt grundsätzlich. Das einzige Phänomen ist: Einige Rechner können git.pfc.office nicht auflösen (manchmal auch nicht im browser) ehe sie Ipconfig /renew machen oder sie nach dem ersten versuch nochmal probieren bzw. eine gewisse Zeit warten. Das Verhalten scheint aber nicht konsistent zu sein.
Die Geschichte hält dann bis zum nächsten Neustart.
BTW: das entfernen von 8.8.8.8 als "zweiten" DNS im Router hat nichts gebracht.
Interessant ist, dass es nicht jeden Rechner im Netzwerk betrifft. Kollegen sind sowohl im Office als auch Homeoffice betroffen, bei mir weder noch.
Wir verbinden uns via ssh://git@git.pfc.office.
Nur nochmal zur Klarstellung. Wir haben keinerlei DHCP Probleme. Die DNS Auflösung gelingt grundsätzlich. Das einzige Phänomen ist: Einige Rechner können git.pfc.office nicht auflösen (manchmal auch nicht im browser) ehe sie Ipconfig /renew machen oder sie nach dem ersten versuch nochmal probieren bzw. eine gewisse Zeit warten. Das Verhalten scheint aber nicht konsistent zu sein.
Die Geschichte hält dann bis zum nächsten Neustart.
BTW: das entfernen von 8.8.8.8 als "zweiten" DNS im Router hat nichts gebracht.
Moin,
ich sehe da immer noch den Google-Server als zweiten DNS. Den sollst Du auch nicht aus dem Router entfernen, sondern aus der DHCP-Konfiguration. Da steht er noch drin, wie Dein IPCONFIG zeigt. Das ist schlicht falsch in einer Domain.
Liebe Grüße
Erik
ich sehe da immer noch den Google-Server als zweiten DNS. Den sollst Du auch nicht aus dem Router entfernen, sondern aus der DHCP-Konfiguration. Da steht er noch drin, wie Dein IPCONFIG zeigt. Das ist schlicht falsch in einer Domain.
Liebe Grüße
Erik
1
Du schreibst:
Via DHCP wird der DNS ausgerollt, welcher ja gleichzeitig der AD ist, als secondary haben wir 8.8.8.8 genommen.
Wenn der Client also mal den 1. DNS, also dein AD, nicht erreicht dann wechselt er zu Google.
Und du erwartest dass Google deine bei dir intern gehostete Domäne auflöst?
Das kann funktioniert nicht.
Hör auf Erik. Im DHCP dürfen nur interne DNS Server stehen.
Die DNS Server im Router sollen dann alles was die nicht auflösen können ins Internet (8.8.8.8, 1.1.1.1...) weiterleiten zum auflösen. Also ist da die config korrekt.
Wenn über dem VPN der DHCP die gleichen DNS Server mitgegeben werden wie intern dann liegt das Problem 100 Prozentig daran.
Weil:
Host Datei ändern = funktioniert
Normale Auflösung = nach Lust und Laune
Host Datei wird lokal auf dem Client ausgewertet. Also vor der typischen DNS Auflösung.
Da du das Problem nur mit deinem vom DHCP mitgegebenen DNS Servern hast liegt das Problem hier.
Und etwas wichtiges noch:
Ist ja gut dass du auf deinem DHCP Server nur noch den lokalen DNS angibst. Aber dann bitte auch ein renew am client damit er auch die neuen DNS Einträge mitbekommt
Oder habt ihr zwei DHCPs für die gleiche Netzadresse?
Nachtrag:
Außerdem betrifft das Problem nur sporadisch die Clients weil der eine Client mal deinen AD nutzt zur Auflösung und der andere Google.
Bei der internen Auflösung klappts, bei der externen, also Google, nicht.
Zusätzlich noch:
Wenn dein Router SPLIT-DNS kann dann werden nur die DNS Anfragen von deiner Domäne verarbeitet. Der Rest geht dann über den Router in das Internet. Kannst dich da ja mal schlau machen.
In diesem Fall wäre dann Dein Router der DNS. Der leitet dann gemäß policies die DNS requests weiter zu Google oder zu deinem AD.
Und wenn der Router ausfällt ist alles tot. Passt doch 👍
Vg
Via DHCP wird der DNS ausgerollt, welcher ja gleichzeitig der AD ist, als secondary haben wir 8.8.8.8 genommen.
Wenn der Client also mal den 1. DNS, also dein AD, nicht erreicht dann wechselt er zu Google.
Und du erwartest dass Google deine bei dir intern gehostete Domäne auflöst?
Das kann funktioniert nicht.
Hör auf Erik. Im DHCP dürfen nur interne DNS Server stehen.
Die DNS Server im Router sollen dann alles was die nicht auflösen können ins Internet (8.8.8.8, 1.1.1.1...) weiterleiten zum auflösen. Also ist da die config korrekt.
Wenn über dem VPN der DHCP die gleichen DNS Server mitgegeben werden wie intern dann liegt das Problem 100 Prozentig daran.
Weil:
Host Datei ändern = funktioniert
Normale Auflösung = nach Lust und Laune
Host Datei wird lokal auf dem Client ausgewertet. Also vor der typischen DNS Auflösung.
Da du das Problem nur mit deinem vom DHCP mitgegebenen DNS Servern hast liegt das Problem hier.
Und etwas wichtiges noch:
Ist ja gut dass du auf deinem DHCP Server nur noch den lokalen DNS angibst. Aber dann bitte auch ein renew am client damit er auch die neuen DNS Einträge mitbekommt
Oder habt ihr zwei DHCPs für die gleiche Netzadresse?
Nachtrag:
Außerdem betrifft das Problem nur sporadisch die Clients weil der eine Client mal deinen AD nutzt zur Auflösung und der andere Google.
Bei der internen Auflösung klappts, bei der externen, also Google, nicht.
Zusätzlich noch:
Wenn dein Router SPLIT-DNS kann dann werden nur die DNS Anfragen von deiner Domäne verarbeitet. Der Rest geht dann über den Router in das Internet. Kannst dich da ja mal schlau machen.
In diesem Fall wäre dann Dein Router der DNS. Der leitet dann gemäß policies die DNS requests weiter zu Google oder zu deinem AD.
Und wenn der Router ausfällt ist alles tot. Passt doch 👍
Vg
1
Hallo pfcAndre,
vielleicht hilft Dir meine Konfiguration:
Im Einsatz hab ich 2 Synology Boxen. Beide können mit dem Containermanager/Docker umgehen.
Eine davon ist als "Master" unterwegs. Die andere dann eher als "Slave". Einfach eine Definitionsfrage.
Für den DHCP nutze ich auf einer der Boxen den eingebauten DHCP Service.
Auf beiden Boxen nutze ich den Synology DNS Service. Die Master Box hostet dabei die Master Zonen. Auf der Slave Box entsprechend die Slave Zonen.
Per DHCP werden die IPs der Synology Boxen als DNS Server verteilt. Die Box 1 als primärer DNS Server und die Box 2 als sekundärer DNS Server.
Wie schon angesprochen, beide Boxen können mit Containern umgehen. Daher läuft auf jeder Box ein Pihole Container mit eigener IP.
Die Konfiguration des DNS Server sieht nun vor, daß als Forwarder der Box 1 der Pihole Container der Box 1 eingetragen ist. Analog dazu bei der Box 2 der Pihole Container der Box 2.
Im Pihole ist als Forwarder der Quad9 eingetragen.
Was bringt mir das jetzt?
So kann ich sicherstellen, einen internen redundanten DNS Service zu haben, der Anfragen zusätzlich gegen den Pihole filtert und die vorgefilterten DNS Server von Quad9 nutzt.
Die Pihole Konfiguration muß man auch nur einmal machen und kann diese dann speichern und übertragen.
VG
vielleicht hilft Dir meine Konfiguration:
Im Einsatz hab ich 2 Synology Boxen. Beide können mit dem Containermanager/Docker umgehen.
Eine davon ist als "Master" unterwegs. Die andere dann eher als "Slave". Einfach eine Definitionsfrage.
Für den DHCP nutze ich auf einer der Boxen den eingebauten DHCP Service.
Auf beiden Boxen nutze ich den Synology DNS Service. Die Master Box hostet dabei die Master Zonen. Auf der Slave Box entsprechend die Slave Zonen.
Per DHCP werden die IPs der Synology Boxen als DNS Server verteilt. Die Box 1 als primärer DNS Server und die Box 2 als sekundärer DNS Server.
Wie schon angesprochen, beide Boxen können mit Containern umgehen. Daher läuft auf jeder Box ein Pihole Container mit eigener IP.
Die Konfiguration des DNS Server sieht nun vor, daß als Forwarder der Box 1 der Pihole Container der Box 1 eingetragen ist. Analog dazu bei der Box 2 der Pihole Container der Box 2.
Im Pihole ist als Forwarder der Quad9 eingetragen.
Was bringt mir das jetzt?
So kann ich sicherstellen, einen internen redundanten DNS Service zu haben, der Anfragen zusätzlich gegen den Pihole filtert und die vorgefilterten DNS Server von Quad9 nutzt.
Die Pihole Konfiguration muß man auch nur einmal machen und kann diese dann speichern und übertragen.
VG
1
Hallo Allerseits,
vielen dank für die ganzen Vorschläge und Ideen. Ich habe jetzt das Problem, so denke ich, gelöst bekommen.
Tatsächlich gab es unter Unifi Settings -> WAN auch nochmal DNS Einstellungen. Dort waren die Provider DNS Einträge drin. Da hab ich jetzt alles auf unseren internen DNS umgestellt und voila. Es scheint zu gehen und selbst die Seiten scheinen nun schneller zu laden.
Also das hartnäckige Verfolgen redundanter Einträge hat wirklich was gebracht. Danke nochmal für das darauf beharren
Allerdings erschließt sich mir nicht wirklich in welcher Priorisierung und Reihenfolge DNS-Einträge Gültigkeit besitzen. Wenn ein DHCP DNS Server zuweist und in ipconfig der DNS vorgegeben ist, warum scheint er trotzdem die Einträge unter WAN zu verwenden? Das ergibt für mich keinen Sinn. Muss ja so sein, sonst dürfte sich jetzt ja keine Änderung eingestellt haben.
Hat zufällig jemand tieferes Verständnis wie Unifi arbeitet?
@Netzwerkunwissender1: Spannendes Setup. Wir haben ja bereits 2x RS1221+ im Einsatz im High Availability Betrieb. Theoretisch sollte das eine gewisse Redundanz bieten. Allerdings hatten wir letztens das Problem, das aufgrund eines Konfigurationsfehlers des Switch uns die Link Aggregation und damit der Passive Server weggestorben ist, welchen wir resetten mussten. Dann war unser HA Setup massiv ausgelastet durch High Availability Sync und Datenintegritätsprüfung und darunter litt zusätzlich noch die DNS Auflösung, welche wiederum durch unser offensichtlich fehlerhaftes Setup noch getrübt war.
Aus dem Grund habe ich auch erwogen, einen NUC oder sowas als Pihole dazwischen zu schalten, wurde aber vom Chef mit der Begründung "zuviel Komplexität" abgelehnt :D.
vielen dank für die ganzen Vorschläge und Ideen. Ich habe jetzt das Problem, so denke ich, gelöst bekommen.
Tatsächlich gab es unter Unifi Settings -> WAN auch nochmal DNS Einstellungen. Dort waren die Provider DNS Einträge drin. Da hab ich jetzt alles auf unseren internen DNS umgestellt und voila. Es scheint zu gehen und selbst die Seiten scheinen nun schneller zu laden.
Also das hartnäckige Verfolgen redundanter Einträge hat wirklich was gebracht. Danke nochmal für das darauf beharren
Allerdings erschließt sich mir nicht wirklich in welcher Priorisierung und Reihenfolge DNS-Einträge Gültigkeit besitzen. Wenn ein DHCP DNS Server zuweist und in ipconfig der DNS vorgegeben ist, warum scheint er trotzdem die Einträge unter WAN zu verwenden? Das ergibt für mich keinen Sinn. Muss ja so sein, sonst dürfte sich jetzt ja keine Änderung eingestellt haben.
Hat zufällig jemand tieferes Verständnis wie Unifi arbeitet?
@Netzwerkunwissender1: Spannendes Setup. Wir haben ja bereits 2x RS1221+ im Einsatz im High Availability Betrieb. Theoretisch sollte das eine gewisse Redundanz bieten. Allerdings hatten wir letztens das Problem, das aufgrund eines Konfigurationsfehlers des Switch uns die Link Aggregation und damit der Passive Server weggestorben ist, welchen wir resetten mussten. Dann war unser HA Setup massiv ausgelastet durch High Availability Sync und Datenintegritätsprüfung und darunter litt zusätzlich noch die DNS Auflösung, welche wiederum durch unser offensichtlich fehlerhaftes Setup noch getrübt war.
Aus dem Grund habe ich auch erwogen, einen NUC oder sowas als Pihole dazwischen zu schalten, wurde aber vom Chef mit der Begründung "zuviel Komplexität" abgelehnt :D.
Hallo pfcAndre,
schön daß Du eine Lösung gefunden hast.
Die Kombination mit den 2 DNS Servern hab ich auch erst, nachdem mir durch 3, recht kurz hintereinander stattgefundene Stromausfällen, die eine Box mit dem damals einzigen DNS, über Stunden hinweg im Recovery Modus geblieben ist und ein Arbeiten so nicht wirklich möglich war.
Ich spreche hier von einer Installation zuhause, um das entsprechend einordnen zu können.
Vielleicht wäre es eine Überlegung wert, die DNS/DHCP Dienste von den Synology Systemen zu nehmen und dafür auf kleine Raspis (oder irgendwas Vergleichbares oder Kleines) zu verlagern. Das mag zwar die Komplexität erhöhen. Wenn die Systeme jedoch mal wieder in eine Datenintegritätsprüfung laufen, wird man sich jedoch über einen funktionierenden DNS freuen.
Da muß man halt wissen, wie viel Schmerzen man gewillt ist zu ertragen. Chefes muß man nicht verstehen. Man kann nur Vorschläge machen. Werden die abgelehnt, ist das halt so Dann lehnt man sich zurück und schaut sich das Drama an. Dran ändern kann man dann eh grad nichts...
VG
schön daß Du eine Lösung gefunden hast.
Die Kombination mit den 2 DNS Servern hab ich auch erst, nachdem mir durch 3, recht kurz hintereinander stattgefundene Stromausfällen, die eine Box mit dem damals einzigen DNS, über Stunden hinweg im Recovery Modus geblieben ist und ein Arbeiten so nicht wirklich möglich war.
Ich spreche hier von einer Installation zuhause, um das entsprechend einordnen zu können.
Vielleicht wäre es eine Überlegung wert, die DNS/DHCP Dienste von den Synology Systemen zu nehmen und dafür auf kleine Raspis (oder irgendwas Vergleichbares oder Kleines) zu verlagern. Das mag zwar die Komplexität erhöhen. Wenn die Systeme jedoch mal wieder in eine Datenintegritätsprüfung laufen, wird man sich jedoch über einen funktionierenden DNS freuen.
Da muß man halt wissen, wie viel Schmerzen man gewillt ist zu ertragen. Chefes muß man nicht verstehen. Man kann nur Vorschläge machen. Werden die abgelehnt, ist das halt so
Dann lehnt man sich zurück und schaut sich das Drama an. Dran ändern kann man dann eh grad nichts...VG
Moin,
Den DHCP in der Unifi ist aber schon ausgeschaltet, oder?
Liebe Grüße
Erik
Zitat von @pfcAndre:
Allerdings erschließt sich mir nicht wirklich in welcher Priorisierung und Reihenfolge DNS-Einträge Gültigkeit besitzen. Wenn ein DHCP DNS Server zuweist und in ipconfig der DNS vorgegeben ist, warum scheint er trotzdem die Einträge unter WAN zu verwenden? Das ergibt für mich keinen Sinn. Muss ja so sein, sonst dürfte sich jetzt ja keine Änderung eingestellt haben.
Allerdings erschließt sich mir nicht wirklich in welcher Priorisierung und Reihenfolge DNS-Einträge Gültigkeit besitzen. Wenn ein DHCP DNS Server zuweist und in ipconfig der DNS vorgegeben ist, warum scheint er trotzdem die Einträge unter WAN zu verwenden? Das ergibt für mich keinen Sinn. Muss ja so sein, sonst dürfte sich jetzt ja keine Änderung eingestellt haben.
Den DHCP in der Unifi ist aber schon ausgeschaltet, oder?
Liebe Grüße
Erik
DHCP ist an. Die unifi macht doch die DHCP verteilung.
Das ist zwar nicht falsch, aber eher ungewöhnlich. Lass das auch den DC machen und schalte den im unifi ab. Das ist eher die allgemeine Praxis.
Er hat doch keinen "richtigen" DC, das macht doch sein NAS.
Jürgen
Jürgen
Und? Der Linux-Server kann auch DHCP.
Nene, also noch mehr Single Point of Failure will ich nicht bauen. Wozu haben wir die ganze teure Netzwerktechnik, wenn wir sie nicht nutzen. Schon der DNS stört mich auf der Synology, aber wegen AD leider unumgänglich. Am liebsten würden wir auf AD verzichten, weil man damit nur Ärger hat .
.
Uff - sorry - dann möchte ich mal dagegen halten: Was macht man mit der ganzen teuren Netzwerktechnik wenn man damit nicht umgehen kann? Ich kaufe mir auch kein Profi-Messerset wenns grad mal reicht um ne Scheibe Brot zu schmieren...
Und "man" hat nur Ärger mit AD? Deshalb hat es sich also (auch zu meinem Leidwesen) im Firmen-Umfeld so durchgesetzt?
Sorry, aber so wie ich das sehe habt ihr genau einen single Point of failure... Denn wenn du die Protokolle nicht verstehst dann sitzt der leider VOR der Tastatur. Wenn du zB. nen DHCP nimmst und mal mittem Tag neu startest passiert... genau gar nix, wenn nicht grad in dem Moment nen Lease abgelaufen ist...
Von daher - ganz ehrlich, es mag ja sein das du es gerne lustig mischen willst -> was aber einfach mal so gar keinen Sinn macht. Denn du hast am Ende dann nur eine _vielzahl_ von Single Point of Failures gebaut. Wenn dir dein ganzes AD abraucht, deine Syno fröhlich das Lied vom Tod piepst - was bringt es dir nen DHCP zu haben wenn du auf keine Daten zugreifen kannst,... Umgekehrt: Was bringt es dir in deinem Setup wenn die Syno zwar super läuft - dein DHCP aber sich verabschiedet hat (da die Rechner beim Starten natürlich ne IP ziehen wollen). Dann hast du zwar dein AD aber kommst immer noch nicht ran... Du hast also - sofern du keine Vorkehrungen triffst - grade die Ausfallwahrscheinlichkeit deines Systems sogar verdoppelt. Herzlichen Glückwunsch dazu!
Und "man" hat nur Ärger mit AD? Deshalb hat es sich also (auch zu meinem Leidwesen) im Firmen-Umfeld so durchgesetzt?
Sorry, aber so wie ich das sehe habt ihr genau einen single Point of failure... Denn wenn du die Protokolle nicht verstehst dann sitzt der leider VOR der Tastatur. Wenn du zB. nen DHCP nimmst und mal mittem Tag neu startest passiert... genau gar nix, wenn nicht grad in dem Moment nen Lease abgelaufen ist...
Von daher - ganz ehrlich, es mag ja sein das du es gerne lustig mischen willst -> was aber einfach mal so gar keinen Sinn macht. Denn du hast am Ende dann nur eine _vielzahl_ von Single Point of Failures gebaut. Wenn dir dein ganzes AD abraucht, deine Syno fröhlich das Lied vom Tod piepst - was bringt es dir nen DHCP zu haben wenn du auf keine Daten zugreifen kannst,... Umgekehrt: Was bringt es dir in deinem Setup wenn die Syno zwar super läuft - dein DHCP aber sich verabschiedet hat (da die Rechner beim Starten natürlich ne IP ziehen wollen). Dann hast du zwar dein AD aber kommst immer noch nicht ran... Du hast also - sofern du keine Vorkehrungen triffst - grade die Ausfallwahrscheinlichkeit deines Systems sogar verdoppelt. Herzlichen Glückwunsch dazu!
Hallo,
ich kann @maretz nur zustimmen. Ein Verzeichnisdienst ist die zentrale Verwaltungsstelle für User, Ressourcen, Services und die Rechte darauf. In einem modernen, komplexen Netzwerk unverzichtbar. Ob nun M$ AD oder LDAP oder etwas anderes (ich nutze immer noch das eDirectory und bin zufrieden), ist dabei egal. Es muss redundant und fehlersicher aufgebaut sein UND man muss es administrieren können!!
Ich habe 4 redundante DNS-Server und 2 DHCP-Server. Ich kann also jeden der Server updaten, rebooten oder was auch immer, ohne das mein Netz rot anläuft.
Das ist doch kein Hexenwerk!
Jürgen
ich kann @maretz nur zustimmen. Ein Verzeichnisdienst ist die zentrale Verwaltungsstelle für User, Ressourcen, Services und die Rechte darauf. In einem modernen, komplexen Netzwerk unverzichtbar. Ob nun M$ AD oder LDAP oder etwas anderes (ich nutze immer noch das eDirectory und bin zufrieden), ist dabei egal. Es muss redundant und fehlersicher aufgebaut sein UND man muss es administrieren können!!
Ich habe 4 redundante DNS-Server und 2 DHCP-Server. Ich kann also jeden der Server updaten, rebooten oder was auch immer, ohne das mein Netz rot anläuft.
Das ist doch kein Hexenwerk!
Jürgen
Moin,
Tust Du so aber.
Wo habt Ihr teure Netzwerktechnik? Unifi und Synology ist die Billigvariante.
Das ist der falsche Ansatz. Nutze die Werkzeuge, wofür sie gedacht sind. Router sind keine DHCP-Server. Im privaten Netz ist das ganz nett, wenn der Router das auch übernimmt. Im Firmennetz ist das allerdings mehr als suboptimal,
Du kannst auch den DNS auf einem anderen Server laufen lassen. Kein Problem. Man muss es halt nur richtig machen.
Was meinst Du, wieviel Ärger Du hättest, wenn kein AD vorhanden wäre. AD ist eine großartige Erfindung. Ich kenne noch die Zeiten, in denen es das nicht gab. AD ist einfach und übersichtlich, wenn man es kann.
Liebe Grüße
Erik
Tust Du so aber.
Wozu haben wir die ganze teure Netzwerktechnik,
Wo habt Ihr teure Netzwerktechnik? Unifi und Synology ist die Billigvariante.
wenn wir sie nicht nutzen.
Das ist der falsche Ansatz. Nutze die Werkzeuge, wofür sie gedacht sind. Router sind keine DHCP-Server. Im privaten Netz ist das ganz nett, wenn der Router das auch übernimmt. Im Firmennetz ist das allerdings mehr als suboptimal,
Schon der DNS stört mich auf der Synology, aber wegen AD leider unumgänglich.
Du kannst auch den DNS auf einem anderen Server laufen lassen. Kein Problem. Man muss es halt nur richtig machen.
Am liebsten würden wir auf AD verzichten, weil man damit nur Ärger hat .
.Was meinst Du, wieviel Ärger Du hättest, wenn kein AD vorhanden wäre. AD ist eine großartige Erfindung. Ich kenne noch die Zeiten, in denen es das nicht gab. AD ist einfach und übersichtlich, wenn man es kann.
Liebe Grüße
Erik
Also, das geht grad weit am Thema vorbei und ist auch recht übergriffig. Weil irgendwelche Settings nicht richtig logisch sind, ist man doch nicht gleich inkompetent Ihr kennt doch unsere spezifischen Anforderungen gar nicht.
Man kann sich nicht mit jedem Detail bestens auskennen. Vor allem wenn man nicht täglich damit zu tun hat. Unser Konzept ist, dass unsere IT so leichtgewichtig wie möglich ist, damit diese von uns administrierbar bleibt. Es ändert sich ja ständig etwas.
Wir sind knapp 15 Entwickler, die alle Adminrechte benötigen und täglich unsere Systeme zubasteln. Wir müssen flexibel sein, Dinge wegzuwerfen und neues aufzubauen. Das ist etwas anderes als ein Büro, wo 50 Leute nur Word und Excel auf und zu machen, und der Schrecken ausbricht, wenn das Netzlaufwerk weg ist.
Sonst würden wir nicht Synology und Ubiquiti benutzen, sondern irgendein Systemhaus würde 10x so teuren Enterprise-Kram betreuen, der selbst für uns paar Entwickler völlig überdimensioniert wäre.
Warum soll ich denn jetzt den DHCP auf unser NAS umziehen und den Dienst in der Dreammachine abschalten? Welchen Vorteil habe ich davon? Das ist doch auf dem Router 10x besser aufgehoben. Ich kann natürlich auch das NAS zum Router machen... ich kann da auch ne OpenSense in einer VM betreiben und darüber laufen lassen, IPS und IDS kann die ja auch gleich übernehmen...
Mir ist schon klar, dass ich alles auf einem Linux machen kann, aber nicht alles was man machen kann ist auch sinnvoll.
Wir haben Netzwerkgeräte, die sollen Netzwerk machen. Unser NAS hat eigentlich nur die Aufgabe als Storage zu dienen, Gitlab zu hosten und den Verzeichnisdienst bereitzustellen, weil für uns ein dedizierter Windows Server overkill ist.
Das AD wurde vor meiner Betriebszugehörigkeit eingerichtet, Authentifizierung, Profildienst und Software-Rollout war der Grund dafür. Leider ist die Technik vernachlässigt worden und ich hab mich dafür eingesetzt, da grundsätzlich mehr Redundanz und Absicherung reinzubringen (Snapshot Replication , HA etc.).
Eigentlich brauchen wir die Domäne nicht wirklich. Denn unsere Haupttools müssen wir sowieso händisch installieren. Es geht eher um Authentifizierung / LDAP, Komfort um Standardsachen nicht jedes mal neu einrichten zu müssen (slack, keepass, Netzlaufwerk, etc.). Ein reiner LDAP wäre theoretisch ausreichend. Man bräuchte nur für den Rest eine konsistente Lösung, Projektdateien sind sowieso zu groß zum syncen über Domäne.
AD von Synology (was ja am Ende ein modifiziertes Samba ist), ist leider nicht ganz unproblematisch. Viele GPOs funktionieren seit DSM 7 nicht mehr richtig. Das ist mit Windows Server sicherlich weniger problematisch. Ich sage ja nicht, das AD generell Mist ist, sondern bei UNS bzw. Synology Mist ist.
Unser Problem ist, dass sich Dinge nicht so verhalten, wie sie beschrieben sind / nicht logisch und schwer zu unterscheiden ist, wo das Problem liegt, ist es die Implementierung von Synology, funkt Ubiquiti dazwischen oder ist es ein Konfigurationsfehler, aufgrund schlechter Dokumentation. Wir haben stellenweise Windows 10 Installationen, die machen manchmal Probleme, weil sie so alt sind (verhalten sich klar anders als neuere bzw. Win 11 Installationen -> self signed Zertifikate mit Git zum Bleistift).
Aber eine Neuinstallation zeitlich schwer durchführbar ist... das wird dann halt vertagt.
Wir arbeiten ohnehin hybrid. Wenn unser Server stirbt, ist das für 1-2 Tage verschmerzbar. Wir können lokal und mit Internet problemlos vorübergehend weiter arbeiten, solange Internet geht. Wenn das Internet fehlt ist es schon mal viel schlimmer. Wir können aber aufgrund der Datenmengen und bestimmter kundenseitiger Vorgaben aber nicht alles im Netz machen. Aus diesem Grund ist die Priorität Internet viel größer, als die Erreichbarkeit unseres lokalen Servers.
Ihr seht, bei uns läuft es ganz anders als in einem 0815-Büro. Unsere Ansprüche und Anforderungen sind auch ganz anders und deswegen muss das Netzwerk auch ohne Server laufen können.
Man kann sich nicht mit jedem Detail bestens auskennen. Vor allem wenn man nicht täglich damit zu tun hat. Unser Konzept ist, dass unsere IT so leichtgewichtig wie möglich ist, damit diese von uns administrierbar bleibt. Es ändert sich ja ständig etwas.
Wir sind knapp 15 Entwickler, die alle Adminrechte benötigen und täglich unsere Systeme zubasteln. Wir müssen flexibel sein, Dinge wegzuwerfen und neues aufzubauen. Das ist etwas anderes als ein Büro, wo 50 Leute nur Word und Excel auf und zu machen, und der Schrecken ausbricht, wenn das Netzlaufwerk weg ist.
Sonst würden wir nicht Synology und Ubiquiti benutzen, sondern irgendein Systemhaus würde 10x so teuren Enterprise-Kram betreuen, der selbst für uns paar Entwickler völlig überdimensioniert wäre.
Warum soll ich denn jetzt den DHCP auf unser NAS umziehen und den Dienst in der Dreammachine abschalten? Welchen Vorteil habe ich davon? Das ist doch auf dem Router 10x besser aufgehoben. Ich kann natürlich auch das NAS zum Router machen... ich kann da auch ne OpenSense in einer VM betreiben und darüber laufen lassen, IPS und IDS kann die ja auch gleich übernehmen...
Mir ist schon klar, dass ich alles auf einem Linux machen kann, aber nicht alles was man machen kann ist auch sinnvoll.
Wir haben Netzwerkgeräte, die sollen Netzwerk machen. Unser NAS hat eigentlich nur die Aufgabe als Storage zu dienen, Gitlab zu hosten und den Verzeichnisdienst bereitzustellen, weil für uns ein dedizierter Windows Server overkill ist.
Das AD wurde vor meiner Betriebszugehörigkeit eingerichtet, Authentifizierung, Profildienst und Software-Rollout war der Grund dafür. Leider ist die Technik vernachlässigt worden und ich hab mich dafür eingesetzt, da grundsätzlich mehr Redundanz und Absicherung reinzubringen (Snapshot Replication , HA etc.).
Eigentlich brauchen wir die Domäne nicht wirklich. Denn unsere Haupttools müssen wir sowieso händisch installieren. Es geht eher um Authentifizierung / LDAP, Komfort um Standardsachen nicht jedes mal neu einrichten zu müssen (slack, keepass, Netzlaufwerk, etc.). Ein reiner LDAP wäre theoretisch ausreichend. Man bräuchte nur für den Rest eine konsistente Lösung, Projektdateien sind sowieso zu groß zum syncen über Domäne.
AD von Synology (was ja am Ende ein modifiziertes Samba ist), ist leider nicht ganz unproblematisch. Viele GPOs funktionieren seit DSM 7 nicht mehr richtig. Das ist mit Windows Server sicherlich weniger problematisch. Ich sage ja nicht, das AD generell Mist ist, sondern bei UNS bzw. Synology Mist ist.
Unser Problem ist, dass sich Dinge nicht so verhalten, wie sie beschrieben sind / nicht logisch und schwer zu unterscheiden ist, wo das Problem liegt, ist es die Implementierung von Synology, funkt Ubiquiti dazwischen oder ist es ein Konfigurationsfehler, aufgrund schlechter Dokumentation. Wir haben stellenweise Windows 10 Installationen, die machen manchmal Probleme, weil sie so alt sind (verhalten sich klar anders als neuere bzw. Win 11 Installationen -> self signed Zertifikate mit Git zum Bleistift).
Aber eine Neuinstallation zeitlich schwer durchführbar ist... das wird dann halt vertagt.
Wir arbeiten ohnehin hybrid. Wenn unser Server stirbt, ist das für 1-2 Tage verschmerzbar. Wir können lokal und mit Internet problemlos vorübergehend weiter arbeiten, solange Internet geht. Wenn das Internet fehlt ist es schon mal viel schlimmer. Wir können aber aufgrund der Datenmengen und bestimmter kundenseitiger Vorgaben aber nicht alles im Netz machen. Aus diesem Grund ist die Priorität Internet viel größer, als die Erreichbarkeit unseres lokalen Servers.
Ihr seht, bei uns läuft es ganz anders als in einem 0815-Büro. Unsere Ansprüche und Anforderungen sind auch ganz anders und deswegen muss das Netzwerk auch ohne Server laufen können.
Zitat von @pfcAndre:
Also, das geht grad weit am Thema vorbei und ist auch recht übergriffig. Weil irgendwelche Settings nicht richtig logisch sind, ist man doch nicht gleich inkompetent Ihr kennt doch unsere spezifischen Anforderungen gar nicht.
Also, das geht grad weit am Thema vorbei und ist auch recht übergriffig. Weil irgendwelche Settings nicht richtig logisch sind, ist man doch nicht gleich inkompetent Ihr kennt doch unsere spezifischen Anforderungen gar nicht.
Ok, ich habe verstanden. Du gehörst zu denen, die jeden Rat, der dem widerspricht, was man selbst meint, ablehnt. Ist in Ordnung. Aber dann werde zumindest ich mir auch keine Mühe mehr geben, Dir zu helfen. PLONK
Zitat von @erikro:
Ok, ich habe verstanden. Du gehörst zu denen, die jeden Rat, der dem widerspricht, was man selbst meint, ablehnt. Ist in Ordnung. Aber dann werde zumindest ich mir auch keine Mühe mehr geben, Dir zu helfen. PLONK
Ok, ich habe verstanden. Du gehörst zu denen, die jeden Rat, der dem widerspricht, was man selbst meint, ablehnt. Ist in Ordnung. Aber dann werde zumindest ich mir auch keine Mühe mehr geben, Dir zu helfen. PLONK
Sorry, ich hab es vielleicht etwas übertrieben. Du solltest dich davon nicht angesprochen fühlen. Das ging eher an Maretz. Sowas regt mich immer auf, impliziert es doch inkompetenz ohne Kenntnisse der genauen Umstände zu haben.
"Uff - sorry - dann möchte ich mal dagegen halten: Was macht man mit der ganzen teuren Netzwerktechnik wenn man damit nicht umgehen kann? Ich kaufe mir auch kein Profi-Messerset wenns grad mal reicht um ne Scheibe Brot zu schmieren..."
"Denn wenn du die Protokolle nicht verstehst dann sitzt der leider VOR der Tastatur."
Verstehe ich nicht, wenn DNS und DHCP auch noch auf dem Server laufen, liegt doch das Risiko ausschließlich auf dem Server?
Wozu haben wir die ganze teure Netzwerktechnik,
Wo habt Ihr teure Netzwerktechnik? Unifi und Synology ist die Billigvariante.
Dass weiß ich doch. Aber für unsere Ansprüche doch völlig ok. Vorher hatten wir TP-Link Archer und eine alte DS15xx.
wenn wir sie nicht nutzen.
Das ist der falsche Ansatz. Nutze die Werkzeuge, wofür sie gedacht sind. Router sind keine DHCP-Server. Im privaten Netz ist das ganz nett, wenn der Router das auch übernimmt. Im Firmennetz ist das allerdings mehr als suboptimal,
Schon der DNS stört mich auf der Synology, aber wegen AD leider unumgänglich.
Du kannst auch den DNS auf einem anderen Server laufen lassen. Kein Problem. Man muss es halt nur richtig machen.
Am liebsten würden wir auf AD verzichten, weil man damit nur Ärger hat .
.Was meinst Du, wieviel Ärger Du hättest, wenn kein AD vorhanden wäre. AD ist eine großartige Erfindung. Ich kenne noch die Zeiten, in denen es das nicht gab. AD ist einfach und übersichtlich, wenn man es kann.
Das mag grundsätzlich so sein. Aber zumindest die Synology Implementierung scheint problematisch zu sein bzw. ist mir nicht klar was wir falsch machen, denn vorher ging es ja halbwegs gut vor dem Update. Aber das ist ein eigenes Thema. Vieles was AD bietet, benötigen wir eigentlich nicht zwingend.
Viele Grüße,
André
Um das ganze nicht ausufern zu lassen. Ich habe es vielleicht persönlicher aufgefasst, als es gemeint war. Nochmal sorry an alle.
Ist genau der Punkt um dem es am Ende geht. Deswegen haben wir Ubiquiti gewählt und setzen weiterhin auf Synology.
Mir ist schon klar, dass das kein Profi Equipement ist, aber das kann man auch nicht mehr "einfach" administrieren. Habe zuhause ein OpnSense zum rumbasteln und da merkt man schon schnell den Unterschied, obwohl das noch halbwegs übersichtlich ist (hab vor 100 Jahren mal einen CCNA gemacht).
UND man muss es administrieren können
Ist genau der Punkt um dem es am Ende geht. Deswegen haben wir Ubiquiti gewählt und setzen weiterhin auf Synology.
Mir ist schon klar, dass das kein Profi Equipement ist, aber das kann man auch nicht mehr "einfach" administrieren. Habe zuhause ein OpnSense zum rumbasteln und da merkt man schon schnell den Unterschied, obwohl das noch halbwegs übersichtlich ist (hab vor 100 Jahren mal einen CCNA gemacht).
Nun - das Problem ist doch das du eben einfach Dinge vermischt die sinnlos sind. Du sagst was von "Single Point of Failure" und baust dann eben gleich zwei? Du sagst ihr entwickelt Software? Dann sollte dir ggf. das Beispiel des Fliegers bekannt sein - warum die Atlantiküberquerung mit einer _einmotorigen_ Maschine gemacht wurde statt mit 2? Weil man kurz überlegt hatte - fällt ein Motor aus dann wird der zweite durch das höhere Gewicht u. Windwiederstand die Strecke nicht mehr schaffen. Somit hätte man die Fehlerchance einfach nur verdoppelt OHNE einen Sinn zu haben.
Dasselbe baust du grade. Und ja - das zeigt nunmal einfach das du das grundlegende System nicht verstanden hast. Du sagst was von "ungewöhnlicher Umgebung"? Ehrlich gesagt - warum? Weil ihr nen paar Entwicklermaschinen habt? Das ist auch nix anderes als nen paar Word-/Excel-Arbeitsplätze. Grad in dem kleinem Umfeld ist es nicht mal ungewöhnlich wenn auch da die Anwender Admin-Rechner haben. Wenn ich überlege - meine Server stehen morgens für Gewöhnlich nicht mal mehr am selben Ort wie am Vorabend, beim Internet wechselt das bei mir permanent zwischen SAT-Verbindungen, 4G oder Starlink (und das abhängig davon welches Programm man nutzt) oder eben der Strom und Klima eben auch mal weg sind,... Und es ist schon die leichtere Version, im letzten Job hat man erstmal auf ne Webseite geschaut WO der Server grad ist um zu überlegen ob man grade anrufen kann (weil die Kollegen vor Ort äusserst ungehalten reagieren wenn man um 3-4 Uhr morgens anruft um da mal zu fragen ob die was neustarten können). Also mit "ungewöhnlich" musst du da schon mehr rausholen als nen paar Entwicklermaschinen...
Das was du hast ist nunmal einfaches Homeuse Equipment. Das ist explizit dafür gemacht DAS es eben jeder der grundlegende IT-Kenntnisse hat zuhause aufbauen kann (also mehr oder weniger die Kenntnisse das man überhaupt weiss das es zB. nen NAS gibt).
Am Ende ist es aber deine Entscheidung. Wenn du meinst es ist für dich besser das so aufzubauen - nun, viel Spass. Ich vermute mal die meisten hier sehen es überraschenderweise anders. Und dabei werden hier ne handvoll Entwicklermaschinen wohl kaum jemanden morgens beim Kaffee nen graues Haar wachsen lassen.
Dasselbe baust du grade. Und ja - das zeigt nunmal einfach das du das grundlegende System nicht verstanden hast. Du sagst was von "ungewöhnlicher Umgebung"? Ehrlich gesagt - warum? Weil ihr nen paar Entwicklermaschinen habt? Das ist auch nix anderes als nen paar Word-/Excel-Arbeitsplätze. Grad in dem kleinem Umfeld ist es nicht mal ungewöhnlich wenn auch da die Anwender Admin-Rechner haben. Wenn ich überlege - meine Server stehen morgens für Gewöhnlich nicht mal mehr am selben Ort wie am Vorabend, beim Internet wechselt das bei mir permanent zwischen SAT-Verbindungen, 4G oder Starlink (und das abhängig davon welches Programm man nutzt) oder eben der Strom und Klima eben auch mal weg sind,... Und es ist schon die leichtere Version, im letzten Job hat man erstmal auf ne Webseite geschaut WO der Server grad ist um zu überlegen ob man grade anrufen kann (weil die Kollegen vor Ort äusserst ungehalten reagieren wenn man um 3-4 Uhr morgens anruft um da mal zu fragen ob die was neustarten können). Also mit "ungewöhnlich" musst du da schon mehr rausholen als nen paar Entwicklermaschinen...
Das was du hast ist nunmal einfaches Homeuse Equipment. Das ist explizit dafür gemacht DAS es eben jeder der grundlegende IT-Kenntnisse hat zuhause aufbauen kann (also mehr oder weniger die Kenntnisse das man überhaupt weiss das es zB. nen NAS gibt).
Am Ende ist es aber deine Entscheidung. Wenn du meinst es ist für dich besser das so aufzubauen - nun, viel Spass. Ich vermute mal die meisten hier sehen es überraschenderweise anders. Und dabei werden hier ne handvoll Entwicklermaschinen wohl kaum jemanden morgens beim Kaffee nen graues Haar wachsen lassen.
Wie man 5 VLANs auf men Syno hinbekommt? Mit nem simplen Helper den auch UniFi kennen sollte.
Was du aber eben einfach getan hast - deshalb der Hinweis mit dem Flieger: Wenn dir dein DHCP auf dem Router ausfällt (zB. weil dein Cloudkey versagt) hast du kein IP-Netz mehr, dein Netz ist praktisch Tod. Ob deine Syno noch läuft spielt also keine Rolle... Fällt deine Syno aus ist der DNS weg (und das AD) - damit ist dein Netz wieder praktisch tod. Du hast also effektiv nur die Chance auf Ausfall verdoppelt.
Du sagst ihr seid Entwickler? Gut, mache ich auch nebenbei. Ich arbeite zB. viel mit Webservices. Jetzt könnte ich natürlich nen einzelnen DB-Server hinstellen, dann nen Tomcat für die Kern-Applikation, dann nen weiteren Tomcat für nen paar Hilfsservices,... (obwohl die Leistung von nem einzelnem Server bei mir locker reicht). Was habe ich denn jetzt erreicht? DB-Server weg - Applikation tod. Kern-Applikaiton weg - app tod. Hilfs-Applikationsserver weg - selbst das Login geht nicht mehr, app tod. Ich habe also überhaupt keinen Gewinn mehr durch mehrere Server. ABER: Ich habe (in diesem Konstrukt) doch gleich 3x die Chance DAS was ausfällt.
Man KANN Dienste auf mehrere Server auslagern - das ist im grossen Umfeld durchaus normal. ABER: Da muss man sich eben mehr Gedanken drüber machen wie man eben die Ausfallrate reduziert und nicht unnötig erhöht.
Was du aber eben einfach getan hast - deshalb der Hinweis mit dem Flieger: Wenn dir dein DHCP auf dem Router ausfällt (zB. weil dein Cloudkey versagt) hast du kein IP-Netz mehr, dein Netz ist praktisch Tod. Ob deine Syno noch läuft spielt also keine Rolle... Fällt deine Syno aus ist der DNS weg (und das AD) - damit ist dein Netz wieder praktisch tod. Du hast also effektiv nur die Chance auf Ausfall verdoppelt.
Du sagst ihr seid Entwickler? Gut, mache ich auch nebenbei. Ich arbeite zB. viel mit Webservices. Jetzt könnte ich natürlich nen einzelnen DB-Server hinstellen, dann nen Tomcat für die Kern-Applikation, dann nen weiteren Tomcat für nen paar Hilfsservices,... (obwohl die Leistung von nem einzelnem Server bei mir locker reicht). Was habe ich denn jetzt erreicht? DB-Server weg - Applikation tod. Kern-Applikaiton weg - app tod. Hilfs-Applikationsserver weg - selbst das Login geht nicht mehr, app tod. Ich habe also überhaupt keinen Gewinn mehr durch mehrere Server. ABER: Ich habe (in diesem Konstrukt) doch gleich 3x die Chance DAS was ausfällt.
Man KANN Dienste auf mehrere Server auslagern - das ist im grossen Umfeld durchaus normal. ABER: Da muss man sich eben mehr Gedanken drüber machen wie man eben die Ausfallrate reduziert und nicht unnötig erhöht.
Moin,
Entschuldigung angenommen.
Genau. Du hast also nur einen single point of failure. Verteilst Du die Rollen ohne Redundanz auf zwei Stücke Hardware, dann hast Du zwei single point of failure. Vorausgesetzt, bei beiden Geräten besteht die gleiche Wahrscheinlichkeit des Ausfalls, hast Du bei einem Geräte eine Wahrscheinlichkeit von 1/x für den Ausfall. Bei zwei Geräten liegt sie bei 2/x. Sie ist also doppelt so hoch.
Das hat keiner bestritten. Bei so kleinen Netzen ist das vollkommen in Ordnung. Man muss nicht mit Kanonen auf Spatzen schießen.
Das ist der falsche Ansatz. Nutze die Werkzeuge, wofür sie gedacht sind. Router sind keine DHCP-Server. Im privaten Netz ist das ganz nett, wenn der Router das auch übernimmt. Im Firmennetz ist das allerdings mehr als suboptimal,
Das NAS ist doch auch kein DHCP? Da liegt die Aufgabe doch näher am Router? Wir haben 5 VLANS, die vom Router abgebildet werden, wie soll ich das vernünftig mit dem Synology hinkriegen?
Üblicherweise geht das so:
Auf dem DC oder auch einem eigenständigen DHCP-Server werden die Bereiche für die verschiedenen Netzsegmente eingerichtet. Auf dem Router wird ein DHCP-Forwarder eingerichtet, der die Anforderungen an den eigentlichen DHCP weiterreicht aus den Segmenten, die den DHCP nicht direkt erreichen können. Aber Du kannst das natürlich so lassen. Das ist eben nicht üblich aber auch nicht falsch. Du musst nur darauf achten, dass der DHCP-Server im AD autorisiert wird, DNS-Einträge zu erzeugen.
Du kannst auch den DNS auf einem anderen Server laufen lassen. Kein Problem. Man muss es halt nur richtig machen.
Der AD erzeugt ja automatisch einen DNS.
Nur, wenn Du ihm das sagst (zumindest unter Windows). Unter Linux muss man sogar den DNS selbst bauen. Auf der Synology ist das allerdings alles vorkonfiguriert.
Das ist richtig. Die Domain steht und fällt mit dem funktionierenden DNS. Das war ja auch Dein ursprüngliches Problem. Deshalb darf man auch keine externen DNS-Server in der Domain benutzen.
Kluge Entscheidung. Sonst hättest Du noch einen weiteren single point of failure und somit ein noch höheres Ausfallrisiko.
Was meinst Du, wieviel Ärger Du hättest, wenn kein AD vorhanden wäre. AD ist eine großartige Erfindung. Ich kenne noch die Zeiten, in denen es das nicht gab. AD ist einfach und übersichtlich, wenn man es kann.
Das mag grundsätzlich so sein. Aber zumindest die Synology Implementierung scheint problematisch zu sein bzw. ist mir nicht klar was wir falsch machen, denn vorher ging es ja halbwegs gut vor dem Update. Aber das ist ein eigenes Thema.
Wie verwaltest Du das AD denn? Direkt auf der Synology oder mit den RSATs?
Das ist sogar in großen Firmen gerne der Fall. Das AD ist sehr mächtig. Einiges davon braucht man nur in speziellen Fällen.
Liebe Grüße
Erik
Entschuldigung angenommen.
Verstehe ich nicht, wenn DNS und DHCP auch noch auf dem Server laufen, liegt doch das Risiko ausschließlich auf dem Server?
Genau. Du hast also nur einen single point of failure. Verteilst Du die Rollen ohne Redundanz auf zwei Stücke Hardware, dann hast Du zwei single point of failure. Vorausgesetzt, bei beiden Geräten besteht die gleiche Wahrscheinlichkeit des Ausfalls, hast Du bei einem Geräte eine Wahrscheinlichkeit von 1/x für den Ausfall. Bei zwei Geräten liegt sie bei 2/x. Sie ist also doppelt so hoch.
Wo habt Ihr teure Netzwerktechnik? Unifi und Synology ist die Billigvariante.
Dass weiß ich doch. Aber für unsere Ansprüche doch völlig ok. Vorher hatten wir TP-Link Archer und eine alte DS15xx.
Das hat keiner bestritten. Bei so kleinen Netzen ist das vollkommen in Ordnung. Man muss nicht mit Kanonen auf Spatzen schießen.
wenn wir sie nicht nutzen.
Das ist der falsche Ansatz. Nutze die Werkzeuge, wofür sie gedacht sind. Router sind keine DHCP-Server. Im privaten Netz ist das ganz nett, wenn der Router das auch übernimmt. Im Firmennetz ist das allerdings mehr als suboptimal,
Üblicherweise geht das so:
Auf dem DC oder auch einem eigenständigen DHCP-Server werden die Bereiche für die verschiedenen Netzsegmente eingerichtet. Auf dem Router wird ein DHCP-Forwarder eingerichtet, der die Anforderungen an den eigentlichen DHCP weiterreicht aus den Segmenten, die den DHCP nicht direkt erreichen können. Aber Du kannst das natürlich so lassen. Das ist eben nicht üblich aber auch nicht falsch. Du musst nur darauf achten, dass der DHCP-Server im AD autorisiert wird, DNS-Einträge zu erzeugen.
Schon der DNS stört mich auf der Synology, aber wegen AD leider unumgänglich.
Du kannst auch den DNS auf einem anderen Server laufen lassen. Kein Problem. Man muss es halt nur richtig machen.
Nur, wenn Du ihm das sagst (zumindest unter Windows). Unter Linux muss man sogar den DNS selbst bauen. Auf der Synology ist das allerdings alles vorkonfiguriert.
Den ich ja auch benutzen muss, damit sich die Domäne findet.
Das ist richtig. Die Domain steht und fällt mit dem funktionierenden DNS. Das war ja auch Dein ursprüngliches Problem. Deshalb darf man auch keine externen DNS-Server in der Domain benutzen.
Ich hätte ja gern, wie gesagt, einen PIhole dazwischen geschalten, leider von der Geschäftsführung abgelehnt.
Kluge Entscheidung. Sonst hättest Du noch einen weiteren single point of failure und somit ein noch höheres Ausfallrisiko.
Am liebsten würden wir auf AD verzichten, weil man damit nur Ärger hat .
.Was meinst Du, wieviel Ärger Du hättest, wenn kein AD vorhanden wäre. AD ist eine großartige Erfindung. Ich kenne noch die Zeiten, in denen es das nicht gab. AD ist einfach und übersichtlich, wenn man es kann.
Das mag grundsätzlich so sein. Aber zumindest die Synology Implementierung scheint problematisch zu sein bzw. ist mir nicht klar was wir falsch machen, denn vorher ging es ja halbwegs gut vor dem Update. Aber das ist ein eigenes Thema.
Wie verwaltest Du das AD denn? Direkt auf der Synology oder mit den RSATs?
Vieles was AD bietet, benötigen wir eigentlich nicht zwingend.
Das ist sogar in großen Firmen gerne der Fall. Das AD ist sehr mächtig. Einiges davon braucht man nur in speziellen Fällen.
Liebe Grüße
Erik
Moin...
ob 8.8.8.8 da die richtige wahl ist, oder 9.9.9.9 ist da Latte!
hth
Erik
Frank
Zitat von @erikro:
Moin,
Das ist falsch. Im AD dürfen nur und ausschließlich DNS-Server genutzt werden, die zu diesem AD gehören bzw. die internen Domainteilnehmer auflösen können. Wenn man halt nur einen in der Domain hat, dann gibt es eben keinen zweiten.
richtig, das ist Falsch... die 8.8.8.8 kannst du nur im DNS Server als forwarder nutzen (für externe Adressen)Moin,
Zitat von @pfcAndre:
Via DHCP wird der DNS ausgerollt, welcher ja gleichzeitig der AD ist, als secondary haben wir 8.8.8.8 genommen.
Via DHCP wird der DNS ausgerollt, welcher ja gleichzeitig der AD ist, als secondary haben wir 8.8.8.8 genommen.
Das ist falsch. Im AD dürfen nur und ausschließlich DNS-Server genutzt werden, die zu diesem AD gehören bzw. die internen Domainteilnehmer auflösen können. Wenn man halt nur einen in der Domain hat, dann gibt es eben keinen zweiten.
ob 8.8.8.8 da die richtige wahl ist, oder 9.9.9.9 ist da Latte!
hth
Erik
