11
OPNsense - Netzwerksegmentierung - Netzlaufwerke
Hallo Allerseits,
ich steige derzeit von IpFire auf OpnSense um und brauche etwas Support bei einem interessanten Problem, wo ich nicht einfach so weiter komme:
Es gibt eine Funktionierende Lösung, die aber nicht richtig ist, und mittelfristig anders gelöst werden müsste:
Es geht um Folgendes: Zwei (eigentlich mehr, aber zum Vereinfachung und Problemlösung reicht diese Annahme) getrennte Netzwerksegemete, wo in einem Segement (192.168.0.0/22) alle Server und die Windows AD Domaincontroller stehen, und im anderen (192.168.50.0/24) die Notebooks per LAN oder WLAN angebunden werden.
Die Firewall-Regeln sind zunächst mit * beidseitig offen, um diesen Faktor erstmal auszuschließen:
die Routen und Firewall auf den Servern sind so eingestellt, dass es hier keine Probleme zu erwarten sind. (es funktioniert ja auch die Variante2)
Setze ich auf der Clientseite den DNS-Server auf die DCs, funktionieren die Netzwerklaufwerke, setze ich die DNS-Server auf opnSense, sind die Netzwerklaufwerke nicht erreichbar. die Freigabe \\nas\freigabe fragt nach Zugansdaten und die Verbindung kommt nach Eingabe dieser zustande.
Ich vermute, dass ich entweder Netbios oder DNS oder beides nachkonfigurieren muss, aber ich fand bisher keinen Hinweis, wie das richtig zu machen ist.
Variante 1, gewünscht, Aber Netzwerklaufwerke funktionieren nicht
Variante 2, Funktional, aber eigentlich nicht richtig.
ich steige derzeit von IpFire auf OpnSense um und brauche etwas Support bei einem interessanten Problem, wo ich nicht einfach so weiter komme:
Es gibt eine Funktionierende Lösung, die aber nicht richtig ist, und mittelfristig anders gelöst werden müsste:
Es geht um Folgendes: Zwei (eigentlich mehr, aber zum Vereinfachung und Problemlösung reicht diese Annahme) getrennte Netzwerksegemete, wo in einem Segement (192.168.0.0/22) alle Server und die Windows AD Domaincontroller stehen, und im anderen (192.168.50.0/24) die Notebooks per LAN oder WLAN angebunden werden.
Die Firewall-Regeln sind zunächst mit * beidseitig offen, um diesen Faktor erstmal auszuschließen:
die Routen und Firewall auf den Servern sind so eingestellt, dass es hier keine Probleme zu erwarten sind. (es funktioniert ja auch die Variante2)
Setze ich auf der Clientseite den DNS-Server auf die DCs, funktionieren die Netzwerklaufwerke, setze ich die DNS-Server auf opnSense, sind die Netzwerklaufwerke nicht erreichbar. die Freigabe \\nas\freigabe fragt nach Zugansdaten und die Verbindung kommt nach Eingabe dieser zustande.
Ich vermute, dass ich entweder Netbios oder DNS oder beides nachkonfigurieren muss, aber ich fand bisher keinen Hinweis, wie das richtig zu machen ist.
Variante 1, gewünscht, Aber Netzwerklaufwerke funktionieren nicht
Eth1 opnSense Eth6
192.168.3.254 192.168.50.254
192.168.0.0/22 192.168.50.0/24
Windows Server Windows 10
dc1 192.168.0.1 Client 192.168.50.1 (per DHCP von OpnSense)
dc2 192.168.0.2 Gateway 192.168.50.254
nas 192.168.0.100 DNS1 192.168.50.254Eth1 opnSense Eth6
192.168.3.254 192.168.50.254
192.168.0.0/22 192.168.50.0/24
Windows Server Windows 10
dc1 192.168.0.1 Client 192.168.50.1 (per DHCP von OpnSense)
dc2 192.168.0.2 Gateway 192.168.50.254
nas 192.168.0.100 DNS1 192.168.0.1 (manuell gesetzt)
DNS2 192.168.0.2 (manuell gesetzt)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 82932830645
Url: https://administrator.de/contentid/82932830645
Printed on: April 27, 2024 at 05:04 o'clock
11 Comments
Latest comment
Moin,
Richtig ist ausschließlich, dass in einer Windows-Domain exklusiv die DNS-Server genutzt werden, die zu dieser Domain gehören.
hth
Erik
Zitat von @bmcs-alex:
Ich vermute, dass ich entweder Netbios oder DNS oder beides nachkonfigurieren muss, aber ich fand bisher keinen Hinweis, wie das richtig zu machen ist.
Ich vermute, dass ich entweder Netbios oder DNS oder beides nachkonfigurieren muss, aber ich fand bisher keinen Hinweis, wie das richtig zu machen ist.
Richtig ist ausschließlich, dass in einer Windows-Domain exklusiv die DNS-Server genutzt werden, die zu dieser Domain gehören.
hth
Erik
Man kann auch OPNsense als DNS Server verwenden, wenn dieser die passenden Anfragen auf diese Domäne durchreicht.
Auflösbar muss sein:
dc1.domain.tld
dc2.domain.tld
domain.tld
domain.tld muss auf die IPs der DCs zeigen.
Auflösbar muss sein:
dc1.domain.tld
dc2.domain.tld
domain.tld
domain.tld muss auf die IPs der DCs zeigen.
1
Danke, Das war der entscheidende Hinweis.
Zitat von @NordicMike:
Man kann auch OPNsense als DNS Server verwenden, wenn dieser die passenden Anfragen auf diese Domäne durchreicht.
Auflösbar muss sein:
dc1.domain.tld
dc2.domain.tld
domain.tld
domain.tld muss auf die IPs der DCs zeigen.
Man kann auch OPNsense als DNS Server verwenden, wenn dieser die passenden Anfragen auf diese Domäne durchreicht.
Auflösbar muss sein:
dc1.domain.tld
dc2.domain.tld
domain.tld
domain.tld muss auf die IPs der DCs zeigen.
Und was ist mit den anderen Servern? Was ist mit den dynamischen Einträgen der Clients?
Die Anfragen werden ja "durchgereicht" bzw gecached. D.H. der Client hat zwar den Router als Gateway und DNS Server, der Router fragt dann selbst beim DC nach.
1
Moin,
Warum sollte man das tun? Wozu einen weiteren Single Point of Failure konstruieren? Warum nicht das machen, was Best Practice ist? Worin liegt der Vorteil, einen anderen DNS-Server als den/die der Domain auf den Clients zu nutzen?
Liebe Grüße
Erik
Zitat von @NordicMike:
Die Anfragen werden ja "durchgereicht" bzw gecached. D.H. der Client hat zwar den Router als Gateway und DNS Server, der Router fragt dann selbst beim DC nach.
Die Anfragen werden ja "durchgereicht" bzw gecached. D.H. der Client hat zwar den Router als Gateway und DNS Server, der Router fragt dann selbst beim DC nach.
Warum sollte man das tun? Wozu einen weiteren Single Point of Failure konstruieren? Warum nicht das machen, was Best Practice ist? Worin liegt der Vorteil, einen anderen DNS-Server als den/die der Domain auf den Clients zu nutzen?
Liebe Grüße
Erik
Ich kenne jetzt schon einige Firmen. Bei reinen Windows Umgebungen wird gerne DC als DNS Server verwendet. Bei gemischten Umgebungen: so gut, wie gar nicht.
In Niederlassungen, in denen der DC nicht in der eigenen Niederlassung steht: Gar nicht. Das wäre ja Fatal.
In Niederlassungen, in denen der DC nicht in der eigenen Niederlassung steht: Gar nicht. Das wäre ja Fatal.
Moin,
Und? Ich erspare uns jetzt den Schvergleich.
So? Bei allen Umgebungen, die ich kenne, wird der Domain-DNS verwendet, weil es so am Besten funktioniert. Er muss nicht auf einem DC liegen. Aber es muss der sein, der für die Domain zuständig ist.
Wa? Dann muss ich aber mal ganz schnell alle unsere Außenstandorte umkonfigurieren.
Es wäre fatal, wenn die nicht die DCs unserer Domain benutzen würden. Dann ginge nämlich gar nichts. Selbstversändlich muss auch bei Außenstandorten das DNS der Domain benutzt werden. Wie sonst sollten die Rechner dort die DCs finden, um sich gegen sie authentifizieren zu können.
Liebe Grüße
Erik
Und? Ich erspare uns jetzt den Schvergleich.
Bei reinen Windows Umgebungen wird gerne DC als DNS Server verwendet. Bei gemischten Umgebungen: so gut, wie gar nicht.
So? Bei allen Umgebungen, die ich kenne, wird der Domain-DNS verwendet, weil es so am Besten funktioniert. Er muss nicht auf einem DC liegen. Aber es muss der sein, der für die Domain zuständig ist.
In Niederlassungen, in denen der DC nicht in der eigenen Niederlassung steht: Gar nicht. Das wäre ja Fatal.
Wa? Dann muss ich aber mal ganz schnell alle unsere Außenstandorte umkonfigurieren.
Es wäre fatal, wenn die nicht die DCs unserer Domain benutzen würden. Dann ginge nämlich gar nichts. Selbstversändlich muss auch bei Außenstandorten das DNS der Domain benutzt werden. Wie sonst sollten die Rechner dort die DCs finden, um sich gegen sie authentifizieren zu können.Liebe Grüße
Erik
Bei allen Umgebungen, die ich kenne
Ich lade dich herzlich ein unser Netzwerk kennen zu lernen. Aber nimm Taschentücher mit 
Dann zeige ich dir mal, wie ein gut laufender Linux DNS Server fungiert, nur mit diesen zwei oben genannten DNS Anfrageweiterleitungsregeln zum DC. Und sämtliche Domain Controller werden von den Clients gefunden und funktionieren ordentlich. Selbst über VPN.
Selbstversändlich muss auch bei Außenstandorten das DNS der Domain benutzt werden
Der DNS der Domain läuft üblicher Weise auf dem DC - so wird er auf jeden Fall beim erstellen des Domain Controllers automatisch mit eingerichtet, deswegen spreche ich vom DC, meine jedoch den DNS Dienst. Von dieser Konstellation geht mein Beispiel aus.Und wenn der lokale DNS Dienst nicht der DC selbst ist, dann muss er die Anfragen, die den DC betreffen trotzdem von wo anders cachen, so, wie ich es oben beschrieben habe.
Moin,
Was soll ich mit Taschentüchern.
Das bezweifele ich nicht. Die Frage ist, warum man solchen Unsinn treibt. Worin liegt der Mehrwert?
Da wird gar nichts automatisch eingerichtet. Man muss es schon beim Einrichten angeben, dass er das machen soll. Ich bin mir jetzt nicht sicher. Evtl. ist der Haken im Standard beim ersten DC eines Forest drin.
Also wenn ich schon Linux-Server nutze, um das DNS zu betreiben, warum dann noch einen auf den DCs? Warum dann nicht den Linux-Server zur SOA machen? Es gibt dafür einen guten Grund. Einen sehr guten.
Nein, muss er nicht. Wenn man unter Windows (und auch unter Linux) alles richtig macht, brauche ich auf dem DC keinen DNS-Service mehr. Da muss man nichts von woanders cachen.
Liebe Grüße
Erik
Zitat von @NordicMike:
Bei allen Umgebungen, die ich kenne
Ich lade dich herzlich ein unser Netzwerk kennen zu lernen. Aber nimm Taschentücher mit Was soll ich mit Taschentüchern.
Dann zeige ich dir mal, wie ein gut laufender Linux DNS Server fungiert, nur mit diesen zwei oben genannten DNS Anfrageweiterleitungsregeln zum DC. Und sämtliche Domain Controller werden von den Clients gefunden und funktionieren ordentlich. Selbst über VPN.
Das bezweifele ich nicht. Die Frage ist, warum man solchen Unsinn treibt. Worin liegt der Mehrwert?
Selbstversändlich muss auch bei Außenstandorten das DNS der Domain benutzt werden
Der DNS der Domain läuft üblicher Weise auf dem DC - so wird er auf jeden Fall beim erstellen des Domain Controllers automatisch mit eingerichtet,Da wird gar nichts automatisch eingerichtet. Man muss es schon beim Einrichten angeben, dass er das machen soll. Ich bin mir jetzt nicht sicher. Evtl. ist der Haken im Standard beim ersten DC eines Forest drin.
deswegen spreche ich vom DC, meine jedoch den DNS Dienst. Von dieser Konstellation geht mein Beispiel aus.
Also wenn ich schon Linux-Server nutze, um das DNS zu betreiben, warum dann noch einen auf den DCs? Warum dann nicht den Linux-Server zur SOA machen? Es gibt dafür einen guten Grund. Einen sehr guten.
Und wenn der lokale DNS Dienst nicht der DC selbst ist, dann muss er die Anfragen, die den DC betreffen trotzdem von wo anders cachen, so, wie ich es oben beschrieben habe.
Nein, muss er nicht. Wenn man unter Windows (und auch unter Linux) alles richtig macht, brauche ich auf dem DC keinen DNS-Service mehr. Da muss man nichts von woanders cachen.
Liebe Grüße
Erik
warum man solchen Unsinn treibt. Worin liegt der Mehrwert?
Das muss keinen Mehrwert haben, das kann historisch gewachsen sein. Oft bauen Windows Hasser ein komplettes Netzwerk ohne einer einzigen Windows Maschine auf. Linux DNS, Linux Router, Linux Clients usw. Wegen Kosten, Angst gegen Viren, aus Protest gegen die Zwangsupdates usw.Aber ohne Windows Clients kommen wenige aus. Und bei einer bestimmen Menge kommt ein DC dazu usw. Deswegen wirft man nicht das vorhandene Linux DNS gleich um.
Also wenn ich schon Linux-Server nutze, um das DNS zu betreiben, warum dann noch einen auf den DCs?
Weil der Linux DNS Server nichts vom Cluster weiss, nichts vom DFS weis, Replikation bei den Hyper-V Hosts usw. Weil er eben bei den DCs automatisch mit kommt. Die wenigsten klicken den weg und machen sich die Arbeit den Linux Server damit zu füttern, das muss erst einmal erlernt werden was da alles dazu gehört. Er schadet ja nicht, also kann er bleiben. So eine DNS Anfrageweiterleitung ist schnell eingerichtet und erspart einen Haufen Ärger. Den Clients ist es egal, ob die Antwort vom Router kommt (meistens und üblicher Weise: IP vom DNS Dienst = IP der Standard Gateway), oder von einem echten DNS Server, der auf dem DC mit läuft oder einem Rechner, der und den DNS Dienst hostet.Deswegen fahre auch ich zweigleisig: Die DCs, RDS Server, Clusters, Exchange DAGs usw bekommen als DNS Server die Domain Controller eingetragen, die Clients hingegen erhalten DNS Antworten vom jeweiligen Router des Subnetzes bzw VLANs. Alles in der Hauptniederlassung der Firma. Bei den Niederlassungen kommt es auf die Größe an. Wenn da sowieso ein Hypervisor tickert, kommt auch ein DC dazu mit rein, der DNS mit macht. Bei kleineren Niederlassungen kommt gar nichts hin, nur ein Router, der die DNS Anfragen (die Domäne betreffend) zu einem der externen DCs weiter leitet und andere DNS Anfragen ab ins Internet schickt. Aber auch in den größeren Niederlassungen fragen die Clients nicht den DC direkt an, der in der VM sitzt, sondern da macht es auch der Router dazwischen, damit die Struktur zumindest bei den einfachen Servern und Clients, WLAN Gästen, IoTs usw überall gleich bleibt: IP des DNS = IP des Routers.
brauche ich auf dem DC keinen DNS-Service mehr. Da muss man nichts von woanders cachen.
Das Cachen war wegen dem Konstrukt, wo eine kleine Niederlassung keine eigenen Server hat. Nur einen Router. Dieser Router muss cachen und den Weg zu den externen DNS Servern kennen. Auf keinen Fall dürfen Clients einen externen DNS Server der Hauptniederlassung in ihren Netzwerkeigenschaften drinnen stehen haben. Das wäre das von mir genannte Fatale, wo auch das Internet nicht mehr funktionieren würde, nur, weil der externe Server in der Hauptniederlassung nicht erreichbar ist oder seine WAN Leitung dicht ist.