kosta88

Danke. Werde ich am Freitag oder nächste Woche einrichten - bin gespannt ob das alles so funkt, wie man sich vorstellt.

Donnerstag ist die Besprechung mit dem Chef, wenn alles passt, Freitag wird umgesetzt.

Wie sonst? (angenommen kein Server lokal vorhanden)

Hallo, Hier mal ne recht "einfache" Frage zu dem DHCP. Ist auch eine Ableitung vom diesen Thema, jedoch habe ich die Netze "vereinfacht". Sind meine DCs entfernt (im Rechenzentrum), und in einem anderen Netzwerk als die lokalen Clients (die lokalen Clients werden mittels 1:1 NAT im Router übersetzt), sagen wir ich konfiguriere den Router um Anfragen an den entfernten DC weiterzuleiten, werden die Pakete wieder zum Client retour finden? Zu beachten ist dass die Clients im genateten Netzwerk nur mit der genateten Adresse zu finden sind. Als Beispiel: Client 192.168.1.100 sucht nach einem DHCP (DISCOVER). Router antwortet (Relay), sagt weiter an 10.10.10.10 (im RZ). RZ Server können auf 192.168.1.0/24 nicht zugreifen, jedoch können sie auf ein separates Netz, bspw. 10.20.10.0/24. So übersetzt der Router 192.168.1.100 ins 10.20.10.100, und leitet das DHCP Paket an 10.10.10.10 weiter. DHCP antwortet mit OFFER, und sendet das Paket an 10.20.10.100 (Client Adresse genatet). Client antwortet mit REQUEST, geht ja wieder über NAT, Client kann ja nur mit 192.168.1.100 senden, wird wieder genatet, DHCP bekommt und sendet zurück den ACK an die genatete Adresse der Clients. Schaut gut aus, oder? Danke!

Hm, dann ist es etwas was ich bei GPOs gesehen habe, und wohl analog gedacht habe es gibt bei Ordner auch... sorry.

Ah, ja. Ich muss ja keine Sperre setzen, sondern den User aus der Gruppe die Berechtigung auf D:\DATEN hat entfernen. Meine Güte, warum denke ich denn so kompliziert (Sperre usw...). Danke Leute.. :)

Root freizugeben ist no-go, eine Bedingung der Software die wir nutzen. Ist jedoch bei der oberen Konstellation trotzdem nicht möglich auf \\server zu gehen und direkt ins Share hinein?

Ahh, ja. Mei, saublöd geschrieben... also... Es ist ein 08/15 Ordner auf einem Laufwerk am Server, dieser wird freigegeben und als L: angebunden (und dann sind normale Unterordner gegeben, wie üblich). Der eine User soll darauf nicht zugreifen können, jedoch wohl auf einen Unterordner. Furchtbar, es tut mir leid für die Verwirrung!!

Nein, der Server mit dem LW-L ist ein File-Server, also eine Freigabe. Wenn RDS, dann auf einem anderen Server und Zugriff via Freigabe / Mount. Danke, ist das best practice. Aber wie verhält sich das System wenn man das macht wie oben beschrieben?

Besser wäre wenn DHCP lokal agiert, eigentlich. Ist wohl klar warum. Die Frage stellt sich für mich wegen dynamischen Updates, da diese in so einem Fall nicht stattfinden... glaube ich? Jetzt ist LANCOM2 DHCP, der zu vergebende DNS in DHCP Einstellungen ist einer der zwei Laptops die als DCs agieren. Daweil spüre ich keine Probleme, aber ich weiß nur von der Empfehlung her (also "best practice") dass sich DHCP am DC befinden soll. Übrigens, Antwort aus einem anderen Forum, zum gleichen Thema: "Das Problem, warum das Rechenzentrum auf das N:N-NAT besteht, wird mit Sicherheit sein, dass euer lokal verwendetes Subnet 10.146.32.0/24 im RZ bereits verwendet wird oder auch nur ein Teil eines dort bereits verwendeten Subnetzes ist. Daher dann die N:N-Maskierung im RZ um die Eindeutigkeit und damit Routebarkeit (geiles Wort...) zu wahren."

