zwei lokale Netzwerke miteinander verbinden (VPN)

[tomm1984]

Hallo wertes Forum,

ich habe zwei identische Router, welche als VPN-Host agieren können und gleichzeitig die Möglichkeit bieten, VPN-Client zu sein.

Deshalb frage ich mich, ob ich an den beiden verschiedenen Orten das gleiche Netz nehmen kann (192.168.1.x) und Router so clever sind, die Anfrage an den VPN-Tunnel zu senden, also:

• Server 0 callt Server 1 = im eigenen Netz ("Welt 1") gefunden
• Server 0 callt Server 2 = nicht gefunden; Anfrage geht an Gateway und kommt bei Router in "Welt 2" raus und erreicht dort das Ziel

Danke für Hilfestellung.

 

[InFlame]

Über den VPN hinweg benötigst du unterschiedliche Netze (z.B. 192.168.1.0/24 und 192.168.2.0/24), es sei denn du setzt Technologien wie z.B. VXLAN ein. Hintergrund: über einen klassischen VPN wird auf Layer 3-Ebene geroutet - MAC-Adressen des Netzes auf der anderen VPN-Seite werden durch die lokalen Komponenten nicht aufgelöst.

 

[tomm1984]

hmm, okay. also ich der anfragende Server muss schon wissen, ob sich das Ziel im eigenen Netz befinden müsste oder nicht.

Ich hatte gehofft, damit im Grunde das großes LAN zu machen, egal ob der Zielrechner nebendran steht oder eben über das Internet / VPN verbunden ist (mal abgesehen von Response Time und Geschwindigkeit natürlich).

Danke!

Ergänzung (3. Mai 2022)

... und ich nehme an VXLAN ist nicht für den normal-sterblichen Anwender gedacht, korrekt?

 

[madmax2010]

Ich hatte gehofft, damit im Grunde das großes LAN zu machen, egal ob der Zielrechner nebendran steht oder eben über das Internet / VPN verbunden ist (mal abgesehen von Response Time und Geschwindigkeit natürlich).

Auf der logischen ebene geht das genau so.
Hast dann halt Routen zwischen den Netzen

 

[redjack1000]

Du suchst sowas? http://www.thlu.de/openvpn_bridging.html

CU
redjack

 

[tomm1984]

Du suchst sowas? http://www.thlu.de/openvpn_bridging.html

Okay. Danke! Sieht vielversprechend aus. Beim Überfliegen ist mir nicht ins Auge gestochen, ob das auch in beide Richtungen geht (weil der Ansatz eher ein anderer ist: mobile Geräte ins Heimnetzwerk bringen)

Danke an alle!

 

[redjack1000]

Das sieht in #1 anders aus.

Wenn Du nur einzelne Clients in dein Netzwerk bringen möchtest, benötigst Du einen beliebigen VPN Zugriffspunkt (OpenVPN, Zerotier, Wireguard ........) und einen Client auf dem jeweiligen Client.

Ich benutze dafür Zerotier. Läuft auf fast jedem Client und ist total simpel zu konfigurieren.

CU
redjack

 

[InFlame]

Beim OpenVPN Bridging muss JEDES Gerät, dass sich per VPN ins "Netz" verbindet einzeln konfiguriert und eingebunden werden - bei Site-to-Site Lösungen nicht.

 

[tomm1984]

in Ordnung. Danke für die Ergänzungen

 

[Raijin]

• Server 0 callt Server 1 = im eigenen Netz ("Welt 1") gefunden
• Server 0 callt Server 2 = nicht gefunden; Anfrage geht an Gateway und kommt bei Router in "Welt 2" raus und erreicht dort das Ziel

So funktioniert das aber nicht, muss es auch nicht.

Ich verstehe nicht so ganz was du damit überhaupt bezweckst. Gängige Praxis - und ich meine hier gefühlt 99,99% aller Netzwerke auf diesem Erdball - werden für solche Zwecke über Layer3 geroutet. Das heißt du hast je Standort ein eigenes Subnetz (zB 192.168.1.0/24 und 192.168.2.0/24) sowie ein Subnetz für die VPN-Verbindung selbst (zB 10.0.0.0/24). Die Verbindungen untereinander werden schlicht und ergreifend über das VPN-Gateway geroutet und so kann zB ein PC mit der IP 192.168.1.23 an Standort A mit einem Server mit der IP 192.168.2.34 an Standort B kommunizieren. Ich sehe keinen zwingenden Grund dafür, beide Standorte zwingend in ein und dasselbe Subnetz zu packen und dann mit Layer2-Bridging anzufangen - außer der naive Gedanke (no offense), dass es anders nicht ginge.

Wenn du an den Standorten zwingend auf dieselben Subnetze angewiesen bist - aus .. .. Gründen - dann kann man sonst auch mit NAT arbeiten. Dabei würde das lokale VPN-Gateway ein virtuelles Transfer-Subnetz zum anderen VPN-Gateway schicken und dort wird es wieder in das dortige lokale Subnetz übersetzt. Hätten beide Standorte 192.168.1.0/24, würdest du also an Standort A zB die 192.168.123.45 anpingen und das VPN schickt das "rüber" und leitet es an die dortige 192.168.1.45 weiter. NAT ist aber eher eine Notlösung und es ist in der Regel besser, mit sauber gerouteten Subnetzen zu arbeiten.

 

[tomm1984]

@Raijin danke für diesen Hinweis.

zu Deiner Frage: es ist so, dass die Rechner zwischen den Welten ausgetauscht werden - und damit meine ich nicht Notebooks.

Damit erhoffte ich mir eben ohne großartige Anpassungen sicherzustellen, dass die Rechner problemlos miteinander kommunizieren können, egal, ob der Ziel-Rechner nebendran steht oder über VPN in einem entfernten Netz.

In jedem Fall danke, dass Du (und die anderen auch) da so reingedacht hast / habt.

 

[Raijin]

zu Deiner Frage: es ist so, dass die Rechner zwischen den Welten ausgetauscht werden - und damit meine ich nicht Notebooks.

Darf ich ehrlich sein? Das klingt nach einem XY-Problem. Scheinbar hast du ein mies organisiertes Client-/Server-Konzept und versuchst dies nun mit einer Netzwerkkrücke zu umgehen. Auch wenn hier im Thread schon dargestellt wurde, dass sowas grundsätzlich funktionieren kann, heißt das noch lange nicht, dass man es auch so umsetzen sollte. Die oberste Regel bei Standortverbindungen sind verschiedene Subnetze. Verletzt man diese Regel, sollte man schon sehr gute Gründe dafür haben.

Zwar wurde bereits erklärt wie das ganze IP-technisch ablaufen würde, bedeutet auch das nicht, dass man in der Praxis tatsächlich mit IP-Adressen arbeiten muss. So wäre es beispielsweise kein Problem, dass der DNS am jeweiligen Standort stets die korrekte IP auflöst, sei es die IP des lokalen Servers, eines Servers am anderen Standort oder ggfs eine virtuelle geNATtete IP. Heißt: Egal wo du den Client hinstellst, "MeinServer" würde stets die korrekte IP zurückgeben und der Client würde sich verbinden.

Ich rate daher eher dazu, das Konzept generell zu überdenken, da zB NAT in so einem Fall maximal Symptombekämpfung ist, die ihrerseits zu ganz anderen Problemen führen kann (zB Firewalls).

 

[tomm1984]

okay, danke für das Feedback, die Anregung und Empfehlung. Schätze ich!