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.

Moin

 

Bei mir haben Benutzer Berechtigung zum Zugfriff nur über Sicherheitsgruppe(n)

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?

Warum führst du dann hier die Diskussion über die letzten Seiten? ;)

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.

 

Kannst du eigentlich noch mehr virtuelle Maschinen dort hosten?

Eventuell könnte man sich da ein VPN über das VPN bauen. Das ist dann aber echt gebastelt.

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 :)

Manche lernen eben nur durch Schmerzen. ;)

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...

Ob ich mich an die Wünsche des RZ gebunden fühlte? Müsste ich mich strikt an der Regeln halten? Sind die mir vorgesetzt, wie weit? Für mich wäre das RZ ein Dienstleister zum Erfüllen meiner Anforderungen. Und wollten sie es nicht, ich ignorierte sie wohl so es mir in den Kram passte.

 

Ichbaute mir wohl in meinen Netzen meine Infrastruktur, so wie ich sie benötigte, also begänne ich am LANDC mit meinem AD-integrierten DNS, der hätte eine Weiterleitung auf den DNS des RZ. Ob die das merkten? Wie sollten sie denn? Ob die die das überwachen?

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!

Dieses GW "VPN-Punkt lokal" musst du im RZ als GW angeben. Das ist das was ich als 10.241.56.1 bezeichnet habe.

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...

BTW: was meinst du mit der "WAN-IP des VPN-Routers"?

Meinst du mit "öffentliche IP des VPN in RZ"? Ist das eine echte, öffentliche, im Internet geroutete IP oder vielmehr eine private IP die im VPN zur Verfügung steht?

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...

ich dachte 10.241.56.0 ist das VPN?

 

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.

 

Dann musst du das doch am LANCOM nicht einrichten, Der hat doch schone in Interface in diesem Netz.

 

Ne, hat er nicht. LANCOM hat nur Netz 10.146.32.0, aber nicht 10.241.56.0.

 

Übrigens: nicht jedes Gerät im Netz pingt!

 

Duh ;)

 

Ich würde ja auf den Endgeräte überhaupt keine routen einrichten. Das sollen doch bitte schön die router machen. Dafür sind die da.

 

Bin bei dir. Wenn ich es könnte (im RZ), würde ich. Die Wirkung ist aber die selbe.

 

Deine LANCOM1 ist doch vermutlich das default GW im LAN? Wenn ja musst du auf der LANCOM1 noch die route einrichten ins RZ-LAN über 10.241.56.251 als GW.

 

Ja, ist er.

Was bringt das? Ins 10.225.159.0 Netz komme ich eh ohne Probleme hin.

 

Im RZ auf dem router musst du dein lokales LAN über die 10.241.56.251 als GW einrichten.

 

Das ist am Server eingerichtet (Router-Eintrag werde ich dann besprechen, hier geht es lediglich um "es funktioniert").

 

In linux wäre das für den LANCOM1:

route add -net 10.255.159.0 netmask 255.255.255.0 gw 10.241.56.251

 

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.

 

und für den router im RZ:

route add -net 10.146.32.0 netmask 255.255.255.0 gw 10.241.56.1(oder wie auch immer sonst das VPN-interface der LANCOM1 lautet)

 

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...

 

Router im "LAN lokal"(LANCOM1) bekommt als route: "LAN RZ" über GW "VPN-Punkt lokal"

Die Route:

Der Router (der ausgeblendete Eintrag in der Route):

Entferntes Gateway: öffentliche IP des VPN Gateways in RZ.

 

Derzeitiger NAT-Eintrag:

 

Router im "LAN" RZbekommt als route: "LAN lokal" über GW "VPN-Punkt RZ"

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.

 

Um DNS würde ich mor ja erst Gedanken machen wenn IP sauber funktioniert. Ich bin aber auch nur der Netzwerkfuzzy...

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?

Da dem 32.Netz per RDP der Server im RZ erreicht wird, besteht ja eine funktionierenden Verbindung, damit ist administrierbar.

 

Ob es gelingt, den Server im RZ der Domäne hinzuzufügen und anschliessend zum DC hochzustufen?

 

 

Auf dem LANCOM ein weiteres Routing einzurichten zwischen 32 und 56? Und das PAT/NAT rauswerferen? Ich denke im Moment, das sollte funktionieren. Und es ist gut begreiflich, für mich jedenfalls. :)

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 :)

So wie ich Kosta verstanden, sind gewisse Sachen wohl nicht änderbar, er hat keine Kontrolle darüber.

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.

 

Falls sich der Bereich 32 nicht auflösen lässt, zwischen dem Netz 32 und dem Netz 56 einen weiteres Gerät, einen Router setzen, wie auf der anderen Seite im RZ auch. Und weg mit der Translation.

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.

 

Kannst Du denn aus dem 32. auf den Server im RZ zugreifen? Z.B. per RDP?

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...

Was ist eigentlich wichtig? Ist es wichtig, vom RZDC aus den LANDC pingen zu können? Oder umgekehrt, den RZDC vom LANDC? Wichtig dürfte doch sein, die beiden DC der Domäne haben Kontakt und replizieren einander.

 

 

Das verstehe ich nicht, was ist das? Ist das ein DC deiner Domäne oder nicht?

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.

NAT in einer ad replikationsstruktur ist zwangsläufig problematisch. Evtl. Sogar unsupported, gab zumindest dazu mal einen technet Artikel.

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...

https://support.microsoft.com/en-us/help/978772/description-of-support-boundaries-for-active-directory-over-nat

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...

Welche Geräte sind 32.1 und 56.1?

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.

 

Ist der Server im RZ von 32.1 und 56.1 aus pingbar?

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.

 

"Verstehn" sich die beiden DC miteinander?

Weiß ich noch nicht, DC im RZ ist berechtigterweise noch nicht aktiv.

 

Sind die beiden LANCOM im LAN beide mit dem dem DC und den Clients verbunden? Welcher aber ist "verbindliches" Gateway?

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.

Egal wie du es drehst und wendest, du musst immer auf beiden Seiten konfigurieren.

routingeintrag lancom1:

10.225.159.0/24 gw 10.241.56.251

 

routingeintrag RZ-GW

10.146.36.0/24 gw IP-Lancom1-VPN

 

Dann sollten sich die Netze sehen können.

 

NAT und co sind definitiv nicht notwendig und verkomplizieren die Sache nur.

Wenn du es umbedingt machen willst, dann musst du auf der RZ-Seite auch ein NAT einrichten denn sonst finden die Pakete ja den Weg nicht zu dir.

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.