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

[kosta88 2]

Hallo,

 

ich bin mir nicht sicher ob das hierher oder im Netzwerk gehört. Die Basis ist Netzwerk, aber ggf. liegt die Antwort bei Windows Server.

 

Wir sind dabei zwei DCs über VPN einzurichten. Ein DC ist lokal, und eins sollte im Rechenzentrum eingerichtet werden.

 

Dabei handelt es sich um eine Site-to-Site VPN Verbindung, jedoch nicht um gleiche (Client-)Netze.

 

Das lokale Netz, 10.146.32.0, wird gegenwärtig für den DC, andere Server, Clients, Telefonie, usw. verwendet. Infrastrukturbedingt kann dieses Netz nicht geändert werden.

Das Rechenzentrum VPN Netz kann aber auch nicht auf unser Netz angepasst werden (Terminierung des VPN Tunnels ist geshared auch für andere Kunden), und hat eine Clientnetz-Adresse 10.241.56.0.

 

Unser Netzwerk, das für die Server im RZ verwendet wird, ist auch ein anderes, also 10.225.159.0. Hier sind derzeit Server mit IPs im letzten Octet Nr. 1-4.

 

Auf unserem LANCOM Router lokal hier in der Firma, dieser baut auch die VPN Verbindung auf, ist eine Netz-Übersetzung von 10.146.32.0 ins 10.241.56.0 eingerichtet.

 

Somit, nach der Einrichtung einer statischen Route auf dem Server im RZ, damit die Anfragen die an 10.146.32.0 gestellt werden, über dem VPN-Gateway verlaufen, passiert folgendes:

- beim anpingen des hostname.domain.local, kommt eine Antwort mit der IP 10.241.56.x (x=letztes Octet der IP-Adresse aus dem Netz 10.146.32.0) - ist klar, wegen der Übersetzung im LANCOM

- beim anpingen der Adresse 10.241.56.x kommt eine Antwort - klar, wie oben

- beim anpingen der IP 10.146.32.x kommt keine Antwort (auch klar - es gibt keine Übersetzung im Rechenzentrum, vermute auch dass keine möglich ist)

 

Ich sehe ggf. Probleme beim DNS:

Wenn neue DC eingerichtet wird und repliziert, repliziert er die Adressen 1:1 vom ersten DC. Dieser hat Einträge aus dem Netz 10.146.32.0.

Ich weiß dass DNS auch mehrere A-Records für den gleichen Hostname und verschiedene IP haben kann, klar, aber wenn ich dann im RZ eine Adresse 10.146.32.x anpingen versuche, dann wird keine Antwort kommen. Ich könnte jedoch im DNS im RZ als Weiterleitung den lokalen DNS eintragen... die Einträge werden repliziert, alle, und die Weiterleitungen an allen DNS würden dazu sorgen, dass die Abfragen überall passieren. Dürfte ja gehen, oder?

 

Ich weiß nicht ob es sinnvoll ist auch dort noch DHCP zu betreiben (zzgl. zum lokalen DHCP auf dem DC). Die Anfragen kann ich ja im LANCOM an beide Server senden, und in Windows DHCP die Verzögerung (ich bilde mir ein, irgendwas davon gelesen zu haben, habe jetzt nur kein 2012R2 zu checken) einrichten.

 

Aber bin ich mit meiner Mathe zu Ende.

Funktioniert das wie ich mir vorstelle?

Mir kommt es nur so vor, als die wichtigste Aufgabe sein wird, alle Weiterleitung und DNS Server im DHCP einzutragen, und dafür sorgen dass die DNS und DHCP Abfragen überall hinkommen können, wenn zB. der lokale DC abkackt.

 

Also nochmals, wenn das eher zu Netzwerk gehört, bitte verschieben, aber das Thema läuft hauptsächlich auf die Sache DC/DNS/DHCP in einem anderen Netzwerk und wie das genau funktionieren wird.

 

