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
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte 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: 28.04.2025 um 09: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.
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?
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?
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.0Und dann muss du noch in der Client Config ein
iroute 192.168.48.0 255.255.255.0Dann 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 setzenDann 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.
Danke, ich probier's morgen mal 
Leider ist die VPN-Geschichte nur secundär. die Primären Programme sind halt nur Windows basierend.
Leider ist die VPN-Geschichte nur secundär. die Primären Programme sind halt nur Windows basierend.
Eventuell macht die Firewall noch Probleme 
da kann ich aber leider nciht weiterhelfen.
da kann ich aber leider nciht weiterhelfen.
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.
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 ).
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 ).
Hi,
leider akzeptiert der Client den 'iroute'-Befehl nicht... bin am forschen warum...
leider akzeptiert der Client den 'iroute'-Befehl nicht... bin am forschen warum...
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....
Ok das leuchtet ein.
Aber woher weiß der Server wenn er " 192.168.48.230" anspricht (pingt) wo er hingreifen soll?
-> Ich will vom Server die "IP:192.168.48.230" ansprechen können.
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
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
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
Netzwerkkarte : IP 192.168.48.230
-> Ich will vom Server die "IP:192.168.48.230" ansprechen können.
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...
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...
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...
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
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
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
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.
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.
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 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 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.
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
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.
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
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
.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
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 !
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...
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...
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 !
