Wie erstelle ich ein Transfernetz?

Guten Tag

Mein Netzwerk ist in den letzten Jahren immer mehr gewachsen und es werden verschiedene Verbindungstechnologien (IPSec, OpenVPN, Multipath-TCP, usw.) eingesetzt. Dadurch entstand ein Routingproblem, sprich z.B. ein Client kann mittels OpenVPN ins Hauptnetz zugreifen, aber nicht auf einen Client, welcher sich über IPSec ins Hauptnetz einwählt.

Das Problem sollte mit einem Transfernetz gelöst werden, welches die einzelnen Netzsegmente verbindet. Die Funktionsweise ist mir einleuchtend und nachvollziehbar. Leider stehe ich bei der Umsetzung auf dem Schlauch.

Mir stehen HW-Firewalls (Zyxel USG) sowie SW-Firewalls (IPFire, pfSense) zur Verfügung.

Kann mir jemand auf die Sprünge helfen

Gruss
tr00p3r

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 338573

Url: https://administrator.de/forum/wie-erstelle-ich-ein-transfernetz-338573.html

Ausgedruckt am: 10.04.2025 um 23:04 Uhr

10 Kommentare

Neuester Kommentar

Hallo,

ich würde den Ist-Stand erfassen und dokumentieren (Netzwerkplan), den Soll Stand planen (Netzwerkplan, Netzwerksegmente, Routingpfade, Firewall, ...) die Umsetzung planen (eventuell brauchst Du noch Hardware) und dann Umsetzen (lassen).

vG
LS

ein Client kann mittels OpenVPN ins Hauptnetz zugreifen, aber nicht auf einen Client, welcher sich über IPSec ins Hauptnetz einwählt.

Das ist mit Sicherheit KEIN Routing Problem sondern immer ein Problem der lokalen Endgeräte Firewalls oder der physischen Firewalls das dort entsprechende Zugriffsregeln fehlen.
Wenn du deine IP Adressplanung vorschriftsmäßig gemacht hast und alle IP Netze einzigartig sind kann es ja niemals ein Routing Problem sein !
Weisst du aber sich ja auch selber....?!
Aber wie Kollege laster schon richtig sagt. Sinnvoll wäre eine Topologie Zeichnung bzw. wie du dir das vorstellst.
Normal ist es kinderleicht, denn du steckst die unterschiedlichen Firewalls mit ihrem lokalen LAN Ports alle in ein gemeinsames IP Netzwerk.
Das wiederum legst du dann mit einem Router oder Layer 3 Switch auf die lokalen Produktivnetze. So realisiert man sehr einfach ein "Transfernetz". Der Begriff ist sehr schwammig und bezeichnet viele Szenarien.
Auch zeigt er dein generelles Design Problem bzw. Fehler direkt auf. Die Verwendung zig unterschiedlicher Firewalls und Zugangsprotokolle ist nicht gerade sinnvoll und verkompliziert das Management.
Ggf. solltest du hier auf eine zentralisierte HW übergehen. Auch unterschiedliche VPN Protokolle kannst du mit einer gemeinsamen Hardware abfackeln ohne da 3 oder 4 Boxen stehen haben zu müssen.
Also z.B. eine einzige pfSense die alles macht und gut iss.
Also zusätzlich zum "Transfernetz" mal die gesamte Topologie überdenken.
Und...vergiss den Unsinn mit dem Routing Problem !

Danke für die schnelle Antwort. Ich habe versucht den IST-Netzaufbau darzustellen. Da das Netzwerk stetig gewachsen ist, gab es auch das Chaos mit den verschiedenen Hardware/Subnetze, usw.. Grundsätzlich könnte die Topologie beliebig angepasst werden (wäre wahrscheinlich auch sinnvoll

). Um aber nicht die ganze Netzarchitektur zu ändern, wurde ich auf ein Transfernetz hingewiesen, welches in das jeweilige richtige Netz verweist.

Hallo,

CentOS und SoftEtherVPN Server überall auf allen Seiten in die DMZ und gut ist es, dann ist es egal wer
sich wann überall einwählt und man kann auch mittels eines einzigen "Mausklicks" untereinander auf
alle Bereiche und Klienten zugreifen die sich mittels VPN verbunden haben.

Gruß
Dobby

Ist doch alles richtig gemacht ! 10.10.0.0 /24 ist doch dann schon das "Transfernetz".
Das Design ist doch soweit schlüssig und OK. Viel besser kann man es nicht machen.
Einzig die zig unterschiedliche Hardware für die VPNs.
Eigentlich ist das Unsinn, denn das könnte man mit einer einziegn Hardware Plattform z.B. der pfSense abfackeln.
Aber auch mit dem Hardware Zoo funktioniert es fehlerlos wenn auch etwas auswändiger.

Guten Abend

Vielen Dank für die schnellen und konstruktiven Antworten.