Ich werde auf jeden Fall in einer Lab-Umgebung simulieren. Jedoch wäre vorher gut die Theorie zu wissen.

 

Ich hoffe klar genug. ;)

 

Besten Dank!

Kosta

[kosta88 2]

Niemand? Wenn zumindest eine Grundfrage beantwortet werden könnte: habe ich ein Problem wenn sich die DCs (somit auch DHCP und DNS) in verschiedenen Netzen befinden? Die DNS Replikation kann ich vorerst abdrehen, ist aber nicht eine langfristige Lösung, wäre nur gut zu wissen, ob da was schief laufen kann? Aus meiner Sicht nicht, da DNS lediglich "Einträge" sind, die ich im schlimmsten Fall wieder korrigieren kann, sollte was nicht funktionieren.

Oder?

 

Und kann eventuell 2012R2 eine IP Übersetzung (N:1-NAT) machen? Also zB. die ersten 3 Octets wenn bspw. 10.146.32.x eingetippt wird, automatisch in 10.241.56.x umzuwandeln? Ich kenne leider 2012R2 Router nicht so gut. Ob das überhaupt Sinn macht ist ne andere Sache...

bearbeitet 28. April 2017 von kosta88

[Vinc211 1]

Ich versuche grade zu verstehen warum du überhaupt über NAT und Übersetzung sprichst. 2 seperate Netze wären doch auch vollkommen okay wenn ein Site to Site VPN zwischen den Gateways beides Netze besteht. DHCP könnten dann sowohl die DC's oder die Gateways übernehmen und DNS wäre überhaupt kein Problem.Der Grund der NEtzübersetzung ist mir nicht ganz klar.

[kosta88 2]

Ja, es ist eine berechtigte Frage.

Die Site-to-Site habe nicht ich eingerichtet, sondern die LANCOM Kollegen vom RZ. Aber meine Vermutung ist weil das RZ Netz nicht auf unser lokales Netz, aus welchen Grund auch immer, nicht zugreifen kann. Aber RZ kann auf das eingerichtete Client-Nezt (10.241.56.0) zugreifen. Daher ist diese Übersetzung eingerichtet, um die Clients im lokalen Netzwerk zugfreifen zu können. Daher wird es auch notwendig sein, um DNS aus dem RZ in das lokale Netz zugreifen zu können.

Soweit ich das verstehe, unser 10.146.32.0/24 Netz kann im RZ nicht als Client-Netz eingerichtet werden.

 

Allerdings, es gibt eine offene Frage, die mir derzeit keiner wirklich beantworten kann - lt. Info die so "herumschwebt" ist derzeit "nur" ein Point-to-Site eingerichtet. Dazu finde ich aber keine Spuren im LANCOM Router, und sehe nur eine Site-to-Site Verbindung eingerichtet. Lt. Infos muss im RZ noch etwas umgestellt werden, damit der Weg auch sozusagen rückwärts funktioniert (also damit ich 10.146.32.0 zugreifen kann).

 

Aber wie schon erwähnt, wenn die statische Route eingerichtet wird, kann ich die Clients im lokalen Netz über die übersetzte IP (10.241.56.0) zugreifen, ansonsten funktioniert es nicht (also rede ich hier von N:1-NAT).

 

Deswegen schieb ich auch über die gleiche Funktion aus dem RZ -> lokal. Aber es ist wahrscheinlich komplett Sinnfrei, da wenn die Adresse einmal NAT (oder in diesem Fall PAT) passiert hat, hat sie die Adresse aus dem Client-Netz, und alle Anfragen von dort müssen in dem Client-Netz bleiben.

 

Am Beispiel der DHCP-Abfrage, angenommen lokale DC ist ausgefallen.

1) Client broadcastet nach einem DHCP, LANCOM Router ist der einzige der sich meldet, hat eine Weiterleitung nach Priorität eingerichtet (1. lokale DC, 2. DC im RZ)