Man kann es per Relay herausrouten, oder? Ist ja nur die Frage ob das Paket retour findet?

Mache ich. Nun doch noch was: Auf der 1. Seite wurde geschrieben dass DHCP via NAT keine gute Idee ist. Funktioniert es nicht oder wie soll ich das verstehen? Habe ich da nicht ein Problem mit dynamischen updates?

Ich meinte ja nur so VPN via VPN (basteln im RZ). Gebastelt (oder besser gesagt eingerichtet) hätte ich nur was auf meiner Seite, aber nachdem da nix möglich ist, habe ich nur wegen Registry Eintrag nachgedacht, aber nachdem das auch so ne Sache ist, lassen wir es lieber. Dann gibt es einfach die Grenze.

Norbert: gut gesagt. Dann wird es kein DC lokal geben und basta. Nö, 4 VMs werden zur Verfügung gestellt. Ich möchte da nicht wirklich basteln... Ich möchte mich jedoch allen Beteiligten herzlich für die Hilfe bedanken, ihr seid Top :)

Die Entscheidung ob wir es machen, obliegt nicht mir. Ich werde es nach Möglichkeit einrichten. Wenn es nicht funktioniert, wird nur wichtig sein, dass ich darauf hingewiesen habe. Anderseits, wird es dann auch egal sein, die Finger werden auf mich zeigen - und ich vermute dass ist das was du meinst... Hah, der RZ ist unser Mutterkonzern. Wir sind zwar eigenständige GmbH, jedoch angewiesen an das MK und deren RZ - die Geschäftsleitung bei uns hat sich entschieden dort zu hosten, noch vor meinem Eintritt (preislich unterschiedet sich das von einem Microsoft Azure nicht gravierend). Daher ist es für mich jetzt nicht wirklich möglich hier "hart" zu sein. Wie gesagt, ich bin der Meinung dass ich nur darauf hinweisen kann. Aber ja, die Frage stimmt: auch wenn es unser MK ist, ist dieser Teil des Mutterkonzerns ein Hosting, und wir zahlen dafür. Man muss auch sagen, dass ich den Chef mitteilen muss, dass würde man die DCs NUR im RZ haben, dass das wohl von MS als getestete Lösung gibt. Der Nachteil ist ja die kontinuierliche Auslastung der WAN Leitung. Wenn doch DC lokal: die Weiterleitungen werde ich nach besten Gewissen eingerichten, lokaler DC wird vorhanden sein, die FSMO Rollen schicke ich ins RZ, und lokal vergebe ich zwei IPs für den DC (Registry), intern und extern. Dürfte reichen?

Hallo, Bitte kurz um eine Erläuterung zum Thema NTFS Berechtigungen. Beispiel: Laufwerk L:, Ordner-Sturktur L:\Folder1\Folder2\Folder3. LW-L soll grundsätzlich für alle Nutzer, System und Applikationen zugänglich sein. Jetzt kommt ein neuer Benutzer hin, und dieser soll ausschließlich Zugriff auf Folder3 haben. Wie wäre das am besten zu lösen? Was ich weiß: Man kann das LW ausblenden, das blockiert aber Direktzugang zu L:\ nicht. Was ich aber nicht sicher bin: Sollte man auf der L:\ Ebene für den einen Benutzer das LW-L sperren, greift die Sperre dann allgemein für alle Benutzer oder nur für den einen Benutzer? - ich weiß eben vonwegen Sperre greift vorrangig. Und wenn das funktioniert - dann kann man ja auf Folder3 Ebene die Vererbung deaktivieren, und dem Nutzer Zugang erlauben. Danke!