@108012: werde SoftEtherVPN genauer anschauen. Tönt sehr vielversprechend und wäre sicherlich übersichtlicher als über verschiedene Hardware, bzw. Software. Weiter konnte diese Lösung wahrscheinlich die Zyxel USG entlasten, was wohl auch zu einem höheren VPN-Durchsatz führen könnte.

@aqui: leider sind wir teilweise auf die Hardware angewiesen und so kann der Hardware Zoo nicht ganz eliminiert werden... In einem Punkt werde ich noch nicht wirklich schlau. Wenn ich z.B. wie in der Netzwerkskizze beschrieben mit einem OpenVPN Client von einem Notebook auf den OpenVPN Server (10.10.0.246) verbinde, habe ich nur Zugriff in das Netz 10.10.0.0/24 und nicht auf den Aussenstandort 5 (10.10.5.0/24), welcher mittels IPSec VPN über den USG100 (10.10.0.1) aufgebaut wird. Müssen noch weitere Routen definiert werden?

@108012: werde SoftEtherVPN genauer anschauen. Tönt sehr vielversprechend und wäre sicherlich übersichtlicher als über
verschiedene Hardware, bzw. Software.

Es werden recht viele VPN Methoden unterstützt, und die Software ist kostenlos ebenso wie CentOS was schon gehärtet
daher kommt. Und wenn man noch irgend wo einen alten Server hat kann man das damit auch schnell realisieren!

Weiter konnte diese Lösung wahrscheinlich die Zyxel USG entlasten, was wohl auch zu einem höheren VPN-Durchsatz führen könnte.

Wenn der VPN Server in der DMZ steht und potent genug ist wäre das sicherlich drinnen, nur mit einem Raspberry PI würde ich
da auch nicht drauf hoffen wollen!

Gruß
Dobby

und so kann der Hardware Zoo nicht ganz eliminiert werden...

Das ist ja auch kein Beinbruch und funktioniert natürlich auch. Du hast es oben ja auch schon ganz richtig gemacht diese Geräte dann in das 10.10.0.0 /24 "Transfernetz" zu legen.
Intuitiv also alles richtig gemacht

Du musst natürlich nur drauf achten das du dann auch die richtigen Routen an die VPN Clients distribuierst auf diesen Servern, dann klappt es aauch fehlerlos mit der Erreichbarkeit.

mit einem OpenVPN Client von einem Notebook auf den OpenVPN Server (10.10.0.246) verbinde, habe ich nur Zugriff in das Netz 10.10.0.0/24 und nicht auf den Aussenstandort 5 (10.10.5.0/24)

Das ist auch vollkommen klar, denn hier hast du genau das Problem. Du musst auch das 5er Netz vom OpenVPN Server dem Client bekanntmachen, das er das auch in den Tunnel routet also muss in der server.conf Datei folgendes stehen:
...
push "route 10.10.0.0 255.255.255.0"
push "route 10.10.5.0 255.255.255.0"
...
Damit werden dann beide Netze in den VPN Tunnel geroutet. Wenn deine 10.10er Netze alle lokale sind könntest du es auch mit einer entsprechenden Maske generell in den VPN Tunnel routen ala: ...
push "route 10.10.0.0 255.255.0.0"
...
Das routet dann alle 10.10.er Netze in den VPN Tunnel !
Das Kommando route print (Winblows) und auch das Tool Traceroute sind hier wie immer deine besten Freunde beim Troubleshooten.
Mitroute print// kannst du also genau sehen was in den VPN Tunnel geht.
Das lässt schlussfolgern das du dir über das IP Routing bis dato keinerlei Gedanken gemacht hast und es deshalb vermutlich alles fehlschlägt. Was dann auch nicht weiter verwunderlich ist wenn solche simplen Basiscs schon nicht beachtet wurden bei der Einrichtung der Komponenten

Intuitiv also alles richtig gemacht

Tja die gute alte Intuition

Ich habe mit route print die Routen analysiert und nun ist mir auch klar, wieso dies nicht funktioniert. Als Gateway wird der IPFire interne OpenVPN Gateway angegeben. Die Aussenstandorte werden aber per IPSec via 10.10.0.1 aufgebaut. Wenn ich das richtig sehe müsste die Route in etwas so aussehen:
push route "10.10.5.0 255.255.255.0 10.10.0.1 1"
Ich muss mich aber zuerst schlau machen, wie ich bei der IPFire händisch die Server Config anpassen kann um den alternativen Gateway zu definieren.

Das lässt schlussfolgern das du dir über das IP Routing bis dato keinerlei Gedanken gemacht hast und es deshalb vermutlich alles fehlschlägt. Was dann auch nicht weiter verwunderlich ist wenn solche simplen Basiscs schon nicht beachtet wurden bei der Einrichtung der Komponenten

Da hast du leider nicht ganz unrecht. Müsste mich plötzlich mit der ganzen Thematik befassen, ohne vorher das entsprechende Grundwissen vermittelt zu bekommen. Daher half mir nur Dr.Google und Learning by Doing...