2) Paket wird an die IP des DC geschickt (REQUEST) - die IP des Clients wird am LANCOM in 10.241.56.x übersetzt

3) DHCP in RZ bekommt die Anfrage mit 10.241.56.x und schickt dann an 10.241.56.x die Antwort (Offer) retour, dass die IP vergeben werden kann

4) Geht retour (Request), Client kann ja nur wieder mit 10.146.32.x antworten, wird übersetzt...

5) ACK vom DHCP an den Client

 

Beim DNS sehe ich nur Bedarf alle Weiterleitungen und DHCP DNS Einstellung ordentlich eingerichtet zu haben. D.h. in jeden Fall muss so sein, dass wenn die Anfrage irgendwo eintrifft, und es muss so sein dass die Clients alle DNS Server sowohl eingetragen (passiert ja via DHCP) wie auch erreichbar haben, die Antwort auch an die Clients zurück kommt.

 

Nicht falsch verstehen, ich versuche das Thema einfach im Kopf zu "sortieren", damit ich ohne viel Probleme die DC-Umstellung machen kann (siehe anderer Thread zum Thema DC-Problem).

bearbeitet 28. April 2017 von kosta88

[Vinc211 1]

Ist auf beiden Seiten ein Router der Punkt für die Site to Site?

 

DHCP Request vom Router übersetzen lassen und das auf hin und rückweg würde ich ganz spontan als nicht machbar bereichnen. Weil das nicht über IP läuft und generell einfach keine gute Idee ist.

 

Das ganze was du da hast scheint ziemlich verworren und ich würde grade einfach alles über den haufen werfen und neu machen =D Diese Netz IP geschichte ergibt für mich keinen Sinn.

Auch schwierig dass du anscheinend nicht Zugriff auf alles hast und dich über Netzwerkthemen mit einem Dienstleister austauschen musst.

 

Eventuell solltest du erstmal 2 sauber und saubere von einander getrennte Netzwerke herstellen die dann komplett und ohne Einschränkungen und ohne NAT/PAT etc miteinander verbunden sind.

Danach kannst du dir gedanken machen wie DHCP, DNS etc laufen.

 

Wenn der lokale DC ausfällt und kein DHCO Cluster im lokalen Netz besteht würde ich sagen das die Rechner die dann online gehen schlichtweg kein DHCP bekommen. Was ich auch eher dann als sekundäres Problem sehe da Prio 1 ist den DC wieder zum laufen zu bekommen.

[kosta88 2]

Ist auf beiden Seiten ein Router der Punkt für die Site to Site?

Kann ich leider nicht ganz bestätigen.

 

DHCP Request vom Router übersetzen lassen und das auf hin und rückweg würde ich ganz spontan als nicht machbar bereichnen. Weil das nicht über IP läuft und generell einfach keine gute Idee ist.

Dann verstehe ich das so: dafür dürfte man keine Übersetzung mehr machen, und das Netz 10.146.32.0 müsste man ohne jegliche Eingriffe (also nur die statische Route für den VPN-Gateway) aus dem Netz 10.241.56.0 erreichen können. Bin mir nicht sicher ob das funktioniert.

 

Das ganze was du da hast scheint ziemlich verworren und ich würde grade einfach alles über den haufen werfen und neu machen =D

Würde ich sowas machen können, würde ich. Jedoch sind wir leider sehr stark an unser Mutterkonzern angewiesen. Wir sind zwar ein eigenständiges Unternehmen, jedoch können wir nicht beliebig wie wir nur wollen die Netze erstellen. Die zwei ganz oben genannten Netze können nicht geändert werden, und das Netz im RZ auch nicht. Alles sind fix vorgegebene Werte. Ich *muss* drumherum arbeiten.

Der Dienstleister ist unser Mutterkonzern, aber das Verhältnis spielt jetzt hier keine Rolle wirklich.

 

