13
VPN Lan to Lan, wenn Client Netzadresse identisch
Hallo Zusammen,
brauche mal wieder einen kleinen Denkanstoss!
Zielsetzung ist es, verschiedene Netzwerke via VPN Lan to Lan zu koppeln. Das Problem ist, dass die entfernten Clientnetzwerke die gleiche Netzadressen haben. Alle haben die: 192.168.2.0/24. Das Zielnetzwerk hat die Netzadresse: 192.168.1.0/24.
Zielsetzung ist es, dass von den Client-Netzwerken dieverse Infos im Zielnetz angerufen werden können!
Jetzt leuchtet auch mir ein, dass gleiche Client-Netzadressen keine gut Idee sind! Das Umstricken der Client-Netzadressen aber sehr aufwendig und Fehleranfällig sein wird, da hängt einfach teilweise zu viel dran.
Nun meine Überlegung, eigentlich sollte das Gnaze auch mit den gleichen Client-Netzadressen kein Thema sein, da die Anfragen ja immer aus den Client-Netzen kommt. Umgekehrt, kann dass natürlich nicht gehen, den wenn es z.B. eine gleiche Adresse 2.1 geben, woher soll der VPN-Router wissen, welcher gemeint ist!
Liege ich hier richtig oder alles blödsinn, was ich erzähle?
Danke
brauche mal wieder einen kleinen Denkanstoss!
Zielsetzung ist es, verschiedene Netzwerke via VPN Lan to Lan zu koppeln. Das Problem ist, dass die entfernten Clientnetzwerke die gleiche Netzadressen haben. Alle haben die: 192.168.2.0/24. Das Zielnetzwerk hat die Netzadresse: 192.168.1.0/24.
Zielsetzung ist es, dass von den Client-Netzwerken dieverse Infos im Zielnetz angerufen werden können!
Jetzt leuchtet auch mir ein, dass gleiche Client-Netzadressen keine gut Idee sind! Das Umstricken der Client-Netzadressen aber sehr aufwendig und Fehleranfällig sein wird, da hängt einfach teilweise zu viel dran.
Nun meine Überlegung, eigentlich sollte das Gnaze auch mit den gleichen Client-Netzadressen kein Thema sein, da die Anfragen ja immer aus den Client-Netzen kommt. Umgekehrt, kann dass natürlich nicht gehen, den wenn es z.B. eine gleiche Adresse 2.1 geben, woher soll der VPN-Router wissen, welcher gemeint ist!
Liege ich hier richtig oder alles blödsinn, was ich erzähle?
Danke
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 427407
Url: https://administrator.de/contentid/427407
Printed on: April 25, 2024 at 01:04 o'clock
13 Comments
Latest comment
Hallo,
das kannst Du nur lösen, wenn Du die Adressen änderst. Thema „Rückroute“.
Grüße
lcer
das kannst Du nur lösen, wenn Du die Adressen änderst. Thema „Rückroute“.
Grüße
lcer
Ne schon richtig, dass du oder ein Vorgänger wohl ziemlichen Blödsinn produziert habt. Rate hier aber zu einem Netzwerkgrundlagen Kurs, bevor du dich weiter in der IT-Administration beschäftigst...
Hallo,
Um mehrere Netzwerke per VPN Lan 2 Lan zu koppeln mußt du:
zwingend unterschiedliche IP Address Ranges bei allen beteiligten Netzwerken haben,
oder
du mußt mit Transfernetzen (NAT) arbeiten.
-
Die meiner Meinung nach einzig vernünftige Lösung ist: Ändere die Netzwerkaddressranges und hole die jemand mit ins Boot der sich mit Netzwerken und VPNs auskennt.
CH
Um mehrere Netzwerke per VPN Lan 2 Lan zu koppeln mußt du:
zwingend unterschiedliche IP Address Ranges bei allen beteiligten Netzwerken haben,
oder
du mußt mit Transfernetzen (NAT) arbeiten.
-
Die meiner Meinung nach einzig vernünftige Lösung ist: Ändere die Netzwerkaddressranges und hole die jemand mit ins Boot der sich mit Netzwerken und VPNs auskennt.
CH
certifiedit.net komm mir doch nicht immer wieder mit Grundkurs usw. ich bin ausgebildeter Fachinformatiker. Jedoch Einzelkämpfer und kann daher nicht überall gleich stark sein und kann auch nicht mal eben meinen Kollegen am Schreibtisch fragen. Darf man nicht einfach mal ein blöde Frage stellen ohne gleich als Anfänger zu gelten! Es geht doch nur um ein wenig Brainstorming.
Hast aber Recht, liest sich etwas doof. In Zunkunft werde ich das in meine Überschrift Packen: Ich bin nicht blöd! Möchte nur ein wenig Barin...
Das Ganze war so nie geplant gewesen, die Netzwerke zu koppeln und jetzt haben wir den Salat. Die Rückroute ist das Problem, das dachte ich mir bereits, dass es in der NAT Probleme geben wird. Danke Icer....
Aber ich glaube ich habe eine Lösung: Es geht bei der ganzen Sache um die Ereichbarkeit eines Terminal-Servers (RDP). Da die RDP aus den Clientnetzwerkes aufgebaut wird, sollte das doch kein Problem sein. Die Clientnetzwerke untereinader Routen ja nicht. Wenn ich dann noch dafür sorge, dass die Clientrechner aus den Clientnetzen niemals die gleichen Adressen haben, so dass es z.B. nie die Adresse: 2.101 haben, sollte ein Rückroute auch kein Problem sein, da diese Adresse nur einmal da ist. Das Ganze würde ich über feste IP-Adressem machen und einer sekmentierung der DHCP-Server. Sind nur kleine Netze mit max 5 Clients.
Jo so könnte das gehen, oder?
Hast aber Recht, liest sich etwas doof. In Zunkunft werde ich das in meine Überschrift Packen: Ich bin nicht blöd! Möchte nur ein wenig Barin...
Das Ganze war so nie geplant gewesen, die Netzwerke zu koppeln und jetzt haben wir den Salat. Die Rückroute ist das Problem, das dachte ich mir bereits, dass es in der NAT Probleme geben wird. Danke Icer....
Aber ich glaube ich habe eine Lösung: Es geht bei der ganzen Sache um die Ereichbarkeit eines Terminal-Servers (RDP). Da die RDP aus den Clientnetzwerkes aufgebaut wird, sollte das doch kein Problem sein. Die Clientnetzwerke untereinader Routen ja nicht. Wenn ich dann noch dafür sorge, dass die Clientrechner aus den Clientnetzen niemals die gleichen Adressen haben, so dass es z.B. nie die Adresse: 2.101 haben, sollte ein Rückroute auch kein Problem sein, da diese Adresse nur einmal da ist. Das Ganze würde ich über feste IP-Adressem machen und einer sekmentierung der DHCP-Server. Sind nur kleine Netze mit max 5 Clients.
Jo so könnte das gehen, oder?
Kommt drauf an, ob Du nur Clients per VPN anbindest oder eine LAN2LAN-Kopplung machst.
Da die Clients normalerweise eine IP-Adresse aus dem Bereich des VPN-Servers bekommen, ist das für Clientverbindungen unerheblich.
Bei Site-2-Site-VPNs mußt Du die Netzwerke umnummerieren, wenn Du mehrere gleichzeitig verbinden willst.
lks
PS: Du solltest Dir trotzdem mal Gedanken machen, Deinen Netznummernplan geradezuziehen.
1
Moin,
Das ist schlecht.
Es wird Dir aber kaum etwas anderes übrig bleiben. Wieso ist das aufwendig und was hängt dran? Im DHCP-Server wird die Netzadresse geändert und schon haben alle DHCP-Clients vdie neue Adresse. Dann noch evtl. bei den Druckern und Servern die feste IP anpassen und es ist schon fast alles gut. Wenn man dann noch die Drucker über einen Printserver betreibt, braucht man hier nur noch die Anschlüsse anzupassen und es ist endgültig alles gut. Zwei Stunden Planung und eine halbe Stunde Durchführung würde ich hier bei uns dafür einplanen.
hth
Erik
Zitat von @zeroblue2005:
Zielsetzung ist es, verschiedene Netzwerke via VPN Lan to Lan zu koppeln. Das Problem ist, dass die entfernten Clientnetzwerke die gleiche Netzadressen haben. Alle haben die: 192.168.2.0/24. Das Zielnetzwerk hat die Netzadresse: 192.168.1.0/24.
Zielsetzung ist es, verschiedene Netzwerke via VPN Lan to Lan zu koppeln. Das Problem ist, dass die entfernten Clientnetzwerke die gleiche Netzadressen haben. Alle haben die: 192.168.2.0/24. Das Zielnetzwerk hat die Netzadresse: 192.168.1.0/24.
Das ist schlecht.
Jetzt leuchtet auch mir ein, dass gleiche Client-Netzadressen keine gut Idee sind! Das Umstricken der Client-Netzadressen aber sehr aufwendig und Fehleranfällig sein wird, da hängt einfach teilweise zu viel dran.
Es wird Dir aber kaum etwas anderes übrig bleiben. Wieso ist das aufwendig und was hängt dran? Im DHCP-Server wird die Netzadresse geändert und schon haben alle DHCP-Clients vdie neue Adresse. Dann noch evtl. bei den Druckern und Servern die feste IP anpassen und es ist schon fast alles gut. Wenn man dann noch die Drucker über einen Printserver betreibt, braucht man hier nur noch die Anschlüsse anzupassen und es ist endgültig alles gut. Zwei Stunden Planung und eine halbe Stunde Durchführung würde ich hier bei uns dafür einplanen.
hth
Erik
Sowas macht man wenn es nicht anders geht mit 1:1 NAT und einem fiktiven Subnetz das der Router der einen Seite mit einem DSTNAT auf eine IP der anderen Seite umsetzt.
Zitat von @zeroblue2005:
Aber ich glaube ich habe eine Lösung: Es geht bei der ganzen Sache um die Ereichbarkeit eines Terminal-Servers (RDP). Da die RDP aus den Clientnetzwerkes aufgebaut wird, sollte das doch kein Problem sein. Die Clientnetzwerke untereinader Routen ja nicht. Wenn ich dann noch dafür sorge, dass die Clientrechner aus den Clientnetzen niemals die gleichen Adressen haben, so dass es z.B. nie die Adresse: 2.101 haben, sollte ein Rückroute auch kein Problem sein, da diese Adresse nur einmal da ist. Das Ganze würde ich über feste IP-Adressem machen und einer sekmentierung der DHCP-Server. Sind nur kleine Netze mit max 5 Clients.
Sorry, selbst wenn die VPN Hardware das hergeben würde, ist die Idee krank. Du müsstest hostrouten pflegen und beim kleinsten Fehler fliegt Dir das um die Ohren. Nimm besser einen Stift und Papier und fang an, die Adressen neu zu planen. Alles andere wirst Du bereuen.Aber ich glaube ich habe eine Lösung: Es geht bei der ganzen Sache um die Ereichbarkeit eines Terminal-Servers (RDP). Da die RDP aus den Clientnetzwerkes aufgebaut wird, sollte das doch kein Problem sein. Die Clientnetzwerke untereinader Routen ja nicht. Wenn ich dann noch dafür sorge, dass die Clientrechner aus den Clientnetzen niemals die gleichen Adressen haben, so dass es z.B. nie die Adresse: 2.101 haben, sollte ein Rückroute auch kein Problem sein, da diese Adresse nur einmal da ist. Das Ganze würde ich über feste IP-Adressem machen und einer sekmentierung der DHCP-Server. Sind nur kleine Netze mit max 5 Clients.
Grüße
lcer
certifiedit.net komm mir doch nicht immer wieder mit Grundkurs usw. ich bin ausgebildeter Fachinformatiker. Jedoch Einzelkämpfer und kann daher nicht überall gleich stark sein und kann auch nicht mal eben meinen Kollegen am Schreibtisch fragen. Darf man nicht einfach mal ein blöde Frage stellen ohne gleich als Anfänger zu gelten! Es geht doch nur um ein wenig Brainstorming.
doch im Bereich Netzwerke bist du Anfänger, Ausbildung hin oder her. (darfst gerne deinen Ausbilder hierfür verantwortlich machen). Und nebenbei: Netze plane ich immer (!) so, dass es zu möglichst keinen Kollisionen kommt.
Aber ich glaube ich habe eine Lösung: Es geht bei der ganzen Sache um die Ereichbarkeit eines Terminal-Servers (RDP). Da die RDP aus den Clientnetzwerkes aufgebaut wird, sollte das doch kein Problem sein.
Damit zeigst du die Kernaussage nur noch verstärkt auf. Es geht schliesslich auch um den Weg zurück. Da ist es egal, ob die Nebennetze nicht untereinander router (momentan). Bau die Um und gut.
PS: Wenn du etwas nicht kannst, dann ziehe jemanden hinzu, der das kann.
Alles klar, ich habe verstanden! Danke für das kleine Brainstorming und die Denkanstöße . Ich weiss was zu tun ist. Ihr habt mir sehr weitergeholfen!
. Ich weiss was zu tun ist. Ihr habt mir sehr weitergeholfen! 
Das Problem ist, dass die entfernten Clientnetzwerke die gleiche Netzadressen haben.
Wieder mal der klassische Adress Design Fehler....VPNs einrichten mit PPTP
Haben wir in der Woche gefühlte 3mal hier....
Welche privaten Subnetze werden am häufigsten verwendet?
Lösen kann man das nur mit einem 1:1 NAT (Network Adress Translation) im VPN Tunnel. Das muss aber die verwendete Router- oder Firewall Hardware natürlich auch supporten. Ohne das klappt es nicht.
Großer Nachteil der NAT Lösung ist die Frickelei mit den Translation Tabellen, denn das muss ja bidirektional passieren. Wenn du dann auch noch mehrere Standorte mit gleichen IPs hast wird das fast unmöglich das zu managen !
Da blickt keiner mehr durch und Troubleshooting wird dann ein Albtraum.
Deshalb der weitaus bessere Tip:
Nimm die kleinsten Lokationen, sprich also die mit der geringsten Anzahl an Clients und stelle die um auf etwas "exotischere" RFC 1918 IP Adressen die eine Doppelung an den Standorten weitgehend verhindern !
Es ist allemal besser mit einem sauberen Adresskonzept zu arbeiten wie es eigentlich bei VPNs auch üblich ist als mit NAT rumzufrickeln. NAT kann nur immer eine absolute Notlösung sein. Skalierbar ist sie niemals.
Das obige Tutorial oder auch hier:
Welche privaten Subnetze werden am häufigsten verwendet?
geben wertvolle Tips dazu !
Weitere Grundlagen auch hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
und hier:
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
So eine Umstellung ist eigentlich auch sehr einfach und schnell gemacht wenn man DHCP im Einsatz hat. Dann ist das eine Sache von nicht mehr als 5 Minuten bei moderater Client Anzahl.
Damit hast du eine langfristige und vor allem saubere Lösung was die IP Adressierung betrifft, die auch das Management bzw. Troubleshooting massiv vereinfacht.
Danke aqui, genau daran habe ich gedacht... danke für die Links
Zitat von @zeroblue2005:
Aber ich glaube ich habe eine Lösung: Es geht bei der ganzen Sache um die Ereichbarkeit eines Terminal-Servers (RDP). Da die RDP aus den Clientnetzwerkes aufgebaut wird, sollte das doch kein Problem sein. Die Clientnetzwerke untereinader Routen ja nicht. Wenn ich dann noch dafür sorge, dass die Clientrechner aus den Clientnetzen niemals die gleichen Adressen haben, so dass es z.B. nie die Adresse: 2.101 haben, sollte ein Rückroute auch kein Problem sein, da diese Adresse nur einmal da ist. Das Ganze würde ich über feste IP-Adressem machen und einer sekmentierung der DHCP-Server. Sind nur kleine Netze mit max 5 Clients.
Aber ich glaube ich habe eine Lösung: Es geht bei der ganzen Sache um die Ereichbarkeit eines Terminal-Servers (RDP). Da die RDP aus den Clientnetzwerkes aufgebaut wird, sollte das doch kein Problem sein. Die Clientnetzwerke untereinader Routen ja nicht. Wenn ich dann noch dafür sorge, dass die Clientrechner aus den Clientnetzen niemals die gleichen Adressen haben, so dass es z.B. nie die Adresse: 2.101 haben, sollte ein Rückroute auch kein Problem sein, da diese Adresse nur einmal da ist. Das Ganze würde ich über feste IP-Adressem machen und einer sekmentierung der DHCP-Server. Sind nur kleine Netze mit max 5 Clients.
Das ist natürlich deutlich weniger aufwendig und fehleranfällig als die Netze einfach umzustellen. *eg*
