Routing über OVPN
Moin,
Folgendes ist gegeben:
Rechner A(VPN Server):
- NIC mit IP 1.0
- VPN mit IP 2.0
Rechner B(VPN CLIENT):
- NIC mit IP 1.1
- VPN mit IP 2.1
- NIC mit IP 3.0
Rechner C:
- NIC mit IP 3.1
Was ich jetzt will ist von Rechner A auf Rechner C zugreifen.
Nach meinem Verständnis muss in Rechner A eine Route von IP3.* auf IP 2.0 eingetragen werden.
Und dann muss noch eine Route im Rechner B von IP2.1 auch nach IP 3.0 eingetragen werden.
1. Ist diese Annahme richtig?
2. Wie würde man dies mit OVPN umsetzen?
Ich hab bis jetzt ein OVPN(Rechner A <-> Rechner B) hinbekommen bei der ich IP 2.* des Partners nur pingen konnte, wenn der Tunnel aufgebaut ist.
Vielen Dank im Voraus
ROB
Folgendes ist gegeben:
Rechner A(VPN Server):
- NIC mit IP 1.0
- VPN mit IP 2.0
Rechner B(VPN CLIENT):
- NIC mit IP 1.1
- VPN mit IP 2.1
- NIC mit IP 3.0
Rechner C:
- NIC mit IP 3.1
Was ich jetzt will ist von Rechner A auf Rechner C zugreifen.
Nach meinem Verständnis muss in Rechner A eine Route von IP3.* auf IP 2.0 eingetragen werden.
Und dann muss noch eine Route im Rechner B von IP2.1 auch nach IP 3.0 eingetragen werden.
1. Ist diese Annahme richtig?
2. Wie würde man dies mit OVPN umsetzen?
Ich hab bis jetzt ein OVPN(Rechner A <-> Rechner B) hinbekommen bei der ich IP 2.* des Partners nur pingen konnte, wenn der Tunnel aufgebaut ist.
Vielen Dank im Voraus
ROB
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 319683
Url: https://administrator.de/forum/routing-ueber-ovpn-319683.html
Ausgedruckt am: 07.04.2025 um 10:04 Uhr
18 Kommentare
Neuester Kommentar
Der Denkansatz ist fast richtig.
Da Rechner B sich ja (denke ich mal) im selben Netz wie Rechner C befindet (Mit NIC 3.0), hat er diese Route schon, das heißt, du musst lediglich angeben, dass Pakete auch geroutet werden (unter Linux geht das mit).
Ansonsten kommt es drauf an, es gibt mehrere Möglichkeiten, das unter OpenVPN zu realisieren. Einerseits eine Route statisch im System konfigurieren oder über eine Configdatei vom Client.
Dazu wäre allerdings ein bisschen mehr Hintergrundinfo notwendig (insbesondere "Echte" IP Adressen).
Dass du über VPN nur Pingen kannst, wenn der Tunnel aufgebaut ist, ist logisch.
Da Rechner B sich ja (denke ich mal) im selben Netz wie Rechner C befindet (Mit NIC 3.0), hat er diese Route schon, das heißt, du musst lediglich angeben, dass Pakete auch geroutet werden (unter Linux geht das mit
echo "1" > /proc/sys/net/ipv4/ip_forward
Ansonsten kommt es drauf an, es gibt mehrere Möglichkeiten, das unter OpenVPN zu realisieren. Einerseits eine Route statisch im System konfigurieren oder über eine Configdatei vom Client.
Dazu wäre allerdings ein bisschen mehr Hintergrundinfo notwendig (insbesondere "Echte" IP Adressen).
Dass du über VPN nur Pingen kannst, wenn der Tunnel aufgebaut ist, ist logisch.
Okay, also in der OpenVPN Config vom Server empfehle ich einzutragen:
(wenn es ein /24er Netz ist).
Und dann muss du noch in der Client Config ein
hinzufügen.
Dann solltest du auf Rechner B noch in der Registry folgenden Eintrag setzen:
Das sollte deine Frage, woher der Rechner das weiß, beantworten.
Dann einmal den Rechner B komplett neustarten und auf dem VPN Server müsste es reichen, wenn du den OpenVPN Dienst neustartest.
Ich persönlich nutze für den ganzen VPN Schrott allerdings Linux Kisten, habe das Gefühl, die laufen stabiler.
route 192.168.48.0 255.255.255.0
Und dann muss du noch in der Client Config ein
iroute 192.168.48.0 255.255.255.0
Dann solltest du auf Rechner B noch in der Registry folgenden Eintrag setzen:
HKEY_LOCAL_MACHINE\System\Current Control Set\Services\Tcpip\Parameters\IPEnableRouter den DWORD Wert von 0 auf 1 setzen
Dann einmal den Rechner B komplett neustarten und auf dem VPN Server müsste es reichen, wenn du den OpenVPN Dienst neustartest.
Ich persönlich nutze für den ganzen VPN Schrott allerdings Linux Kisten, habe das Gefühl, die laufen stabiler.
Was ich jetzt will ist von Rechner A auf Rechner C zugreifen.
Wo ist dein Problem ??- In der Server Konfig Datei das Kommando client-to-client konfigurieren, das erlaubt die Client zu Client Kommunikation !! (Default ist nur Client mit Server erlaubt !)
- OVPN Client auf Rechner C installieren,
- sich ins VPN einwählen mit Rechner C
- und schon können A mit C problemlos kommunizieren.
Nach meinem Verständnis muss in Rechner A eine Route von IP3.* auf IP 2.0 eingetragen werden.
Nein, da sit Blödsinn ! Bei OVPN dürfte dir nicht entgangen sein das der OVPN Server innerhalb der "VPN Wolke" ein virtuelles IP netz aufspannt was mit server 172.16.2.0 255.255.255.0 z.B. in der OVPN Server Konfig Datei definiert ist.Damit sind dann alle Clients in einem gemeinsamen IP Netz ohne jegliche Routen erreichbar !
Guckst du auch hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Und dann muss noch eine Route im Rechner B von IP2.1 auch nach IP 3.0 eingetragen werden.
Nein !Wie oben bereits gesagt sind alle VPN Clients über den Tunneladapter in einem gemeinsamen IP Netz. Routen überflüssig
Wenn du mal ein ipconfig -all (Winblows) oder ifconfig (unixoide OS) machst siehst du das auch selber !
1.) = Nein !
2.) = Mit einer stinknormalen OVPN Standardkonfig ! Tutorial s.o.
Rechner C ist physikalisch nur über Rechner B
Das heisst du hast ein weiteres Netzwerk zwischen diesen Rechnern ?? OK, dann musst du dem Client die Route mitgeben. das route xyz Kommando reicht dafür aus !Damit announced der Client Rechner B sein lokales LAN wo Rchner C hängt an den VPN Server, der dann auch alle IPs in dieses Netzwerk in den VPN Tunnel routet.
Es reicht die Route mit route xyz in die Client Konfig einzutragen. Wenn Client B aktiv eingewählt ist, dann kannst du mit route print das wieder überprüfen. Das lokale LAN des Clients sollte dann in der Routing Tabelle am Server auftauchen !
route network/IP [netmask] [gateway] [metric] Legt eine Route in ein anderes Netzwerk. Z.B. der VPN-Server soll dann über den VPN-Klienten ins Netzwerk hinter dem VPN-Klienten zugreifen.
http://wiki.openvpn.eu/index.php/Routing
unserer sitzt schon über ne woche dran xD
Respekt !! Eine Zeile in der Client Konfig Datei. Unser hat dafür gerade mal 15 Minuten gebraucht !!leider akzeptiert der Client den 'iroute'-Befehl nicht... bin am forschen warum...
Routen erfordern Administrator Rechte ?! Außerdem lautet das Kommando route....Aber woher weiß der Server wenn er " 192.168.48.230" anspricht (pingt) wo er hingreifen soll?
Nun, das kannst du dir sicher auch selber herleiten....Durch den zusätzlicnen route... Befehl in der Client Konfig wird diese Route dem Server beim Tunnelaufbau in die Routing Tabelle übertragen.
Der VPN Server "weiss" nun das er alle bei ihm eintreffenden Pakete mit einer Ziel IP Adresse von 192.168.48.x /24 in den VPN Tunnel routen muss. Was er dann auch tut.
Kommen diese Pakete dann am Client an sieht der auch in seine lokale Routing Tabelle was er mit dem 192.168.48.x Paket machen soll und "sieht" das dieses IP Segment direkt an ihm angeschlossen ist (lokale NIC).
Damit forwardet er dann das Paket an sein Ziel.
Bei Winblows zeigt das Kommando route print die Routing Tabelle bei unixoiden OS ist das netstat -r oder ip route show
Simpelste einfache IP Routing Logik die man in der Grundschule lernt...
Die Tunnel MTU auf 1500 zu setzen ist aber gewagt wenn du einen DSL Anschluss hast.
Das kann erheblich problematisch werden, da die max MTU bei PPPoE im xDSL nie mehr als 1492 ist durch den PPPoE Overhead !
Eigentlich müsste das zu erheblichen Fragmentierungsproblemen bis zur Nichtfunktion bei dir führen...?!
Wie gesagt nur wen xDSL dazwischen ist wegen der PPPoE Encapsulation.
Guckst du hier:
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html
Was am Server auffällig ist dort fehlt das push route... Komando für das lokale LAN Netzwerk !
Ohne das wird dieses Netz niemals auf die Clients übertragen und Endgeräte außer dem Server in dem LAN können dann nie erreicht werden ! Siehe auch hier.
Wenn du also aufs lokale Netz am Server zugreifen willst oder musst ist das ein Fehler.
Wenn nicht ist das soweit OK.
Das kann erheblich problematisch werden, da die max MTU bei PPPoE im xDSL nie mehr als 1492 ist durch den PPPoE Overhead !
Eigentlich müsste das zu erheblichen Fragmentierungsproblemen bis zur Nichtfunktion bei dir führen...?!
Wie gesagt nur wen xDSL dazwischen ist wegen der PPPoE Encapsulation.
Guckst du hier:
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html
Was am Server auffällig ist dort fehlt das push route... Komando für das lokale LAN Netzwerk !
Ohne das wird dieses Netz niemals auf die Clients übertragen und Endgeräte außer dem Server in dem LAN können dann nie erreicht werden ! Siehe auch hier.
Wenn du also aufs lokale Netz am Server zugreifen willst oder musst ist das ein Fehler.
Wenn nicht ist das soweit OK.
Das Fehlerbild bleibt
- Was genau für ein Fehlerbild ?
- Was sagen die Routing Tabellen auf Client und Serverseite bei aktivem Tunnel ?? (route print)
- WO bleibt ein Traceroute hängen ? (tracert)
Mit Tunnel kommt der Client nicht mehr an Rechner C ran
Bitte route print Output hier posten !Rechner A kann Rechner C auch nicht erreichen.
Du hast ein generelles Problem !!Hast du daran gedacht das die virtuellen Tunnel Interfaces (ipconfig) in der lokalen Windows Firewall als öffentliche Netze deklariert werden und damit dort alle Schotten dicht gemacht werden !!
Das Setup erfordert also immer zwingend ein Anpassen der lokalen Firewall ! (Firewall mit erweiterten Einstellungen)
Außerdem ist bei Windows ICMP geblockt (Ping) ! Auch das musst du in der lokalen Firewall anpassen wenn du Pingen willst !
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Ohne das "Firewall Tuning" ist es klar das nix geht !
Was deinen Paket Adressierungs Beschreibung anbetrifft stimmt das so in der Theorie.
Besser ist aber wie immer nachzumessen !!!
Installier dir also dringend den Wireshark auf Server und Client und überprüfe genau ob die Theorie auch mit der Praxis übereinstimmt !!!
Vermutlich nicht wenn die Firewalls nicht angepasst sind.
Der Wireshark wird dir das aber im Handumdrehen zeigen !
Eigentlich ist dein Design ein ganz banales Szenario was mit der richtigen Konfig in einer Viertelstunde zum Fliegen kommt !
Das sieht nach gravierenden IP Konfig fehlern aus.
Der erste Screenshot zeigt das es multiple Default gateways gibt ! Das ist ein Fehler, denn Winblows kann damit nicht umgehen. Es geht dann nach Bindungsreihenfolge was das gesamte Routing dureichanderbringen kann.
Hier musst du dringenst deine Konfig standardkonform anpassen.
Die 2te NIC darf niemals ein Gateway konfiguriert haben !
Lies dir dieses Tutorial durch was dieses Szenario beschreibt und auch die korrekte Gateway Konfig !
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Sicher ein Grund warum es bei dir nicht klappt !!
Der 2te gravierende Fehler ist die OVPN Konfig des Servers. Die ist völliger Blödsinn !
Der propagiert eine Route 192.168.48.0 an seinen Clients. Ein Netz was doch bei ihm gar nicht angeschlossen ist !!
Das .48.0er Netz ist doch am Client wie du oben beschreibst !!!
Den Unsinn solltest du sofort entfernen !!!
Der Server hat als lokales Interface die 192.168.1.120, richtig ?
Also MUSS bei ihm das Kommando push route "192.168.1.0 255.255.255.0" ind der Konfig setehn und sonst NICHTS !
Den ganzen anderen Blödsinn entfernen !
Das .48.0er Netz ist am Client ! Also muss das route 192.168.48.0 255.255.255.0 Kommando auf den Client !
Der injiziert die Route auf den Server, damit der dann das .48.0er Netz kennt.
All dieses Chaos zeigt auch deine Routing Tabelle von Client und Server. Die stimmt ja vorne und hinten nicht wie du selber sehen kannst.
Was auch logisch ist durch die völlig falschen und chaotischen Route Kommandos in der Server und Client Konfig !
Bereinige das alles (OVPN Konfigs und doppelte Default Gateways bei Winblows), dann kommt das auch sofort zum Fliegen !
Der erste Screenshot zeigt das es multiple Default gateways gibt ! Das ist ein Fehler, denn Winblows kann damit nicht umgehen. Es geht dann nach Bindungsreihenfolge was das gesamte Routing dureichanderbringen kann.
Hier musst du dringenst deine Konfig standardkonform anpassen.
Die 2te NIC darf niemals ein Gateway konfiguriert haben !
Lies dir dieses Tutorial durch was dieses Szenario beschreibt und auch die korrekte Gateway Konfig !
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Sicher ein Grund warum es bei dir nicht klappt !!
Der 2te gravierende Fehler ist die OVPN Konfig des Servers. Die ist völliger Blödsinn !
Der propagiert eine Route 192.168.48.0 an seinen Clients. Ein Netz was doch bei ihm gar nicht angeschlossen ist !!
Das .48.0er Netz ist doch am Client wie du oben beschreibst !!!
Den Unsinn solltest du sofort entfernen !!!
Der Server hat als lokales Interface die 192.168.1.120, richtig ?
Also MUSS bei ihm das Kommando push route "192.168.1.0 255.255.255.0" ind der Konfig setehn und sonst NICHTS !
Den ganzen anderen Blödsinn entfernen !
Das .48.0er Netz ist am Client ! Also muss das route 192.168.48.0 255.255.255.0 Kommando auf den Client !
Der injiziert die Route auf den Server, damit der dann das .48.0er Netz kennt.
All dieses Chaos zeigt auch deine Routing Tabelle von Client und Server. Die stimmt ja vorne und hinten nicht wie du selber sehen kannst.
Was auch logisch ist durch die völlig falschen und chaotischen Route Kommandos in der Server und Client Konfig !
Bereinige das alles (OVPN Konfigs und doppelte Default Gateways bei Winblows), dann kommt das auch sofort zum Fliegen !