Ahaa, ja, na das ist mir schon klar! Ich hätte nicht gedacht du beziehst du genau darauf. Das habe ich noch nicht gemacht, wir werden heute noch mit den Kollegen aus dem RZ telefonieren.Sollte es Sinn machen, werde ich das Netz hier erstellen, und dann ins 10.146.32.0 via 10.241.56.1 routen, mit der Hoffenung dass es klappt :) . Via Forum sind manchmal solche relativ komplexen Szenarien keine einfache Sachen zu klären... Es ist eine öffentliche Internet IP, ganz normal über RIPE zu finden. EDIT: Telefoniert. Und war nichts unerwartetes. Also, es lässt sich angeblich keine weitere oder andere Konfiguration machen. Wir müssen zwingend ins RZ-Netz NATen. Das bedeutet für mich ja, wie aus dem Link das hier paar Threads vorher gepostet wurde, in Registry von unserem lokalen DC sowohl die echte wie auch die genatete IP im DNS hinterlegen. Persönlich mag ich sowas nicht, aber am Ende des Tages werde ich happy sein wenn es ordentlich funktioniert. Muss ich noch was anderes beachten? Es wurde mir zwar erklärt warum man aus dem 10.225.159.0 ins 10.146.32.0 nicht direkt anpingen kann, aber es liegt sehr wahrscheinlich an meinem Wissen das nicht verstanden zu haben. Etwas mit VPN und öffentlicher IP, und vielen anderen Routern die dazwischen liegen... Derzeitig ist die Konfiguration so: Lokal DC 10.146.32.165. 10.146.32.0 wird ins 10.241.56.0 genatet. Damit entsteht am LANCOM eine IP 10.241.56.165. Beide IPs landen in das Registry des DNS auf RZ-DC, damit die Replikation zwischen lokalen und RZ problemlos funktioniert. Naja, soll so sein...

Das ist das Client-Netz in RZ. Ich weiß nicht wie ich sonst dieses Netz nennen soll, bzw. die im RZ nennen es so. 10.241.56.251 ist die LAN-IP des VPN-Gateways. Klar hat auch eine WAN IP, diese ist "Entferntes Gateway" oben im Screenshot. Ne, hat er nicht. LANCOM hat nur Netz 10.146.32.0, aber nicht 10.241.56.0. Duh ;) Bin bei dir. Wenn ich es könnte (im RZ), würde ich. Die Wirkung ist aber die selbe. Ja, ist er. Was bringt das? Ins 10.225.159.0 Netz komme ich eh ohne Probleme hin. Das ist am Server eingerichtet (Router-Eintrag werde ich dann besprechen, hier geht es lediglich um "es funktioniert"). Ehh, warte. Das ist ja schon bereits am LANCOM drin: Siehe oberen Screenshots. Die Route... Router... "VPN..." =IST GLEICH= (nächster Screenshot) "Name der Verbindung", Entferntes GW: WAN IP des VPN-Routers. Also führt die Route zum 10.225.159.0 VIA WAN-IP des VPN-Routers. Ich könnte es ändern, sehe ich aber keine Notwendigkeit, da die Route zum RZ funktioniert. Ha! Genau da sind wir! Wie weiß ich denn das jetzt... LANCOM selber ist 10.146.32.1. Aber die Adresse für das VPN-interface finde ich nicht. Hm...

