Client-Netz über VPN / Serverseitige-Übersetzung?

[kosta88 2]

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.

[NorbertFe 2.035]

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

[kosta88 2]

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

bearbeitet 30. April 2017 von kosta88

[lefg 276]

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.

 

 

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

 

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

[NorbertFe 2.035]

Was sind denn "gleiche Netze"? Wichtig ist, dass es geroutet ist und nicht nat. Evtl. Doch nochmal die Grundlagen durchgehen? ;)

[lefg 276]

Wer is zuständig, Dir/Euch eine funktionierende Verbindung bereitzustellen? Die Netzwerker vom Rechenzentrum? Wissen die, dass es nicht funktioniert?

 

Ich strebte wohl an, die Sache möglicht zu vereinfachen, grundsätzlich diese PAT/NAT-Geschichte loszuwerden.

 

Wie @NorbertFe schrieb: Routing

 

Das 56.Netz funktioniert ja wohl, auch dessen Verbindung ins159. und zum Server dort.

 

Am einfachsten erscheint mir, Adressen 32. durch 56. zu ersetzen, dazu PAT/NAT rauszuwerfen.

 

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.

 

 

Aber vielleicht hilft ja die Umsetzung von Magheinz Anregung.

bearbeitet 30. April 2017 von lefg

[magheinz 110]

die router sind doch alle da. man muss ihnen nur noch die entsprechenden routen beibringen.

[lefg 276]

die router sind doch alle da. man muss ihnen nur noch die entsprechenden routen beibringen.

 

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

bearbeitet 30. April 2017 von lefg

[kosta88 2]

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.

[lefg 276]

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

bearbeitet 30. April 2017 von lefg

[kosta88 2]

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

bearbeitet 30. April 2017 von kosta88

[lefg 276]

Da aus dem 32.Netz per RDP der Server im RZ erreichbar, 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. :)

 

Stellt sich eventuell noch die Frage, warum wurde das nicht gleich so gemacht sondern mit Translation? Fiel dem Netzwerker nichts anderes ein? Ist ihm das vorgeschrieben?

bearbeitet 30. April 2017 von lefg

[kosta88 2]

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

bearbeitet 30. April 2017 von kosta88

[magheinz 110]

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

bearbeitet 1. Mai 2017 von magheinz

[lefg 276]

Gehen wir mal davon aus, der DNS am LANDC ist richtig eingerichtet, ist AD-integriert, DNS-Eintrag des Server ist richtig, der DC funktioniert richtig, wurde geprüft mit dcdiag.

 

Will man vom Testergebnis nur die Fehlerausgabe bekommen:  dcdiag /q

 

In eine Datei geschrieben die Fehlerausgabe: dcdiag /q > Dateiname.txt

 

Falls die Fehlerausgabe hier eingetellt werden sollte, bitte diese schon vorher nachbearbeiten, damit es gut lesbar wird.

bearbeitet 1. Mai 2017 von lefg