kosta88 2 Geschrieben 1. Mai 2017 Autor Melden Teilen Geschrieben 1. Mai 2017 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? Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 1. Mai 2017 Melden Teilen Geschrieben 1. Mai 2017 Punkt zwei ist mir schleierhaft. Du hast doch drei Netze 1. LAN lokal 2. VPN 3. LAN RZ Jetzt muss du doch nur dem router im LAN Lokal sagen das er das LAN RZ über das VPN erreicht und umgekehrt, also: Router im "LAN lokal"(LANCOM1) bekommt als route: "LAN RZ" über GW "VPN-Punkt lokal" Router im "LAN" RZbekommt als route: "LAN lokal" über GW "VPN-Punkt RZ" das muss aber der router im RZ wissen, nicht der Server. Wenn der router auch gleichzeitig der VPN-Endpunkt ist macht er das vermutlich eh von alleine. Der RZ-Router ist vermutlich eh das default-GW des Servers. Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 2. Mai 2017 Autor Melden Teilen Geschrieben 2. Mai 2017 (bearbeitet) 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. bearbeitet 2. Mai 2017 von kosta88 Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 2. Mai 2017 Melden Teilen Geschrieben 2. Mai 2017 ich dachte 10.241.56.0 ist das VPN? Dann musst du das doch am LANCOM nicht einrichten, Der hat doch schone in Interface in diesem Netz. Übrigens: nicht jedes Gerät im Netz pingt! 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. 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. Im RZ auf dem router musst du dein lokales LAN über die 10.241.56.251 als GW einrichten. 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 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) Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 2. Mai 2017 Autor Melden Teilen Geschrieben 2. Mai 2017 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... Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 2. Mai 2017 Melden Teilen Geschrieben 2. Mai 2017 Router im "LAN lokal"(LANCOM1) bekommt als route: "LAN RZ" über GW "VPN-Punkt lokal" Dieses GW "VPN-Punkt lokal" musst du im RZ als GW angeben. Das ist das was ich als 10.241.56.1 bezeichnet habe. Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 3. Mai 2017 Melden Teilen Geschrieben 3. Mai 2017 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? Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 3. Mai 2017 Autor Melden Teilen Geschrieben 3. Mai 2017 (bearbeitet) 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... bearbeitet 4. Mai 2017 von kosta88 Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 4. Mai 2017 Melden Teilen Geschrieben 4. Mai 2017 mir würde der technetartikel von seite2 genügen um zu meinem chef zu sagen: geht nicht. Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 4. Mai 2017 Melden Teilen Geschrieben 4. Mai 2017 Manche lernen eben nur durch Schmerzen. ;) Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 4. Mai 2017 Melden Teilen Geschrieben 4. Mai 2017 (bearbeitet) 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. Ich leistet Widerstand wo es möglich, passiv und aktiv. Habt keine Angst! Das Risiko für die Kollegen der Danziger Werft war grösser. 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? bearbeitet 4. Mai 2017 von lefg Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 4. Mai 2017 Autor Melden Teilen Geschrieben 4. Mai 2017 (bearbeitet) 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? bearbeitet 4. Mai 2017 von kosta88 Zitieren Link zu diesem Kommentar
magheinz 110 Geschrieben 4. Mai 2017 Melden Teilen Geschrieben 4. Mai 2017 (bearbeitet) Von unserem ehemaligen Chef gibts den Ausspruch: "Was Physik ist bestimme ich". Mein Ansatz wäre einfach: Es funktioniert nicht und MS hilft uns nicht weiter da es nicht supportet ist. Manchmal reicht halt hinweisen nicht aus, manchmal geht halt einfach etwas gar nicht. Was passiert wenn die unteren Reihen es trotzdem macht kann man bei VW sehen. 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. bearbeitet 4. Mai 2017 von magheinz Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 4. Mai 2017 Melden Teilen Geschrieben 4. Mai 2017 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... Ich würde da gar nichts "nach Möglichkeit einrichten", da es nicht sinnvoll funktionieren kann/wird. Und das haben dir jetzt hier schon einige gesagt, und auch belegt. Allein die Länge dieses Threads dürfte dir eigentlich zeigen, dass man das am besten an der Stelle nicht anfaßt. Aber wie gesagt... manche verbiegen sich und die Technik eben immer solange, bis wirklich nix mehr geht und dann ist das Geheule groß. Wenn die Bedingungen eben nicht zur Anforderung passen, sollte man nochmal drüber nachdenken die Anforderungen zu ändern. ;) Bye Norbert Zitieren Link zu diesem Kommentar
kosta88 2 Geschrieben 4. Mai 2017 Autor Melden Teilen Geschrieben 4. Mai 2017 (bearbeitet) 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 :) bearbeitet 4. Mai 2017 von kosta88 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.