spsman
Goto Top

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

Content-Key: 319683

Url: https://administrator.de/contentid/319683

Ausgedruckt am: 19.03.2024 um 02:03 Uhr

Mitglied: ketanest112
ketanest112 01.11.2016 aktualisiert um 16:22:39 Uhr
Goto Top
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
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.
Mitglied: SPSman
SPSman 01.11.2016 um 17:32:42 Uhr
Goto Top
HI,

danke.

Also IP Adresse sind Variable.(werden als in der Config angebpasst(<- nur in Welcher? Client?)

Aktuell ist es so:
R A:
NIC: IP 192.168.1.120
VPN:10.1.1.1

R B:
NIC: IP 192.168.1.10
VPN: IP 10.1.1.7
NIC 2: IP 192.168.48.100

R C:
NIC: IP 192.168.48.230

Auf alle rechner läuft Win 7 Prof. 64bit.

Was ich nicht ganz verstehe, woher weiß Rechner B wenn eine Anfrage an -192.168.48.230- über 10.1.1.7 kommt das er dies weiterleiten und nicht Ignorieren muss?
Mitglied: ketanest112
ketanest112 01.11.2016 aktualisiert um 18:15:33 Uhr
Goto Top
Okay, also in der OpenVPN Config vom Server empfehle ich einzutragen:
route 192.168.48.0 255.255.255.0
(wenn es ein /24er Netz ist).
Und dann muss du noch in der Client Config ein
iroute 192.168.48.0 255.255.255.0
hinzufügen.

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
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.
Mitglied: SPSman
SPSman 01.11.2016 um 19:59:52 Uhr
Goto Top
Danke, ich probier's morgen mal face-smile

Leider ist die VPN-Geschichte nur secundär. die Primären Programme sind halt nur Windows basierend.
Mitglied: ketanest112
ketanest112 01.11.2016 um 20:02:56 Uhr
Goto Top
Eventuell macht die Firewall noch Probleme face-sad da kann ich aber leider nciht weiterhelfen.
Mitglied: aqui
aqui 01.11.2016 aktualisiert um 20:15:02 Uhr
Goto Top
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.
Macht dir jeder Azubi in 10 Minuten fertig !
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.
Mitglied: SPSman
SPSman 02.11.2016 um 16:03:31 Uhr
Goto Top
Hi,

danke für deine Anregungen insgesamt gibt es dort aber mehrere Probleme:
Rechner C ist physikalisch nur über Rechner B mit Rechner A verbunden.
Auf Rechner c kann nichts installiert werden. Lediglich ein Serviceprogramm auf Rechner A kann über IP auf Rechner C zugreifen.

Grüße an den Azubi (unserer sitzt schon über ne woche dran xD ).
Mitglied: SPSman
SPSman 02.11.2016 um 16:54:06 Uhr
Goto Top
Hi,
leider akzeptiert der Client den 'iroute'-Befehl nicht... bin am forschen warum...
iroute_client_error
Mitglied: aqui
aqui 02.11.2016 aktualisiert um 18:59:22 Uhr
Goto Top
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....
Mitglied: SPSman
SPSman 03.11.2016 um 14:42:55 Uhr
Goto Top
Ok das leuchtet ein.
Aber woher weiß der Server wenn er " 192.168.48.230" anspricht (pingt) wo er hingreifen soll?


Zitat
Aktuell ist es so:
R A:
Netzwerkkarte 1: IP 192.168.1.120
VPN:10.1.1.1

R B:
Netzwerkkarte 1: IP 192.168.1.10
VPN: IP 10.1.1.7
Netzwerkkarte 2: IP 192.168.48.100

R C:
Netzwerkkarte : IP 192.168.48.230

-> Ich will vom Server die "IP:192.168.48.230" ansprechen können.
Mitglied: aqui
aqui 04.11.2016 aktualisiert um 09:50:39 Uhr
Goto Top
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... face-wink
Mitglied: SPSman
SPSman 04.11.2016 um 16:57:32 Uhr
Goto Top
Hi und danke für die Antwort.

In der Theorie verstehe ich das und es klingt auch ganz einfach, in der Praxis geht es nicht -.-*
Im Screenshot Links der Client(Rechner B) rechts der Server (Rechner A)

Was noch komischer ist . ohne VPN erreiche ich Rechner C von Rechner B. Mit VPN funktioniert das nicht.(siehe Screenshot).
Mir gehen langsam echt die Ideen aus...
route_print
Mitglied: SPSman
SPSman 04.11.2016 aktualisiert um 17:04:46 Uhr
Goto Top
Hier mal die OVPN Configdateinen(ohne #Kommentare)


Zitat von Client


remote 192.168.1.120 5000
route 192.168.48.0 255.255.255.0
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\clientpro.crt"
key "C:\\Program Files\\OpenVPN\\config\\clientpro.key"
client
dev tun
proto udp
tun-mtu 1500
tun-mtu-extra 32
ns-cert-type server
comp-lzo
mute 50
verb 3
persist-key
persist-tun


Zitat von Server

local 192.168.1.120
port 5000
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\webrtu.crt"
key "C:\\Program Files\\OpenVPN\\config\\webrtu.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh1024.pem"
status "C:\\Program Files\\OpenVPN\\log\\openvpn-status.log"
log "C:\\Program Files\\OpenVPN\\log\\openvpn.log"
log-append "C:\\Program Files\\OpenVPN\\log\\openvpn.log"
proto udp
mode server
dev tun
server 192.168.10.0 255.255.255.0
comp-lzo
tun-mtu 1500
tun-mtu-extra 32
keepalive 10 120
verb 3
mute 50
persist-key
persist-tun
Mitglied: aqui
aqui 04.11.2016 aktualisiert um 17:51:03 Uhr
Goto Top
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.
Mitglied: SPSman
SPSman 05.11.2016 um 15:44:57 Uhr
Goto Top
Moin,
habe jetzt beim Server (push route "192.168.48.0 255.255.255.0") und beim Client (pull) hinzugefügen und den (route 192.168.48.0 255.255.255.0) rausgelöscht.

Das Fehlerbild bleibt face-sad.
Mit Tunnel kommt der Client nicht mehr an Rechner C ran(per Ping).
Rechner A kann Rechner C auch nicht erreichen.

Ich formuliere mal aus was passieren soll(nach meinem Verständnis).
Rechner A
Programm Alpha auf Rechner A will mit Programm Ceta auf Rechner C kommunizieren und schickt dazu ein Paket an die IP 192.168.48.230.
Rechner A schaut in seine Routetabelle und sieht "192.168.48.0"(null ist gleich bedeutend mit alle .48.*) soll an den VPN - Tunnel IP 10.1.1.1 und schickt das Paket an diesen Netzwerkadapter und packt diese IP gleichzeitig als Absender ins Paket.

Jetzt kommt das Paket beim VPN -Server dienst auf Rechner A an. Der Dienst verschlüsselt das Paket und schickt es an den einzigen verbunden Clienten.
Dazu packt er ein verschlüsseltes Paket in ein Paket mit Absender IP 192.168.1.120:5000 und Empfänger 192.168.1.10:5000 und schick es los ins Netzwerk.

Rechner B

Rechner B bekommt das Paket von Rechner A und gib es anhand des Ports an den VPN-Client-Dienst weiter.
Der VPN-Dienst entschlüsselt das Paket und verschickt das innere Paket von Programm Alpha mit Ziel 192.168.48.230 an Windows.

Windows schaut in der Route Tabelle nach und sieht alles was 192.168.48.* ist muss an den Adapter NIC 2 mit IP 192.168.48.100 und schickt das entschlüsselte Paket von Programm Alpha in das Netzwerk 2.

Rechner C
Lauscht im Netzwerk 2 und sieht das Paket mit seiner IP(192.168.48.230) und nimmt es an.
Anschließend wird es Anhand des Port an das Programm Ceta weitergegeben.

Programm Ceta bekommt also ein Paket mit Absender 10.1.1.1.

Jetzt will Programm Ceta Antworten und schickt ein Paket mit Ziel 10.1.1.1 los.
->>>> Das verstehe ich aktuell noch nicht: Woher weiß Rechner C das Pakete mit Ziel 10.1.1.* aus seinem Netzwerkadapter losgeschickt werden sollen? Oder wird das in die Routing Tabelle eingetragen wenn das erste Paket ankommt?<<<<<<<-

Machen wir weiter...

Das Paket von Ceta gelangt zu
Rechner B
Rechner B Bekommt also ein Paket mit Ziel 10.1.1.1 und übergibt es dem VPN-Client Dienst.
Der VPN Clientdienst Verschlüsselt das Paket und packt es in ein neues Paket Ziel 192.168.1.120:5000.
Windows schaut in die Routing Tabelle und gibt das Paket NIC 1, der es wiederum in Netzwerk 1 schickt.

Rechner A
... sieht seine IP und gibt das Paket dem VPN-Server-Dient das auf Port 5000 lauscht.
Dieser Dienst wiederum entpackt das Paket und schickt es aus seinem TAP- Adapter raus an das Programm Alpha (aufgrund eins Ports...)

Kommunikation Finito!?!

Daraus folgt im Rechner A muss die Route 192.168.48.* nach 10.1.1.1 eingetragen sein.
Rechner C muss die Route 10.1.1.* nach 192.168.48.230 haben.

Und sonst?

Wo habe ich den logisch Denkfehler?

Und warum bringt Rechner A beim Ping "Allgemeiner Fehler trotz eingetragender Route 192.168.48.0 an 10.1.1.1.
Wenn ich Pathping machen sieht man auch das er den ping nur an den Adapter 192.168.1.120 wiedergibt -.-*

DANKE im voraus
Mitglied: aqui
aqui 05.11.2016 aktualisiert um 20:53:53 Uhr
Goto Top
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 !
Mitglied: SPSman
SPSman 06.11.2016 um 16:59:33 Uhr
Goto Top
Hi,
im Screen zu sehen "Tracert" + "route Print" + Config jeweils bei Server und Client mit ausgeschalteter Firewall.
Zudem beim Server ein pathping.

Was man sieht, ist das der Server den Ping über den richtigen(TAP-) Adapter rausschiebt.
allerdings schein es dort nicht weiter zugehen trotz deakt. Win-Firewall.

Der Tipp mit dem öffentlichen Netzwerk war super, ich werd mich mal auf die suche machen wie ich ein Gateway mit reinschieben kann um so ein Homenetz zu simulieren.

Ich danke dir wirklich für deine Geduld! Nebenbei setze ich noch ein Frisches Windows auf um auch diese Fehlerquelle auszumerzen...
vpn_route_print1
Mitglied: aqui
aqui 07.11.2016 aktualisiert um 08:47:35 Uhr
Goto Top
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 !