Hast Recht, ich habe vorher einen ungebildeten Fehler gemacht - VPN wird nicht aus einem Netz (oder verbunden mit einem Netz) aufgebaut, sondern "allgemein". Aber trotzdem ist es unverständlich. Mal zum VPN: Die VPN Verbindung wir vom RZ aus aufgebaut, deswegen haben wir eine fixe WAN IP. Die Einstellungen in unserem LANCOM haben als Router im RZ die öffentliche IP des VPN in RZ (siehe Screenshot unten). Gehen wir es mal mit Screenshots an... Die Route: Der Router (der ausgeblendete Eintrag in der Route): Entferntes Gateway: öffentliche IP des VPN Gateways in RZ. Derzeitiger NAT-Eintrag: Am 2012R2 Server in RZ: route add 10.146.32.0 MASK 255.255.255.0 10.241.56.251. Das Ergebnis: Mein Client hat die IP: 10.146.32.152 Die zwei Notebooks aus RZ erreichbar: Und was ich als nächstes tun würde: Hier würde ich ein Netz 10.241.56.0 erstellen, Router IP 10.241.56.1: und NAT entfernen. Was für Routing Eintrag (Einträge) ich noch dazu brauche oder editieren soll, bin ich mir jetzt nicht sicher. Dürfte gar keine Änderung notwendig sein, da die Route über öffentlichen RZ-VPN-GW bereits schon steht. Und noch was. Die Erreichbarkeit des 10.241.56.0 ist von meinem Rechner nicht gegeben.

Also dann, aus der Netzwerk-Sicht: Siehst du folgendes als funktionierend: 1) Am LANCOM1 wird ein Netz 10.241.56.0/24 erstellt, Gateway 10.241.56.1 2) Die Site-to-Site wird, anstatt aus dem 10.146.32.0 Netz, aus dem 10.241.56.0 Netz aufgebaut 3) Statische Route am LANCOM - 10.225.159.0/24 via 10.241.56.251 4) Statische Route am Server in RZ - 10.146.32.0/24 via 10.241.56.251 Sofern ich hier nichts übersehen habe, ergibt sich eine Route zwischen 10.146.32.0 und 10.225.159.0. zB: 10.146.32.201 (DC) -> 10.225.159.201 (DC im RZ), geht über 10.241.56.251 (VPN-GW ist in diese Konstellation auch aus dem 10.146.32.0 erreichbar) 10.225.159.201 -> 10.146.32.201 müsste auch funktionieren, da sich 10.146.32.0 und 10.241.56.1 lokal wie üblich "sehen". Damit kein NAT mehr. Sehe ich das richtig?

Der Server ist administrierbar. Als ich die Sache übernahm, konnte der Server nicht in die Domäne gesetzt werden. Jedoch als ich die statische Route über VPN Gateway zu 10.146.32.0 eingetragen habe, ginge es (ich habe es aber noch nicht gemacht). Ich muss aber selber noch nachsehen welchen DNS der Server in RZ anspricht usw. Gerade alles noch ein wenig unklar. Ich werde aber so lange es nicht machen, bis ich nicht sicher bin, was genau mit DNS passiert - da hier doch Thema NAT und Replikation nicht beliebt ist, noch ein Grund mehr zu warten und alles klären. Ich werde mal das Thema Routing am LANCOM besprechen, und ggf. testen, dürfte ja zu keinen sonderlichen Problemen führen, höchstens dass es nicht geht :)

Genau, viel ist leider fix und kann nicht geändert werden. Ich versuche mal hier KURZ zu erklären warum: Wir arbeiten in einer ASP-Lösung (Citrix) des Mutterkonzerns. Hier sind wir zwingend mit oberer Hälfte des letzten Octets des IP-Bereichs 10.146.32.0/24 beschränkt. Unser VPN-Router für ASP ist klarerweise auch in diesem Bereich, und alle Clients, Telefone, Drucker müssen auch sein - zwingend. Das Outsourcing von dem wir hier reden, hat mit ASP nichts zu tun, es ist der gleiche Rechenzentrum, aber andere Abteilung, und sie bieten eigene Bereiche - die auch nicht änderbar sind. LANCOM hat viele Möglichkeiten, inkl. logische Router zu erstellen. Wäre es doch nicht möglich, ein weiteres Netz (=Router) im LANCOM zu erstellen, dann die Site-to-Site VPN-Verbindung über diesen Router zu erstellen? Das Netz im LANCOM an das Netz des RZ abstimmen, also 10.241.56.0, und dann die Anfragen zum 10.225.149.0/24 via 10.241.56.251 routen. Und zwar beidseitig. Es ist auch grundsätzlich das, was magheinz geschrieben hat, nur muss man sich LANCOM vorstellen, das ist ne eigene Welt... Damit kann auch unser DC im 10.146.32.0 Netz bleiben, und alle geht via Routing. Ohne NAT. Ja. Das geht, weil die IP derzeit genatet wird. Es gibt kein Direktzugriff aus dem 10.241.56.0 im RZ -> 10.146.32.0 bei uns. Siehe auch noch Edit von oben...