Wenn der lokale DC ausfällt und kein DHCO Cluster im lokalen Netz besteht würde ich sagen das die Rechner die dann online gehen schlichtweg kein DHCP bekommen.

2. Server ist nicht angedacht, hier handelt es sich um einen relativ alten HP DL380 G7, und dieser wird auch nicht erweitert. Deswegen wird dieser lediglich als lokaler Server genutzt, um die Auslastung der WAN Verbindung zu vermeiden, die über Mobilfunk geht.

 

Sollte die S2S (die ja über Mobilfunk geht) relativ leicht ausfallen, dann haben wir kein DC, wenn der lokale DC nicht läuft - und das will ich damit vermeiden.

Ursprunglich war es so angedacht dass wir den DC NUR im RZ haben. Jedoch bin ich mit der Idee gekommen, den lokalen DC auch zu machen, um gewisse Redundanz und die WAN zu entlasten.

Also auch wäre der lokale DC nicht da, müsste man die Lösung mit dem DC im RZ hinbekommen, und die Problematik mit 2 verschiedenen Netzen besteht weiterhin.

[kosta88 2]

Eventuell solltest du erstmal 2 sauber und saubere von einander getrennte Netzwerke herstellen die dann komplett und ohne Einschränkungen und ohne NAT/PAT etc miteinander verbunden sind.

Danach kannst du dir gedanken machen wie DHCP, DNS etc laufen.

Ich glaube jedoch dass das hier der Knackpunkt ist - ich befürchte ohne PAT wird das nicht gehen, da wenn das Client-Netzwerk auf dem VPN Termininierungs-Punkt im RZ unserem Netz nicht entsprechen kann, wird das ohne Übersetzung auf unserer Seite nicht funktionieren - wir müssen uns an das Client-Netz im RZ anpassen, und da wir das lokale Netz NICHT ändern können, können wir ja nur übersetzen.

[lefg 276]

 

Ich sehe ggf. Probleme beim DNS:

 

Moin

 

Der Ping geht aber an eine IP-Adresse, kann da der DNS für eine Auflösung von Rechnername auf IP-Adresse eine Rolle spielen?

 

Ich fragte mich wohl so,

 

geht die gesendete Nachricht den richtigen Weg,

 

kommt sie beim Empfänger an?

 

Wohin sendet dieser die Anwort? Auf die richtige Route dafür?

 

Ist die richtige Route dafür eingerichtet? Führt diese tatsächlich zur Gegenstelle?

 

Findet da am LANCOM ein Splitting statt?

 

 

Der Beschreibung in der Eröffnung des Thread kann ich leider nicht folgen.

 

Meist stellt man sowas auch grafisch dar.

Möglicherweise begänne ich mit mit einer Zeichnung, machte mit einer Simulation weiter.

 

Wahrscheinlich installierte ich auf den beiden DCs auch PRTG.

 

Wahrscheinlich hätte ich am "Coreswitch" meiner Niederlassung einen Monitorport, daran einen Rechner mit PRTG. Am Switch könnte ich beliebig den Mirrorport ändern je nach Bedarf.

 

Mit PRTG kann man sehr schön auch das Netz, die Netze mit allen adressierbaren Elementen grafisch darstellen.

 

Falls ich aber zum Messen, zur Analyse nur den nassen Finger hätte, ...... weiss ich im Moment nicht, vielleicht fiel mir ja noch was ein. :)

bearbeitet 29. April 2017 von lefg

[kosta88 2]

Ich habe mir erlaubt Visio als Alternative mit der ich mich auskenne zu benutzen :)

 

 

Die statische Route ist notwendig, und zwar als 10.146.32.0/24 10.241.56.251 (VPN Gateway).

Wichtig zu verstehen ist eines:

Nach die Route gesetzt wurde, kann ich die Clients nicht mit ihrer echten IP, sondern nur via übersetzter IP (Client-Netz-IP im RZ) zugreifen.

