5
VPN Verbindung von Terminalserver in Kundennetz (gleiches Subnetz)
Hallo Gemeinde,
wir haben derzeit eine eigentlich kleine Geschichte die mir ein paar Knoten ins Netzwerkhirn machen
Folgender Hintergrund erstmal:
Wir müssen eine Maschine von unserer Firma im Netzwerk eines Kunden fernwarten. Hierzu stellt uns der Kunde einen VPN Zugang zur Verfügung.
In unserem Firmennetzwerk wurde das bisher über die einzelnen Maschinen der jeweiligen Mitarbeiter gelöst was aber abgeschafft werden soll. Geplant ist eine VM die als "Fernwartungsrechner" fungieren soll. Darauf läuft Windows 7.
Die Mitarbeiter greifen nun auf den Fernwartungsrechner per MSTSC zu (IP-Adresse: 10.10.11.20 Subnetzmaske: 255.255.0.0)
Nun wird von dieser VM eine VPN Verbindung zum Kunden aufgebaut. Das Kundennetz ist 10.0.0.0 mit Subnetzmaske 255.0.0.0 also liegt unser Netz innerhalb des Subnetzes vom Kunden.
Die VM kann die Verbindung erfolgreich herstellen und erreicht auch die Maschine im Kundennetzwerk, jedoch bricht die Remoteverbindung vom Mitarbeiter zum Fernwartungsrechner natürlich ab nachdem dieser in das Netz vom Kunden Verbindung hat. Die VM ist dann nur noch über die VMWare Konsole erreichbar und nach Trennung der VPN Verbindung auch wieder im Netz ansprechbar.
Meine Lösung (theoretisch) sieht wie folgt aus:
-Der Fernwartungsrechner braucht einen Routeneintrag, der besagt dass die IPs im Bereich 10.10.11.0-255 in unserem eigenen Netzwerk sind. In dieser Range befinden sich auch die Rechner der Mitarbeiter welche die Verbindung zum Fernwartungsrechner aufbauen wollen.
Meine Frage ist demnach:
-Ist meine Lösung so in der Theorie korrekt?
-Wie wird das praktisch umgesetzt? Ich habe versucht verschiedene Routeneinträge zu setzen, bislang aber ohne Erfolg.
Ich bin dankbar für jede Hilfe und versuche alle geforderten Informationen aufzutreiben wenn ihr weitere benötigt!
Vielen Dank!
Grüße
Jochen
wir haben derzeit eine eigentlich kleine Geschichte die mir ein paar Knoten ins Netzwerkhirn machen
Folgender Hintergrund erstmal:
Wir müssen eine Maschine von unserer Firma im Netzwerk eines Kunden fernwarten. Hierzu stellt uns der Kunde einen VPN Zugang zur Verfügung.
In unserem Firmennetzwerk wurde das bisher über die einzelnen Maschinen der jeweiligen Mitarbeiter gelöst was aber abgeschafft werden soll. Geplant ist eine VM die als "Fernwartungsrechner" fungieren soll. Darauf läuft Windows 7.
Die Mitarbeiter greifen nun auf den Fernwartungsrechner per MSTSC zu (IP-Adresse: 10.10.11.20 Subnetzmaske: 255.255.0.0)
Nun wird von dieser VM eine VPN Verbindung zum Kunden aufgebaut. Das Kundennetz ist 10.0.0.0 mit Subnetzmaske 255.0.0.0 also liegt unser Netz innerhalb des Subnetzes vom Kunden.
Die VM kann die Verbindung erfolgreich herstellen und erreicht auch die Maschine im Kundennetzwerk, jedoch bricht die Remoteverbindung vom Mitarbeiter zum Fernwartungsrechner natürlich ab nachdem dieser in das Netz vom Kunden Verbindung hat. Die VM ist dann nur noch über die VMWare Konsole erreichbar und nach Trennung der VPN Verbindung auch wieder im Netz ansprechbar.
Meine Lösung (theoretisch) sieht wie folgt aus:
-Der Fernwartungsrechner braucht einen Routeneintrag, der besagt dass die IPs im Bereich 10.10.11.0-255 in unserem eigenen Netzwerk sind. In dieser Range befinden sich auch die Rechner der Mitarbeiter welche die Verbindung zum Fernwartungsrechner aufbauen wollen.
Meine Frage ist demnach:
-Ist meine Lösung so in der Theorie korrekt?
-Wie wird das praktisch umgesetzt? Ich habe versucht verschiedene Routeneinträge zu setzen, bislang aber ohne Erfolg.
Ich bin dankbar für jede Hilfe und versuche alle geforderten Informationen aufzutreiben wenn ihr weitere benötigt!
Vielen Dank!
Grüße
Jochen
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 217617
Url: https://administrator.de/forum/vpn-verbindung-von-terminalserver-in-kundennetz-gleiches-subnetz-217617.html
Ausgedruckt am: 31.12.2024 um 19:12 Uhr
5 Kommentare
Neuester Kommentar
Das kannst du nur mit NAT (Adress Translation) lösen !! Eine andere Option hast du nicht, denn du hast immer das Problem der doppelten IP Netze.
Generell ist dein VM Netzwerk IP Design nicht gerade intelligent gewählt, denn du wirst immer in den Konflikt einer 8 Bit Maske kommen beim 10er Netz.
Auch das du gerade einen 16 Bit Maske für das VM VPN Netz gewählt hast war nicht gerade klug und weise und birgt schon Probleme in der Adressierung in sich.
Leider kann man hier nicht auf "IP Intelligenz" bei laienhaften Endkunden setzen, deshalb macht es Sinn das eigene VPN Netzwerk etwas intelligenter zu wählen mit einer "exotischen" IP Adresse im 192er Bereich wie z.B. 192.168.237.0 /24 Das 3te Byte sollte schon etwas "unüblich" sein. Alternativ kann man einen 172er IP mit 24 Bit Maske nehmen ala 172.27.243.0 /24 Allerdings hast du hier wieder das erhöhte Risiko das ein Kunde die 172.27 mit einer 16 Bit Maske benutzt. Da musst du abwägen.
Details beschreibt das Tutorial:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
im Kapitel "Allgemeine Tips zum VPN Design" am Ende !
Deine Lösung und deine Theorie ist deshalb grundfalsch, denn der Kundenrechner kann bei den Antwortpaketen die er senden müsste niemals mehr unterscheiden ob das ein Paket für sein lokales LAN oder das remote (bei euch) ist. Außerdem kann der Router mit diesen doppelten IPs natürlich nix mehr routen. Aus dem Dilemma kommst du nur mit statischem NAT raus.
Genau deshalb führen deine verzweifelten Versuche mit Routen auch nicht zum Erfolg. Können sie ja auch logischerweise nicht, denn die IP Adressdopplung und die damit verbundene Unroutebarkeit der Pakete kannst du damit ja niemals aufheben !
Dein Fehler ist schon viel früher beim falschen IP Adressdesign gemacht worden !! Da musst du ansetzen oder eben NAT machen.
Fazit: Mach einen NAT Pool auf auf deinem Router und NATe deine IP Netzwerk im Tunnel, dann funktioniert das fehlerfrei:
Noch besser für die Zukunft: Wähle ein etwas intelligenteres IP Adress Schema für dein VM VPN Netz.
Wenn du nur einen einzigen Fernwartungshost hast musst du ja nicht sinnloserweise und unüberlegt eine 16 Bit Maske verwenden. Da tut es ja eine erheblich kleinere Maske mit 27 oder 28 Bit auch wie Kollege certifiedit unten auch schon richtig bemerkt.
In Kombination mit einer etwas exotischeren Netzadresse bist du da ziemlich wasserdicht gerüstet für deinen Fernwartungszukunft.
Das 10er Design hat vermutlich einer im Schnellschuss ohne nachdenken gemacht.
Generell ist dein VM Netzwerk IP Design nicht gerade intelligent gewählt, denn du wirst immer in den Konflikt einer 8 Bit Maske kommen beim 10er Netz.
Auch das du gerade einen 16 Bit Maske für das VM VPN Netz gewählt hast war nicht gerade klug und weise und birgt schon Probleme in der Adressierung in sich.
Leider kann man hier nicht auf "IP Intelligenz" bei laienhaften Endkunden setzen, deshalb macht es Sinn das eigene VPN Netzwerk etwas intelligenter zu wählen mit einer "exotischen" IP Adresse im 192er Bereich wie z.B. 192.168.237.0 /24 Das 3te Byte sollte schon etwas "unüblich" sein. Alternativ kann man einen 172er IP mit 24 Bit Maske nehmen ala 172.27.243.0 /24 Allerdings hast du hier wieder das erhöhte Risiko das ein Kunde die 172.27 mit einer 16 Bit Maske benutzt. Da musst du abwägen.
Details beschreibt das Tutorial:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
im Kapitel "Allgemeine Tips zum VPN Design" am Ende !
Deine Lösung und deine Theorie ist deshalb grundfalsch, denn der Kundenrechner kann bei den Antwortpaketen die er senden müsste niemals mehr unterscheiden ob das ein Paket für sein lokales LAN oder das remote (bei euch) ist. Außerdem kann der Router mit diesen doppelten IPs natürlich nix mehr routen. Aus dem Dilemma kommst du nur mit statischem NAT raus.
Genau deshalb führen deine verzweifelten Versuche mit Routen auch nicht zum Erfolg. Können sie ja auch logischerweise nicht, denn die IP Adressdopplung und die damit verbundene Unroutebarkeit der Pakete kannst du damit ja niemals aufheben !
Dein Fehler ist schon viel früher beim falschen IP Adressdesign gemacht worden !! Da musst du ansetzen oder eben NAT machen.
Fazit: Mach einen NAT Pool auf auf deinem Router und NATe deine IP Netzwerk im Tunnel, dann funktioniert das fehlerfrei:
Noch besser für die Zukunft: Wähle ein etwas intelligenteres IP Adress Schema für dein VM VPN Netz.
Wenn du nur einen einzigen Fernwartungshost hast musst du ja nicht sinnloserweise und unüberlegt eine 16 Bit Maske verwenden. Da tut es ja eine erheblich kleinere Maske mit 27 oder 28 Bit auch wie Kollege certifiedit unten auch schon richtig bemerkt.
In Kombination mit einer etwas exotischeren Netzadresse bist du da ziemlich wasserdicht gerüstet für deinen Fernwartungszukunft.
Das 10er Design hat vermutlich einer im Schnellschuss ohne nachdenken gemacht.
IP Calculating? Wieso braucht der Kunde 16777214 IP-Adressen? Wie groß ist der denn?
1
Danke euch schonmal für die Antworten.
Ich denke, dass wir den Weg gehen werden den Fernwartungsrechner in ein anderes Netz zu nehmen. Es war einfach der bequemste Weg ihn in unseren Adressbereich für Clients mit einzupflegen (Wir brauchen von der Firmengröße das /16 er Netz und der Kunde ist ein solch namhafter dass man ihm zutraut eine große Anzahl Adressen zu benötigen).
Ich verstehe unseren Fehler beim IP Adressdesign nicht ganz. Wir haben doch das Netz beim Kunden nicht gewählt? Beim Design unseres Netzes hat damals noch keiner an einen Fernwartungsrechner gedacht. Die Rechner die Verbindung direkt aufbauen haben ja keine Probleme damit, außer dass sie bei hergestellter VPN Verbindung nicht auf die internen Server zugreifen können (Ist und wird aber auch keine Anforderung sein).
Danke Aqui für die Lösung und den Text, das kann ich als Argument für einen neuen Adressbereich nehmen!
Ich denke, dass wir den Weg gehen werden den Fernwartungsrechner in ein anderes Netz zu nehmen. Es war einfach der bequemste Weg ihn in unseren Adressbereich für Clients mit einzupflegen (Wir brauchen von der Firmengröße das /16 er Netz und der Kunde ist ein solch namhafter dass man ihm zutraut eine große Anzahl Adressen zu benötigen).
Ich verstehe unseren Fehler beim IP Adressdesign nicht ganz. Wir haben doch das Netz beim Kunden nicht gewählt? Beim Design unseres Netzes hat damals noch keiner an einen Fernwartungsrechner gedacht. Die Rechner die Verbindung direkt aufbauen haben ja keine Probleme damit, außer dass sie bei hergestellter VPN Verbindung nicht auf die internen Server zugreifen können (Ist und wird aber auch keine Anforderung sein).
Danke Aqui für die Lösung und den Text, das kann ich als Argument für einen neuen Adressbereich nehmen!
Oha...mehrere Kardinalsfehler in eurem Netz:
"...Wir brauchen von der Firmengröße das /16 er Netz und der Kunde ist ein solch namhafter dass man ihm zutraut eine große Anzahl Adressen zu benötigen"
Generell ist das völliger Unsinn und auch kontraproduktiv so ein netzwerk Design anzugehen. Das zeugt eher von sehr wenig Fachwissen denn von verantwortungsvollen netzwerkern, sorry !
Wenn die Fa. wirklich so groß ist, dann segmentiert man immer solch ein Netz mit VLANs. Allein schon aus Sicherheitsgründen ist das zwingend.
Keine Layer 2 Broadcast Domain sollte mehr als 200 bis 250 Endgeräte haben ! So gehen jedenfalls erfahrende Netzwerkplaner vor.
Was du da oben machst einfach nur die Subnetzmaske entsprechend groß wählen und ein dummes und flaches Layer 2 Netzwerk in einer Broadcast Doamin zu schaffen ist per se schon dilettantischer Unsinn in einem größeren Firmennetz.
Sowas rächt sich dann meistens später auch in schlechter Performance und Unflexibilität, wie eben jetzt mit dem VPN Design.
Da solltet ihr also nochmal wirklich überlegen ob ihr da in puncto Netzdesign auf dem richtigen Wege seit...so wie es sich anhört ist das eher ne Sackgasse ?!
Das aber nur nebenbei....
Genau das erklärt auch solche Aussagen wie "er bequemste Weg ihn in unseren Adressbereich für Clients mit einzupflegen" und "Design unseres Netzes hat damals noch keiner an einen Fernwartungsrechner gedacht." Sorry, so denken IT Laien aber keine Netzwerker die größere Kundenentze betreuen.
Mit einem gerouteten (VLAN) Backbone kannst du solche zusätzlichen Netze problemlos integrieren und auch vom Produktivnetz abtrennen.
Vielleicht riskierst du mal einen Blick in ein entsprechendes Grundlagentutorial für solch ein Design.
Du darfst ja nicht vergessen das bei aktiver VPN Verbindung zum Kunden es eine direkte Netzkopplung beider Netze gibt.
Welches Unternehmen möchte denn wirklich ein fremdes Kundennetz in seinem Produktivnetz haben was noch nichtmal segmentiert ist wie bei euch ??
In der Regel wäre sowas bei größeren Unternehmen ein sofortiger Kündigungsgrund für einen IT Netzwerk Verantwortlichen wer so fahrlässig vorgeht.
Gut...bei einer größeren Würstchenbude ist das vernachlässigbar...keine Frage !
"...Wir brauchen von der Firmengröße das /16 er Netz und der Kunde ist ein solch namhafter dass man ihm zutraut eine große Anzahl Adressen zu benötigen"
Generell ist das völliger Unsinn und auch kontraproduktiv so ein netzwerk Design anzugehen. Das zeugt eher von sehr wenig Fachwissen denn von verantwortungsvollen netzwerkern, sorry !
Wenn die Fa. wirklich so groß ist, dann segmentiert man immer solch ein Netz mit VLANs. Allein schon aus Sicherheitsgründen ist das zwingend.
Keine Layer 2 Broadcast Domain sollte mehr als 200 bis 250 Endgeräte haben ! So gehen jedenfalls erfahrende Netzwerkplaner vor.
Was du da oben machst einfach nur die Subnetzmaske entsprechend groß wählen und ein dummes und flaches Layer 2 Netzwerk in einer Broadcast Doamin zu schaffen ist per se schon dilettantischer Unsinn in einem größeren Firmennetz.
Sowas rächt sich dann meistens später auch in schlechter Performance und Unflexibilität, wie eben jetzt mit dem VPN Design.
Da solltet ihr also nochmal wirklich überlegen ob ihr da in puncto Netzdesign auf dem richtigen Wege seit...so wie es sich anhört ist das eher ne Sackgasse ?!
Das aber nur nebenbei....
Genau das erklärt auch solche Aussagen wie "er bequemste Weg ihn in unseren Adressbereich für Clients mit einzupflegen" und "Design unseres Netzes hat damals noch keiner an einen Fernwartungsrechner gedacht." Sorry, so denken IT Laien aber keine Netzwerker die größere Kundenentze betreuen.
Mit einem gerouteten (VLAN) Backbone kannst du solche zusätzlichen Netze problemlos integrieren und auch vom Produktivnetz abtrennen.
Vielleicht riskierst du mal einen Blick in ein entsprechendes Grundlagentutorial für solch ein Design.
Du darfst ja nicht vergessen das bei aktiver VPN Verbindung zum Kunden es eine direkte Netzkopplung beider Netze gibt.
Welches Unternehmen möchte denn wirklich ein fremdes Kundennetz in seinem Produktivnetz haben was noch nichtmal segmentiert ist wie bei euch ??
In der Regel wäre sowas bei größeren Unternehmen ein sofortiger Kündigungsgrund für einen IT Netzwerk Verantwortlichen wer so fahrlässig vorgeht.
Gut...bei einer größeren Würstchenbude ist das vernachlässigbar...keine Frage !
2
Deine Argumente leuchten mir ein.
Ich werde das in unserer nächsten Sitzung mal ansprechen. Die Netzplanung wurde damals mit einem externen Dienstleister vorgenommen, da waren wir "kleinen Lichter" leider nicht involviert. Das ganze im Nachhinein zu hinterfragen steht mir allerdings zu
Hab die ersten Worte aus deinem Link mal überflogen (werde ich aber nochmal genauer lesen, sieht interessant aus) und denke dass wir Hardwareseitig schonmal mit Cisco und Konsorten alle Voraussetzungen erfüllen die Infrastruktur gescheit umkrempeln zu können.
Bis dahin wird sich wohl mit dem Fernwartungsrechner erst mal nichts ergeben..
Ich werde das in unserer nächsten Sitzung mal ansprechen. Die Netzplanung wurde damals mit einem externen Dienstleister vorgenommen, da waren wir "kleinen Lichter" leider nicht involviert. Das ganze im Nachhinein zu hinterfragen steht mir allerdings zu
Hab die ersten Worte aus deinem Link mal überflogen (werde ich aber nochmal genauer lesen, sieht interessant aus) und denke dass wir Hardwareseitig schonmal mit Cisco und Konsorten alle Voraussetzungen erfüllen die Infrastruktur gescheit umkrempeln zu können.
Bis dahin wird sich wohl mit dem Fernwartungsrechner erst mal nichts ergeben..
