Site-to-Site mit Rechnerzentrum und die Netz-Erreichbarkeit

[Kosta]

Hallo Leute,

Ich hoffe jemand hier kann mir ein wenig Licht auf das Thema werfen. Gleich in vorhinein: das Projekt ist nicht meins, ich bin in der Firma seit 2 Wochen, und widme mich dem Thema. Die Kollegen die das eingerichtet haben sind noch nicht erreichbar, Kontakt sollte diese Woche erfolgen.

Folgendes war ursprunglich gewünscht:
Nichts mehr lokal aus Clients (+Drucker und Telefonie), und alle Server ausgelagert.
Neu:
DC + andere Server in RZ und ein DC lokal um WAN zu entlasten.

Soll so realisiert werden:
Unser lokales Netz mit RZ per S2S verbinden.
Dzt. vorhanden ist ein DC lokal, dieser befindet sich im gleichen Netz wie alle Clients.
RZ LAN IP ist eine andere.

Ich poste hier mal eine Skizze des Netzwerkes, um besser zu schildern:

Network.jpg

Hier sieht man grundsätzlich drei Netze.
Unser lokales Netz, 10.146.32.0/24
RZ LAN: 10.225.159.0/24
und sog. "Client-Netz": 10.241.56.0/24

WICHTIG:
Keiner der 3 o.g. Netze kann geändert werden.

Folgende Konfigurationen sind im LANCOM vorhanden (ich kann leider nur 3 Dateien anhängen, so werde ich es bestmöglich beschreiben):
IP-Netzwerke:
INTRANET:
10.146.32.0/24, IP: 10.146.32.1
IKEv2, Verbindungs-Liste:
VPNRZ, Entferntes Gateway: öffentliche IP des VPN-RZ-GW
IPv4-Routing-Tabelle:
10.22.159.0/24, Router VPNRZ
N:N-NAT-Tabelle:
Ziel-Gegenstelle: VPNRZ
Original Quell-IP-Adresse: 10.146.32.0
Netzmaske: 255.255.255.0
Umges. Quell-IP-Adresse: 10.241.56.0

Route am RZ-Server eingetragen und Ergebnis:

Ping RZ.JPG

Im RZ, Netzwerk-Eigenschaften, DNS: 10.241.56.156 (unser DC/DNS lokal, jedoch umgesetzt)

Ergebnis lokal:

Lokal.JPG

Zusammengefasst:
In dieser Konstellation wird genatet in das Netzwerk des RZ, um die lokalen Clients aus dem RZ erreichen zu können (nur mit der genateten Adresse).
10.146.32.0 DIREKT ist derzeit aus dem RZ nicht erreichbar.
Ich kann das Netz 10.225.159.0 erreichen, also komme normal per RDP auf die Server.
Jedoch kann ich aus unserem lokalen Netz (INTRANET) das Netz 10.241.56.0 nicht erreichen.

Ich würde gerne die übliche Site-to-Site haben, wo sich die Netze 10.146.32.0 und 10.225.159.0 direkt sehen können. Weiß aber gerade nicht ob das so möglich ist, und was ich dafür genau tun müsste.