ABER, aus irgendeinem Grund konnte ich einen Rechner den ich probiert habe, via DNS-Namen anpingen. Die angezeigte IP war jedoch aus dem Client-Netz Bereich.

D.h. irgendwo werden die Einträge gepflegt, also es gibt eventuell irgendwo ein DNS im Client-Netz, und dieser sorgt dafür, dass ein "Client01.domain.local" mit der original-IP bspw. 10.146.32.10 den Eintrag client01.domain.local 10.241.56.10 bekommt, und so abgefragt werden kann.

Würde erklären warum ich aus dem Server-Netz im RZ die IP 10.146.32.10 nicht pingen kann, aber wohl client01.domain.local (oder nur client01 sofern ich die DNS-suffixe eingetragen habe), und dieser antwortet als 10.241.56.10.

 

Nun zu den Fragen, ich versuche sie nach meinen besten Fähigkeiten zu beantworten.

 

geht die gesendete Nachricht den richtigen Weg, kommt sie beim Empfänger an?

Der einzige Bereich von der interne DNS Rolle spielt ist eigentlich 10.146.32.0/24 Netz. Im Server-Netz im RZ wird man nur ggf. ins Internet gehen, und das ist leicht zu lösen.

Wichtig ist nur, dass die Anfragen, sollte der lokale DNS ausfallen, 1. den Weg zum RZ-DNS und 2. retour finden.

1. Wohl, im Client zwei DNS einrichten:

- DNS lokal

- DNS RZ

2. unsicher

- die statische Route sorgt dafür dass wenn DNS im RZ nach der IP aus dem 10.146.32.0 sucht, diese Anfrage über dem VPN Gateway geht, womit auch per hostname die Adresse auffindbar ist (siehe oben die Erklärung), jedoch NICHT per IP (um per IP zu finden, muss man Client-Netz berücksichtigen)

 

Wohin sendet dieser die Anwort? Auf die richtige Route dafür?

Da beginnt genau mein Problem, ich kenne nicht genau wie die Pakete aussehen, bzw. wie sich das hier verhält. Helfe mir zu verstehen bitte. Beispiel:

Schritt 1: client01 mit IP 10.146.32.10 sendet die Anfrage an RZ-DNS: "wer ist" server01

Schritt 2: LANCOM übersetzt die IP von 10.146.32.10 in 10.241.56.10, vermutlich wird die dann im Client-Netz auch als "client01.domain.local" bekannt ("geheimer" DNS?)

Schritt 3: RZ-DNS bekommt die Anfrage, jedoch von wem als Quelle: 10.146.32.0 ODER 10.241.56.0??? (inwischen ist am LANCOM die Übersetzung passiert, wirkt sich das auf das DNS-Paket, bzw. wem DNS als Quelle sieht?)

Schritt 4: RZ-DNS sendet die IP-Adresse des server01 retour, jedoch an wem? Versucht DNS den "client01", oder 10.146.32.x oder 10.241.56.x zu erreichen? (hängt wohl davon ab, was passiert mit dem DNS-Paket genau bei der N:1-NAT Übersetzung).

 

Ist die richtige Route dafür eingerichtet? Führt diese tatsächlich zur Gegenstelle?

Das behaupte ich schon. Die Route via VPN-Gateway scheint zu funktionieren, siehe ganz oben wegen Erreichbarkeit.

 

Findet da am LANCOM ein Splitting statt?

Was ist das?

 

[magheinz 100]

hats du denn auch Zugriff auf die Routingtabellen der Routinginstanzen im RZ?

 

Wofür du hier Natest bleibt mir aber unklar.

Das ist doch simples routing über ein Transfernetz(VPN).

 

[lefg 276]

Moin

 

Das mit der Port-oder Adresstranslation erstaunt mich (auch). Ich meine, für diesen Zweck wird da keine benötigt, geghört da keine hin. Übewrsetzung erfolgt erstmal von "drinnen" nach "draussen", dann ist da auch die Rückübersetzung gesichert. Aber andersrum??

 