Sorry, schlampig erklärt offensichtlich: In RZ ist ein 2012R2 samt ADDS/DNS Rollen installiert. Der Rechner ist noch nicht in unserer Domäne. Soll dann aber in die Domäne gesetzt werden, und zum DC heraufgestuft werden.

Danke, habe ich gefunden. Also wenn ich richtig verstehe, es wird empfohlen dass die Netze, in denen sich die zu replizierende DCs befinden, gleich sind? Was natürlich die Sache extrem vereinfachen würde. D.h. ich könnte lokal auf dem LANCOM das Netz 10.225.159.0/24 erstellen, und meinen lokalen DC in dieses Netz setzen. Dann dürfte ich keine Probleme mehr mit Replikation und Kommunikation von beiden haben, sofern die Routings passen. Oben habe ich das ganze für das andere Netz geschrieben, also bin nicht mehr ganz sicher was/wo ich hin will... Danke. Ich habe auch das hier gefunden: https://blogs.technet.microsoft.com/enterprisemobility/2009/04/22/dcs-and-network-address-translation/ Jedoch muss ich was dazu sagen: Ursprünglich gewünschte Konstellation ist nur DC + BackupDC in RZ. Nichts lokal. D.h. alle Abfragen gehen über Mobilfunk LAN - in diesem Szenario gibt es kein AD via NAT. Es ist nur, weil ich eben das Thema lokal DC behalten angesprochen habe, jetzt hier das Thema NAT aufgegangen ist. Persönlich halte ich nicht wirklich sehr viel von einem einizgen DC im RZ via LTE Verbindung...

Gleiche Geräte. Bspw. mein Rechner hat die lokale IP 10.146.32.171, im RZ aber 10.241.56.171. Aus dem RZ kann ich ihm NUR als 10.241.56.171 anpingen. Aber nicht als 10.146.32.171. Server in RZ ist aus 32.1 pingbar. Ich kann nicht pingen "aus" dem 56.1 Netz. Das ist nur ein Netz, in dem ich mich als Client nicht befinden kann, also kein Zugriff auf das Gateway zum Beispiel. Weiß ich noch nicht, DC im RZ ist berechtigterweise noch nicht aktiv. Verstehe leider die Frage nicht ganz. Alle Gateway IPs sind verbindlich und können nicht geändert werden. (LANCOM IP könnte ich ja ändern, aber auch nur innerhalb des 10.146.32.0/24 Netzes) Aber was ich mir gerade einfällt, und ich weiß nicht ob das wirklich sinnvoll ist, also Hilfe: Ich könnte am LANCOM ein zusätzliches (logisches) Netz erstellen, und zwar auch 10.241.56.0/24. Die Übersetzung entfernen. Ich müsste nachsehen welche IP lokal als VPN-Gateway agiert (bzw. welche Routing-Einträge vorhanden sind), aber ich vermute sehr stark es ist eine Adresse aus dem 10.241.56.0/24 Bereiches. Wenn ich lokal DC in diesem Bereich hätte, würde ich 0 Probleme haben, sehe ich das richtig? DC wird dann für alle Netze und Clients, auch aus dem 10.146.32.0/24 erreichbar. Danke. Werde mir die Sache so am Dienstag auch ansehen. Was auf der RZ-Seite möglich ist, weiß ich nicht, muss ich erst nachfragen.