Die einzige Idee die ich habe, ist lokal ein weiteres Netz, 10.241.56.0 erstellen und NAT zu entfernen. Damit denke ich dürfte ich das Netz 10.241.56.0 auch in RZ normal erreichen können (wichtig wäre hier das VPN-Gateway, 10.241.56.251, zu erreichen.
Denn, so würde das weitere Netz lokal dazu dienen, den VPN Gateway erreichen zu können. Eine weitere statische Route dürfte nicht notwendig sein, und ich müsste aus meinem Netz, also 10.146.32.0 den VPN-Punkt im RZ (10.241.56.251) erreichen können.

Bitte um Rat, da ich keine Änderungen machen möchte, bevor ich mir sicher bin, dass es funkt. Und vor allem dass ich damit nichts "kaputt" mache.

Besten Dank!
Kosta

[Koppelfeld]

Grundsätzlich mußt Du auf dem _entfernten_ Gateway Routen zu den Netzen haben, die Du lokal angelegt hast.

Ein "entfernter" DC ist u.U. problematisch, weil manche Clients es erfordern, daß sie im gleichen Netz sind wie der DC.

[Kosta]

Grundsätzlich mußt Du auf dem _entfernten_ Gateway Routen zu den Netzen haben, die Du lokal angelegt hast.

Vom Grundsatz her, klingt logisch.
Aber wie?
Im RZ gibt es das Netz 10.241.56.0, ist das Netz des VPN-Gateways (VPN-GW: 10.241.56.251). Das ist auch die Route "retour".
Ob die Route am Server oder Gateway steht, ist doch egal, oder? Egal von wo, ich versuche immer das Netz 10.146.32.0 zu erreichen, und gehe dafür über VPN-GW 10.241.56.251.

Liegt das Problem nicht hier bei uns, im LANCOM? Wenn das Netz doch gleich wäre, also beidseitig 10.241.56.0/24, gäbe es keine Gründe dass sich die zwei ohne naten sehen, oder?

Ein "entfernter" DC ist u.U. problematisch, weil manche Clients es erfordern, daß sie im gleichen Netz sind wie der DC.

Wird nicht anders möglich sein. Die zwei DCs würden in sowohl verschiedenen Netzen, wie auch entfernt sein.
Welche Clients fordern das?

[MariusP]

Hi,
Ohne Rückroute kommen alle Pakete zwar an aber die Antwort kann den Weg nicht zurückfinden.
Ich würde dir empfehlen dies zu überprüfen.
Wenn es immernoch nicht geht, schau dir auf den beiden Geräten den ICMP und den IP-Router Trace an. (Bedenke mit einem @ die Trace Menge zu limitieren.
Gruß

[Koppelfeld]

Grundsätzlich mußt Du auf dem _entfernten_ Gateway Routen zu den Netzen haben, die Du lokal angelegt hast.

Vom Grundsatz her, klingt logisch.
Aber wie?
Im RZ gibt es das Netz 10.241.56.0, ist das Netz des VPN-Gateways (VPN-GW: 10.241.56.251). Das ist auch die Route "retour".

Nun stell' Dir vor, Du wärst ein Paket, welches zurück in Euer LAN soll. Kein Witz. Die Routingtabelle ist vergleichbar mit einem Wegweiser. In die Routingtabelle des Routers im RZ mußt Du also die beiden zusätzlichen Netze Eures Büros eintragen, und zwar mit dem Ziel des dortigen LANCOM.

Ein "entfernter" DC ist u.U. problematisch, weil manche Clients es erfordern, daß sie im gleichen Netz sind wie der DC.

Wird nicht anders möglich sein. Die zwei DCs würden in sowohl verschiedenen Netzen, wie auch entfernt sein.
Welche Clients fordern das?

"Windows 3.1" und "NT 4.0". Bitte nicht lachen, die sind noch zuhauf im Einsatz. Weltfirma Trumpf beispielsweise lieferte noch vor kurzem eine riesige Laserschneidmaschine mit NT4 aus. Allerdings inklusive dem seinerzeit aktuellen SP6a.
Ältere Trumpf - Steuerungen verwenden auch nach Werks-Generalüberholung noch "Windows 3.1".
Ja, beide Fälle habe ich selbst erlebt.
Also: Obacht, wenn Ihr Werkzeugmaschinen in eine Win-"Domäne" prügeln müßt ohne Layer-2 - Verbindung zum DC.

[Kosta]

Ich behaupte dass ich schon verstehe was ein Routing ist bzw. wie es funktioniert.

Jedoch, entweder fehlt mir eine Komponente (Router...?) um das richtige einzutragen oder ich verstehe es falsch.

Wenn ich es richtig verstehe, S2S unterscheidet sich in Konzept nicht wirklich von einer remote access VPN, nur dass es bessere Sicherheit, Verschlüsselung usw. bietet. Also gibt es in S2S genauso einen Gateway. Dieser ist, wie bei mir dargestellt, intern 10.241.56.251 und hat auch eine externe IP (die ich hier nicht nennen will, klar...). Ich habe keine Kontrolle im RZ, aber gehe stark davon aus, dass diese beiden das gleiche Router sind.

Die Pakete die an 10.225.159.0 gesendet werden, werden via WAN IP des VPN-Gateways geroutet. Logisch.

Route zum RZ.JPG

Hier die VPN-Verbindung, die als Route verwendet wird:

IKEv2.JPG

Jedoch:
Die Pakete aus dem 10.225.159.0 an 10.146.32.0 werden via ??? geroutet? Das muss in RZ eingestellt werden, wie oben gesagt.

Aus meiner Sicht, ob die Einträge am Server oder Gateway sitzen, ist genau egal. Die Pakete im RZ-Server-Netz, 10.225.159.0 müssen so weit kommen können, damit das Netz 10.146.32.0 gefunden wird. Doch finde ich keinen Weg. Oder bin ich schlicht unwissend.
Was ich gemacht habe: route add 10.146.32.0/24 10.241.56.251.

Aber, wie oben in der Skizze gezeigt, gibt es weiteres Netz, das ist 10.241.56.0, wird für die genateten remote clients aus dem 10.146.32.0 Netz verwendet. Dort sind dann alle, wie auch in 10.146.32.0 mit der Adresse 10.241.56.x verfügbar. Also 10.146.32.161 wird zu 10.241.56.161.
Und diese Adresse ist dann aus dem 10.225.159.0 erreichbar.

Wird kein NAT gemacht, gibt es keine remote clients im RZ 10.241.56.0 Netzwerk, ergo kein DNS für RZ-Server (derzeitig eingetragen: unser DC mit der genateter Adresse).

Ich weiß, so im Forum geschrieben, ist es sehr schwer zu begreifen, auch für mich hier - obwohl das liegt sich an Unwissen.

[Koppelfeld]

Aus meiner Sicht, ob die Einträge am Server oder Gateway sitzen, ist genau egal.

Nö. Solange einer der Server im RZ eine Default-Route zum Gateway hat, landet ja jedes Paket außerhalb des RZ-LANs auf dem RZ-Gateway.
Aber während ich dies schreibe, schwant mir, was Du meinst: Du willst als Gateway den Router bei Euch eintragen. No way, der Gateway muß lokal erreichbar sein. Also: Auf den Servern im RZ reicht die Default-Route.

Die Pakete im RZ-Server-Netz, 10.225.159.0 müssen so weit kommen können, damit das Netz 10.146.32.0 gefunden wird.

Damit die Pakete, welche qua Default-Route auf dem RZ-Gateway angelangt sind, Dein 10.146.32.0/24 finden, brauchst Du jetzt in der ROUTING-TABELLE des RZ-Gateways einen entsprechenden Eintrag.

Ich weiß, so im Forum geschrieben, ist es sehr schwer zu begreifen, auch für mich hier - obwohl das liegt sich an Unwissen.

Oh, ich habe mindestens zehn Jahre gebraucht, um diese doofe Routerei zu internalisieren. In der Rückschau kann ich zwar nicht verstehen, warum das so war -- es ist offensichtlich so wie mit dem Autofahren.

[Kosta]

Default-Route im RZ ist 10.225.159.250.
Im RZ sind, und ich hätte gehofft aus der Zeichnung, die 10.225.159.0 und 10.241.56.0 sich "bekannt".
Das Problem tritt nur dann auf, wenn ich das 10.241.56.0 "überspringen" will. Ich bekomme keine Direktverbindung zum 10.146.32.0.

Ich werde morgen, wenn ich mal Zeit habe, die NAT rausschmeissen und schauen was passiert, wenn ich die Route am Server eintrage. Ob die Erstellung des Netzes 10.241.56.0 am LANCOM bei uns was bringt oder nicht, weiß ich nicht. Andere Seite ist übrigens kein LANCOM, soweit ich weiß.

Ein Kollege im Telefonat teilte mir mit, dass diese NAT Funktion deshalb da ist, damit man aus dem RZ-Netz, 10.225.159.0 Zugriff auf die Clients hat, jedoch über der genateten IP. Deshalb fiel mir ein, das RZ-Client-Netz, das vorgegeben ist, auch bei uns zu erstellen, mit der Hoffnung dass ich damit die Brücke zwischen Routing and NAT schließe.

[Koppelfeld]

RZ-Netz, 10.225.159.0 Zugriff auf die Clients hat, jedoch über der genateten IP. Deshalb fiel mir ein, das RZ-Client-Netz, das vorgegeben ist, auch bei uns zu erstellen, mit der Hoffnung dass ich damit die Brücke zwischen Routing and NAT schließe.

Manchmal ist es auch besser, Brücken abzureißen. NAT ist in Deinem Szenarium nicht zielführend. Abschalten und VPN-Verbindung trennen und wiederaufbauen.

[Kosta]

Ai, die sprachliche Barriere. Ich meinte eh dass ich NAT auflösen will und rein mit Routing alles verbinden.
Außerdem wird eine Replikation via NAT von Microsoft nicht empfohlen, im Gegenteil, nicht supportet und nicht getestet.

[PappaBaer]

Bin ich der einzige, der die im Eröffnungspost angekündigte Skizze nicht sieht?!?

[Kosta]

Bin ich der einzige, der die im Eröffnungspost angekündigte Skizze nicht sieht?!?

Danke für den Hinweis. Wahrscheinlich habe ich was falsch gemacht... wurde korrigiert.

[Kosta]

Nun habe ich die Rückmeldung von RZ bekommen, und wir müssen angeblich NATen. Anders geht's nicht. Die Netze 10.146.32.0 und 10.225.159.0 können nicht direkt gepingt werden (ohne NAT). 10.146.32.0 muss übersetzt werden.

Warum das so ist, hat mir der Mitarbeiter versucht zu schildern, aber leider habe ich es nicht verstanden. Entweder reicht mein Wissen dafür nicht, oder scheitert an der Erklärung - kann nicht sagen. Er meinte es hat was mit irgendwelcher öffentlichen IP... k.A. ehrlich gesagt.

Wir sollten replizierende DCs via NAT machen, die sich ausschließlich mit DNS und nicht mit einer IP ansprechen.

[Koppelfeld]

Nun habe ich die Rückmeldung von RZ bekommen, und wir müssen angeblich NATen. Anders geht's nicht. Die Netze 10.146.32.0 und 10.225.159.0 können nicht direkt gepingt werden (ohne NAT). 10.146.32.0 muss übersetzt werden.

a) Habe gestern vom Mobiltelephon aus auf das Forum zugegriffen, modernes 'responsive design'. Deshalb habe ich gar nicht erwartet, die Graphik vorzufinden.
b) Da liegt ein klares Problem auf Layer 8 vor.
1:1 NAT ist in dieser Konstellation unnötig.
Mit den "öffentlichen" Adressen haben wir gar nix zu tun.
Es kann jedoch sein, daß die RZ-Leute irgendetwas mit "Transfernetzen" gederkelt haben, eine prima Möglichkeit, sich einen Langzeitzünder zu bauen.

[Kosta]

Ich bin zwar im Netzwerktechnik-Jargon nicht wirklich versiert, aber ich glaube ich verstehe was du mit Layer 8 meinst

Es handelt sich hier um einen der größten deutschen IT-Unternehmen (wobei ich es komischerweise in den typischen Listen im Netz nicht finde, obwohl Jahresumsatz zu den Top10 gehört), haben soweit ich weiß 5 RZ Standorte in DE. Daher alles ist möglich.

Warum Langzeitzünder?

Und so da jetzt du sagst dürfte nicht notwendig sein...
Was ist grundlegend notwendig dass so eine Konstellation funktioniert, bzw. welche Gateway? Wie würde Routing in diesem Fall aussehen, damit es funkt? Gibt es irgendwo eine (allgemeine) Zeichnung wo ich mir das besser veranschaulichen kann? zB. welche Gateways sind wie impliziert usw?

Und noch was: diese NAT Einstellung, ist die nur One-Way, oder werden die Pakete auch zurück-NATted? Also 10.241.56.0 -> 10.146.32.0.