@Kosta, ich hab mir ddie Beschreibung in #9 nicht im Einzelnen durchgelesen, das ist für meine Augen zuviel.

bearbeitet 30. April 2017 von lefg

[kosta88 2]

hats du denn auch Zugriff auf die Routingtabellen der Routinginstanzen im RZ? Wofür du hier Natest bleibt mir aber unklar. Das ist doch simples routing über ein Transfernetz(VPN).

Ich muss ehrlich sagen, ich weiß nicht wovon du sprichst wenn du von Routinginstanzen sprichst.

Mein Netzwerk-Wissen reicht für das Thema sicher nicht ganz genug, so kann ich teilweise nur von Aussagen anderer gehen.

 

Aber das Thema NAT (also PAT) in meinem Beispiel ist mir doch irgendwie logisch. RZ kann unser Netz, also 10.146.32.0/24 sozusagen nicht "durchlassen", was auch logisch klingt, denn was würde passieren, wenn ein anderer Kunde auch den selben Bereich nutzt, speziell weil der VPN-Terminierungs-Punkt mit anderen Kunden geteilt ist.

Deswegen vergibt uns RZ das Client-Netz, um die Clients in unserem Netzwerk doch mit einer IP - der übersetzter IP - erreichen zu können.

 

Simples Routing wäre das, wenn RZ unser 10.146.32.0 kennen würde (ansprechen könnte), dann wäre das ganze ohne jeglichen Problem.

 

Oder sehe ich das falsch?

Moin

 

Das mit der Port-oder Adresstranslation erstaunt mich (auch). Ich meine, für diesen Zweck wird da keine benötigt, geghört da keine hin. Übewrsetzung erfolgt erstmal von "drinnen" nach "draussen", dann ist da auch die Rückübersetzung gesichert. Aber andersrum??

 

@Kosta, ich hab mir ddie Beschreibung in #9 nicht im Einzelnen durchgelesen, das ist für meine Augen zuviel.

Kein Problem :) Ich weiß, das Thema verdreht mir auch die Augen.

 

Wäre die PAT nicht vorhanden, würde ich die Clients aus 10.146.32.0 auf gar keine Weise erreichen können. Das Netz ist aus dem RZ nicht auffindbar/erreichbar.

Ich kann das gerne nächste Woche ausprobieren, also die Übersetzung entfernen.

 

Das hier ist eine Übersetzung von drinnen (10.146.32.0) nach draussen (10.241.56.0). Es gibt keine (eingerichtete) Rückübersetzung auf dem LANCOM - ob die automatisch geschieht, das weiß ich nicht.

bearbeitet 30. April 2017 von kosta88

[lefg 276]

OK, klammern wir das PAT momentan mal aus.

 

Welche Geräte sind 32.1 und 56.1?

 

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

 

"Verstehn" sich die beiden DC miteinander?

 

Ist der RZDC vom LANDC aus pingbar? Kommt die Antwort?

 

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

bearbeitet 30. April 2017 von lefg

[magheinz 100]

Es gib

 

Ich muss ehrlich sagen, ich weiß nicht wovon du sprichst wenn du von Routinginstanzen sprichst.

Mein Netzwerk-Wissen reicht für das Thema sicher nicht ganz genug, so kann ich teilweise nur von Aussagen anderer gehen.

 

Aber das Thema NAT (also PAT) in meinem Beispiel ist mir doch irgendwie logisch. RZ kann unser Netz, also 10.146.32.0/24 sozusagen nicht "durchlassen", was auch logisch klingt, denn was würde passieren, wenn ein anderer Kunde auch den selben Bereich nutzt, speziell weil der VPN-Terminierungs-Punkt mit anderen Kunden geteilt ist.

Deswegen vergibt uns RZ das Client-Netz, um die Clients in unserem Netzwerk doch mit einer IP - der übersetzter IP - erreichen zu können.

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.

[NorbertFe 1.799]

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