34
OpenVPN mit Stunnel - wie lege ich eine Ausnahme für Stunnel an
Hallo,
es geht nun um das gleiche Thema wie hier:
Openvpn per stunnel verstecken (Openvpn läuft ausserhalb stunnel problemlos) (Raspberry Pi - Android)
Der relevante OVPN-Server-Teil sieht bei mir so aus:
Anders als der Threadersteller des erwähnten Thread, möchte ich sämtlichen Traffic über das VPN leiten. Meine Frage ist nun genau die Frage wie ich auf dem Client eine Ausnahme für Stunnel erzeuge so dass die Stunnelverbindung nicht in das VPN geleitet wird?
Die Server-Config ändern ist nicht gut da ich diese Config auch für eine Verbindung ohne Stunnel nutzen möchte. Sonst bräuchte ich eine weitere OVPN-Instanz auf dem Server.
Der Parameter route-nopull ist für mich alleine keine Lösung.
Vielen Dank schonmal für eure Hilfe.
es geht nun um das gleiche Thema wie hier:
Openvpn per stunnel verstecken (Openvpn läuft ausserhalb stunnel problemlos) (Raspberry Pi - Android)
Der relevante OVPN-Server-Teil sieht bei mir so aus:
mode server
tls-server
ifconfig 10.0.9.1 255.255.255.0
ifconfig-pool 10.0.9.30 10.0.9.50 255.255.255.0
ifconfig-pool-persist /etc/openvpn/client/ipp10090.txt
topology subnet
proto tcp-server
dev tun1
port 55554
push "topology subnet"
push "dhcp-option DNS 192.168.3.102"
push "route 192.168.3.0 255.255.255.0 10.0.9.1"
push "route-gateway 10.0.9.1"
push "redirect-gateway def1 bypass-dhcp"
push "ping 10"
push "ping-restart 60"
push "ping-timer-rem"
client-config-dir /etc/openvpn/ccdtcpAnders als der Threadersteller des erwähnten Thread, möchte ich sämtlichen Traffic über das VPN leiten. Meine Frage ist nun genau die Frage wie ich auf dem Client eine Ausnahme für Stunnel erzeuge so dass die Stunnelverbindung nicht in das VPN geleitet wird?
Die Server-Config ändern ist nicht gut da ich diese Config auch für eine Verbindung ohne Stunnel nutzen möchte. Sonst bräuchte ich eine weitere OVPN-Instanz auf dem Server.
Der Parameter route-nopull ist für mich alleine keine Lösung.
Vielen Dank schonmal für eure Hilfe.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 606611
Url: https://administrator.de/contentid/606611
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
34 Kommentare
Neuester Kommentar
Hi,
du müsstest dann im Client eine Route auf das lokale Default-Gateway setzen, die für das Ziel deines stunnels greift.
VG
du müsstest dann im Client eine Route auf das lokale Default-Gateway setzen, die für das Ziel deines stunnels greift.
VG
du müsstest dann im Client eine Route auf das lokale Default-Gateway setzen, die für das Ziel deines stunnels greift.
Danke für die schnelle Rückmeldung.
das habe ich in einigen Tutorials gesehen, aber nicht verstanden.
Könntest du das an einem Beispiel aufzeigen?
Zur Info noch, meine Clients sind RoadWorrier, sprich die verbinden sich heute mit einem Wifi-Hotspot, morgen sind sie per UMTS-Stick angebunden, übermorgen wird das Tethering vom Smartphone genutzt.
In allen Fällen soll dann eine VPN-Verbindung nach Hause durch stunnel hindurch aufgebaut werden.
Könntest du das an einem Beispiel aufzeigen?
Wie denn wenn man noch nicht einmal weiss was für ein OS du auf dem Client hast...??Die Logik dahinter ist doch auch ohne Beispiel ganz einfach.... Du willst einen Gateway Redirect machen am Client. Das bedeutet IP technisch geht dann zwangsweise alles in den Tunnel. Logisch, denn das Default Gateway wird auf den VPN Server gelegt.
Hast du jetzt aber eine dedizierte Hostroute zur Host IP Adresse des Ziel Stunnel Rechners dann hat diese eine höhere Metrik zur Default Route. Für den Traffic der also explizit der statischen Route entspricht gilt nicht die OVPN Tunnel Default Route !
Bei Winblows ist das sowas wie: "route add 192.168.1.0 mask 255.255.255.0 10.10.0.2 -p"
Das "-p" am Ende bewirkt das die Route permanent ist also nach dem nächsten Reboot nicht wieder verschwindet. Ohne das "-p" kannst du also deine Routen testen ohne das was passiert...
Bei Linux ist das: sudo ip route add 192.168.1.0/24 via 10.10.0.2
Noch ein paar Worte zu deiner gruseligen OpenVPN Konfig !:
Deine Server Konfig hat 2 ganz gravierende Fehler:
- 1.) Gateway redirect und Split Tunneling zusammen zu konfigurieren ist natürlich IP technischer Blödsinn. Weisst du hoffenmtlich auch selber, die Frage ist also warum du so einen Unsinn machst ?? Das hiesige_OpenVPN_Tutorial weisst im Kapitel OVPN Server explizit darauf hin wie man mit diesen beiden Route Optionen umgeht !! Das solltest du also dringenst anpassen. Lesen und verstehen...!
- 2.) TCP Encapsulation bei OpenVPN ist keine gute und besonders intelligente Wahl. Sogar die offizielle OpenVPN Doku rät dringenst davon ab. Vermutlich hast du sie nicht gelesen..?! Der Grudn ist klar, es erhöht massiv den Paket Overhead auf Kosten der Nutzdaten und kostet erheblich Performance durch das TCP Handling. Zudem kann es Fragmentierungsprobleme bescheren (MTU Mismatch) die zusätzlich auf Kosten der Performance gehen. Hier ist man also immer gut beraten wenn irgend möglich UDP zu verwenden ! Solltest du auch machen wenn dir der Durchsatz etwas wert ist.
Zitat von @aqui:
Hast du jetzt aber eine dedizierte Hostroute zur Host IP Adresse des Ziel Stunnel Rechners dann hat diese eine höhere Metrik zur Default Route. Für den Traffic der also explizit der statischen Route entspricht gilt nicht die OVPN Tunnel Default Route !
Bei Winblows ist das sowas wie: "route add 192.168.1.0 mask 255.255.255.0 10.10.0.2 -p"
Das "-p" am Ende bewirkt das die Route permanent ist also nach dem nächsten Reboot nicht wieder verschwindet. Ohne das "-p" kannst du also deine Routen testen ohne das was passiert...
Bei Linux ist das: sudo ip route add 192.168.1.0/24 via 10.10.0.2
stimmt, das habe ich wieder rausgelöscht damit der Text nicht so lang wird. Server und Client sind jeweils ein RaspberryPI mit Raspian.Könntest du das an einem Beispiel aufzeigen?
Die Logik dahinter ist doch auch ohne Beispiel ganz einfach.... Du willst einen Gateway Redirect machen am Client. Das bedeutet IP technisch geht dann zwangsweise alles in den Tunnel. Logisch, denn das Default Gateway wird auf den VPN Server gelegt.Hast du jetzt aber eine dedizierte Hostroute zur Host IP Adresse des Ziel Stunnel Rechners dann hat diese eine höhere Metrik zur Default Route. Für den Traffic der also explizit der statischen Route entspricht gilt nicht die OVPN Tunnel Default Route !
Bei Winblows ist das sowas wie: "route add 192.168.1.0 mask 255.255.255.0 10.10.0.2 -p"
Das "-p" am Ende bewirkt das die Route permanent ist also nach dem nächsten Reboot nicht wieder verschwindet. Ohne das "-p" kannst du also deine Routen testen ohne das was passiert...
Bei Linux ist das: sudo ip route add 192.168.1.0/24 via 10.10.0.2
Die Logik habe ich schon verstanden, mir geht es um die Syntax. In den Tutorials heißt es vorne muss die IP des Servers hin, und hinten das Gateway. Aber:
a) ip route add, muss das in das Client-OVPN-File, oder separat vor dem Start der VPN-Verbindung ausgeführt werden
b) welche Adressen muss ich wo nehmen. Der Server-PI hat mehrere Adressen:
irgendwas.dyndns.org ist der DDNS
die öffentliche IP die ständig wechselt
im lokalen LAN hat er die 192.168.3.102
und im VPN die 10.0.9.1
Der DSL-Router auf der Serverseite ist die 192.168.3.1
c) auf clientseite, der client hat eine wechselnde öffentliche IP bei UMTS-Stick, bei der Verbindung zu einem Wifi-Hotspot hat er eine ganz andere private IP. Das Gateway in's Internet wechselt analog ebenfalls ständig.
Also anders formuliert, in deinem Beispiel ip route add 192.168.1.0/24 via 10.10.0.2
Welche meiner IP/DNS-Namen muss wo hin?
Noch ein paar Worte zu deiner gruseligen OpenVPN Konfig !:
Deine Server Konfig hat 2 ganz gravierende Fehler:
Deine Server Konfig hat 2 ganz gravierende Fehler:
- 1.) Gateway redirect und Split Tunneling zusammen zu konfigurieren ist natürlich IP technischer Blödsinn.
push "route 192.168.3.0 255.255.255.0 10.0.9.1"
push "route-gateway 10.0.9.1"
push "redirect-gateway def1 bypass-dhcp"
Wie du es im Tutorial geschrieben hast, wird es oft falsch gemacht.
Ich habe diesen Teil auch aus einem Tutorial und habe es nicht hinterfragt. Es sieht logisch für mich aus. Ich bin davon ausgegangen dass man die route, das Gateway und den redirect pushen muss
Warum ist es ein Fehler wenn man die Route pushed?
* 2.) TCP Encapsulation bei OpenVPN ist keine gute und besonders intelligente Wahl. Sogar die offizielle OpenVPN Doku rät dringenst davon ab. Vermutlich hast du sie nicht gelesen... Overhead ...
Doch, den Hinweis habe ich gelesen. Und ja, ich weiß das mit dem Overhead.
Wie es vorgesehen ist, nutze ich wenn möglich UDP.
TCP ist für mich Backup, und zwar ein zweistufiges. Die erste Stufe ist eine direkte OVPN-Verbindung zwischen Server und Client. Wenn hier gefiltert wird, dann gibt es noch Stufe 2, OVPN über Stunnel.
Ich habe schon die Erfahrung gemacht dass bei einer schlechten Internetverbindung TCP besser funktioniert, vermutlich weil der Sender sofort eine Rückmeldung erhält ob das IP-Paket angekommen ist.
a) ip route add, muss das in das Client-OVPN-File
Oha...wenns bei solchen banalen Fragen schon scheitert... 
Nein, natürlich nicht, das ist ein Windows Shell (cmd) Befehl der Eingabeaufforderung !
b) welche Adressen muss ich wo nehmen.
Die Logik ist einfach:route add <Zielnetz oder Host> mask <Maske_zum_Ziel> <Next_Hop_IP> -p
Analog ist das auf unixoiden OS
Ich habe diesen Teil auch aus einem Tutorial und habe es nicht hinterfragt.
Wie gruselig. Vielleicht solltest du dann besser einmal die offizielle OpenVPN Dokumentation lesen statt dubiose Tutorial von irgendwelchen Laien ?!Warum ist es ein Fehler wenn man die Route pushed?
Das ist per se kein Fehler !Das du aber gemacht hast ist einen gateway redirect und Split Tunneling (push route) zu definieren, was ja kompletter Quatsch ist, denn wenn man eh ALLES in den Tunnel redirected benötigt man logischerweise ja keine dedizierten push route Kommandos mehr für eintzelne Netz und auch umgekehrt. Das eine schliesst logischerweise das ander aus und es ist schlicht falsch beides in der Konfig Datei zu machen weil das dann immer ein indifferentes Routing ergebit durch diese Fehlkonfiguration. OpenVPN Doku lesen !!
weil der Sender sofort eine Rückmeldung erhält ob das IP-Paket angekommen ist.
Muss dann aber immer unnötig retransmitten was viel mehr Overhead mit noch weniger Nettodaten schafft. Aber egal...wenns bei dir hilft ist das OK.Zitat von @aqui:
Nein, natürlich nicht, das ist ein Windows Shell (cmd) Befehl der Eingabeaufforderung !
a) ip route add, muss das in das Client-OVPN-File
Oha...wenns bei solchen banalen Fragen schon scheitert... Nein, natürlich nicht, das ist ein Windows Shell (cmd) Befehl der Eingabeaufforderung !
so eindeutig ist das nicht.
siehe OVPN-Doku, kennt OVPN auch den Parameter –iproute, –route-metric, –iroute network, -route, usw.
Daher zur Sicherheit, ich muss also vor dem Start der OVPN-Verbindung mit route add das fehlende Routing hinzufügen, und nicht über das Konfig-File, richtig?
Bei mir geht's hauptsächlich um Linux-Derivate.
Übrigens, in Android und unter Windows funktioniert die Verbindung obwohl keine zusätzlich Route definiert wird, keine Ahnung warum.
b) welche Adressen muss ich wo nehmen.
Die Logik ist einfach:route add <Zielnetz oder Host> mask <Maske_zum_Ziel> <Next_Hop_IP> -p
Analog ist das auf unixoiden OS
Genau darum geht es ja, was muss als Zielnetz oder Host rein?
die öffentliche IP des Servers, die IP des Servers im privaten LAN hinter dem DSL-Router, oder die IP des Tun-Device auf dem Server, sprich der OVPN-Server?
Und was ist der nächste HOP?
weil der Sender sofort eine Rückmeldung erhält ob das IP-Paket angekommen ist.
Muss dann aber immer unnötig retransmitten was viel mehr Overhead mit noch weniger Nettodaten schafft. Aber egal...wenns bei dir hilft ist das OK.Zitat von @aqui:
Die Logik ist einfach:
route add <Zielnetz oder Host> mask <Maske_zum_Ziel> <Next_Hop_IP> -p
Die Logik ist einfach:
route add <Zielnetz oder Host> mask <Maske_zum_Ziel> <Next_Hop_IP> -p
kannst du das bitte mal an einem konkreten Beispiel aufzeigen?
Zitat von @blacksun:
kannst du das bitte mal an einem konkreten Beispiel aufzeigen?
Zitat von @aqui:
Die Logik ist einfach:
route add <Zielnetz oder Host> mask <Maske_zum_Ziel> <Next_Hop_IP> -p
Die Logik ist einfach:
route add <Zielnetz oder Host> mask <Maske_zum_Ziel> <Next_Hop_IP> -p
kannst du das bitte mal an einem konkreten Beispiel aufzeigen?
route add 192.168.50.0 mask 255.255.255.0 192.168.1.2 -pZitat von @BirdyB:
legt fest, dass jede Anfrage, die in das Netz 192.168.50.0/24 über die 192.168.1.2 gesendet wird.
kannst du das bitte mal an einem konkreten Beispiel aufzeigen?
> route add 192.168.50.0 mask 255.255.255.0 192.168.1.2 -p
> Vielen Dank.
Ist in diesem Beispiel das Netz 192.168.50.0 das private LAN hinter dem DSL-Router, in dem sich der Server befindet?
Die 192.168.1.2, ist das die IP des TUN-Device von OVPN auf dem Server oder die des TUN-Device auf dem Client?
Zitat von @BirdyB:
legt fest, dass jede Anfrage, die in das Netz 192.168.50.0/24 über die 192.168.1.2 gesendet wird.
legt fest, dass jede Anfrage, die in das Netz 192.168.50.0/24 über die 192.168.1.2 gesendet wird.
Könntest du noch was dazu sagen welches Netz in dem Beispiel 192.168.50.0 ist, und was die 192.168.1.2 im Beispiel ist?
Der Stunnel-Server und der Stunnel-Client haben im Gegensatz zu OpenVPN oder iodine keine eigenen Devices und keine eigenen IP-Adressen.
Auf dem Client verbindet sich der OVPN-Client mit dem Stunnel-Client auf 127.0.0.1.
Wenn ich es richtig verstanden habe, dann geht es nun darum dass der vom Stunnel hinausgehende Traffic nicht wieder in's VPN geleitet wird, sondern eben zur öffentlichen IP des Stunnel-Servers.
Darum ist mir das mit dem Netz und der IP aus dem Beispiel nicht klar.
Das .50.0 er Netz ist das Zielnetz also das Netz was der Router mit der statischen Route erreichen soll. Die Hostadresse .1.2 sagt ihm über welche IP Adresse er dieses IP Netz erreicht.
Das Prozedere des Routers ist dann ganz einfach...
Kommt ein IP Paket bei ihm an das als Zieladresse eine .50.x hat sieht er in seiner Routing Tabelle nach. Dort steht ja durch die o.a. statische Route (die immer höchste Prio hat) das er alles was an .50.x gehen muss einfach an die .1.2 senden soll.
Folglich schickt der Router das IP Paket dann an die .1.2 in der Hoffnung das es dann dort irgendwie ins 50er Netz weitergeht.
Die .1.2 als sog. "Next Hop" muss natürlich von ihm aus direkt erreichbar sein also ein IP Netz was direkt an ihm angeschlossen ist.
Eigentlich kinderleicht, oder ?
Guckst du auch hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Damit ist das dann nun hoffentlich sonnenklar für dich ?!
Lesen und verstehen...
Das Prozedere des Routers ist dann ganz einfach...
Kommt ein IP Paket bei ihm an das als Zieladresse eine .50.x hat sieht er in seiner Routing Tabelle nach. Dort steht ja durch die o.a. statische Route (die immer höchste Prio hat) das er alles was an .50.x gehen muss einfach an die .1.2 senden soll.
Folglich schickt der Router das IP Paket dann an die .1.2 in der Hoffnung das es dann dort irgendwie ins 50er Netz weitergeht.
Die .1.2 als sog. "Next Hop" muss natürlich von ihm aus direkt erreichbar sein also ein IP Netz was direkt an ihm angeschlossen ist.
Eigentlich kinderleicht, oder ?
Guckst du auch hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Damit ist das dann nun hoffentlich sonnenklar für dich ?!
Lesen und verstehen...
Zitat von @aqui:
Kommt ein IP Paket bei ihm an das als Zieladresse eine .50.x hat sieht er in seiner Routing Tabelle nach. Dort steht ja durch die o.a. statische Route (die immer höchste Prio hat) das er alles was an .50.x gehen muss einfach an die .1.2 senden soll.
Folglich schickt der Router das IP Paket dann an die .1.2 in der Hoffnung das es dann dort irgendwie ins 50er Netz weitergeht.
Die .1.2 als sog. "Next Hop" muss natürlich von ihm aus direkt erreichbar sein also ein IP Netz was direkt an ihm angeschlossen ist.
Eigentlich kinderleicht, oder ?
Kommt ein IP Paket bei ihm an das als Zieladresse eine .50.x hat sieht er in seiner Routing Tabelle nach. Dort steht ja durch die o.a. statische Route (die immer höchste Prio hat) das er alles was an .50.x gehen muss einfach an die .1.2 senden soll.
Folglich schickt der Router das IP Paket dann an die .1.2 in der Hoffnung das es dann dort irgendwie ins 50er Netz weitergeht.
Die .1.2 als sog. "Next Hop" muss natürlich von ihm aus direkt erreichbar sein also ein IP Netz was direkt an ihm angeschlossen ist.
Eigentlich kinderleicht, oder ?
das habe ich schon verstanden.
Aber mir ist nicht klar wie ich das auf meine Adressbereiche übertragen muss.
Der Client wählt sich über WLAN oder UMTS-Stick in's Internet ein und bekommt da IP, Gateway und Provider-DNS.
Eine OVPN-Verbindung lässt sich aufbauen. Er bekommt vom OVPN-Server die IP 10.0.8.20
Per push vom OVPN-Server bekommt der Client den eigenen DNS 192.168.3.102
Der OVPN-Server hat die 10.0.8.1
Der Server hat eine öffentliche IP irgendwas.ddns.de
Aus Client-Sicht, welches Netz/welche IP muss nun geroutet werden, und welches ist dann das Gateway?
Aus Client-Sicht, welches Netz/welche IP muss nun geroutet werden
Welches Netz geroutet wird wissen wir hier ja nicht, dazu wäre einmal eine kurze Skizze deines Netzes erforderlich damit man weiss was du willst.Zudem weiss man ja auch nicht welche IP Netze du per OVPN Server auf den Client per Push überträgst.
In der Regel ist das ja immer das lokale LAN. Z.B. dann "push "route 192.168.3.0 255.255.255.0" wenn dieses das .3.0er Netz ist.
Wenn du z.B. noch ein anderes IP Netz erreichen willst vom Client das oder die hinter dem OVPN Server liegen dann konfigurierst du ein weiteres Push Kommando was auch dieses Netz dann dem Client bekannt gemacht wird. Z.B. "push "route 172.16.30.0 255.255.255.0".
Wenn du mehrere IP Netze hinterm Server hast z.B. im 172.16er Bereich dann kannst du z.B. mit einem größeren Prefix sagen "push "route 172.16.0.0 255.255.0.0" (Man achte auf den /16er Prefix !). Das routet dann alle 172.16er Netze in den OVPN Tunnel.
Natürlich funktioniert das auch mit einer Hostroute für einen ganz bestimmten einzelnen Rechner z.B. "push "route 192.168.50.100 255.255.255.255".
Am Client (Windows) kannst du dann immer mit route print dir ansehen wie die Routing Tabelle bei aktivem VPN Client aussieht und ob die Netze oder Hosts auch in den Tunnel geroutet werden. Bei unixoiden OpenVPN Endgeräten ist das ip route show oder netstat -r -n.
Wie bereits gesagt...kinderleicht und eine einfache Logik.
Zitat von @aqui:
Zudem weiss man ja auch nicht welche IP Netze du per OVPN Server auf den Client per Push überträgst.
In der Regel ist das ja immer das lokale LAN. Z.B. dann "push "route 192.168.3.0 255.255.255.0" wenn dieses das .3.0er Netz ist.
Aus Client-Sicht, welches Netz/welche IP muss nun geroutet werden
Welches Netz geroutet wird wissen wir hier ja nicht, dazu wäre einmal eine kurze Skizze deines Netzes erforderlich damit man weiss was du willst.Zudem weiss man ja auch nicht welche IP Netze du per OVPN Server auf den Client per Push überträgst.
In der Regel ist das ja immer das lokale LAN. Z.B. dann "push "route 192.168.3.0 255.255.255.0" wenn dieses das .3.0er Netz ist.
verstehe ich nicht. was fehlt denn noch?
Ich hatte doch beschrieben wie die Serveseite und die Clientseite aufgebaut ist.
Die Maschine mit dem OVPN-Server + Stunnel-Server (gemeinsam auf einer) befinden sich hinter einem DSL-Router.
Der DSL-Router hat eine öffentliche IP-Adresse die wechselt. Die IP kann über DDNS angesprochen werden.
Das Netz hinter dem Router ist 192.168.3.0. Alle Clients und die Maschine mit dem Server befinden sich darin. Der Server hat z.B. 192.168.3.102
weitere private Netze gibt es nicht hinter dem DSL-Router.
Der OVPN-Server verwendet ein eigenes Netz, 10.0.8.0.
10.0.8.1 ist das OVPN-Interface.
Was die Server-Konfig angeht, siehe Start-Post.
nachdem Du mich darauf hingewiesen hast dass Gateway redirect und Split Tunneling zusammen falsch sind, ist das hier übrig geblieben:
push "topology subnet"
push "dhcp-option DNS 192.168.3.102"
push "route-gateway 10.0.9.1"
push "redirect-gateway def1 bypass-dhcp" Die Clients haben unterwegs wechselnde Zugänge: Hotspots, UMTS, usw.
So wie du dir das vorstellst funktioniert es aber nicht. Mal abgesehen davon, dass sich mir der Sinn der zusätzlichen stunnel-Verbindung nicht wirklich erschließt, gibt es nur zwei Möglichkeiten dein Ziel zu erreichen:
1) Du leitest nicht das Default-Gateway über dein OpenVPN-Netz, sondern nur das Netz, auf welches hinter deinem OVPN-Server zugegriffen werden soll. Dann wird der stunnel über das Default-Gateway des Clients aufgebaut.
2) Du setzt eine Route für deinen stunnel-Server auf das jeweilig lokale Gateway. Das bringt folgende Schwierigkeiten mit sich:
2.1) Du kennst die IP-Adresse des lokalen Gateways nicht
2.2) Du kennst die IP-Adresse deines stunnel-servers nicht (da DDNS)
Du kannst dir also hier höchstens ein Script bauen (siehe hier: https://openvpn.net/vpn-server-resources/explanation-of-client-side-scri ..), welches die beiden Informationen ermittelt und entsprechend die Route setzt, bzw. wieder löscht. Das ganze hängt dann vom OS des Clients ab.
1) Du leitest nicht das Default-Gateway über dein OpenVPN-Netz, sondern nur das Netz, auf welches hinter deinem OVPN-Server zugegriffen werden soll. Dann wird der stunnel über das Default-Gateway des Clients aufgebaut.
2) Du setzt eine Route für deinen stunnel-Server auf das jeweilig lokale Gateway. Das bringt folgende Schwierigkeiten mit sich:
2.1) Du kennst die IP-Adresse des lokalen Gateways nicht
2.2) Du kennst die IP-Adresse deines stunnel-servers nicht (da DDNS)
Du kannst dir also hier höchstens ein Script bauen (siehe hier: https://openvpn.net/vpn-server-resources/explanation-of-client-side-scri ..), welches die beiden Informationen ermittelt und entsprechend die Route setzt, bzw. wieder löscht. Das ganze hängt dann vom OS des Clients ab.
OK, mit dem Gateway Redirect sendet der OVPN Client dann alles in den OVPN Tunnel. Am Client liegt es also dann de facto nicht und die sind dann generell raus.
Fragt sich dann was am OVPN/Stunnel Server passiert ?! Hier wäre mal der Inhalt der Routing Tabelle interessant !
route print wenn es eine Winblows Gurke ist oder ip route show bzw. netstat -r -n wenn es ein unixoider Server ist.
Die Routing Tabelle sagt ja explizit und sehr genau WAS dann WOHIN geroutet wird !
Fragt sich dann was am OVPN/Stunnel Server passiert ?! Hier wäre mal der Inhalt der Routing Tabelle interessant !
route print wenn es eine Winblows Gurke ist oder ip route show bzw. netstat -r -n wenn es ein unixoider Server ist.
Die Routing Tabelle sagt ja explizit und sehr genau WAS dann WOHIN geroutet wird !
Zitat von @BirdyB:
So wie du dir das vorstellst funktioniert es aber nicht. Mal abgesehen davon, dass sich mir der Sinn der zusätzlichen stunnel-Verbindung nicht wirklich erschließt, gibt es nur zwei Möglichkeiten dein Ziel zu erreichen:
1) Du leitest nicht das Default-Gateway über dein OpenVPN-Netz, sondern nur das Netz, auf welches hinter deinem OVPN-Server zugegriffen werden soll. Dann wird der stunnel über das Default-Gateway des Clients aufgebaut.
2) Du setzt eine Route für deinen stunnel-Server auf das jeweilig lokale Gateway. Das bringt folgende Schwierigkeiten mit sich:
2.1) Du kennst die IP-Adresse des lokalen Gateways nicht
2.2) Du kennst die IP-Adresse deines stunnel-servers nicht (da DDNS)
So wie du dir das vorstellst funktioniert es aber nicht. Mal abgesehen davon, dass sich mir der Sinn der zusätzlichen stunnel-Verbindung nicht wirklich erschließt, gibt es nur zwei Möglichkeiten dein Ziel zu erreichen:
1) Du leitest nicht das Default-Gateway über dein OpenVPN-Netz, sondern nur das Netz, auf welches hinter deinem OVPN-Server zugegriffen werden soll. Dann wird der stunnel über das Default-Gateway des Clients aufgebaut.
2) Du setzt eine Route für deinen stunnel-Server auf das jeweilig lokale Gateway. Das bringt folgende Schwierigkeiten mit sich:
2.1) Du kennst die IP-Adresse des lokalen Gateways nicht
2.2) Du kennst die IP-Adresse deines stunnel-servers nicht (da DDNS)
nun, soweit ich das gelesen habe, sieht der verschlüsselte Traffic von OpenVPN von aussen nicht wie normaler SSL-Traffic aus da OVPN wohl eine andere Verschlüsselung benutzt.
Als Lösung wird vorgeschlagen dass man den OVPN-Traffic mit stunnel oder obfuscation in einen SSL-Tunnel packt so dass es für eine DPI nach normalem Verkehr aussieht und ihn nicht blockiert.
Dass das ganze erheblich Performance kostet (einmal durch TCP anstatt UDP bei OVPN, und durch das zweite Verpacken durch stunnel), das ist mir bewusst. Aber eine langsamere Verbindung ist immer noch besser als gar keine Verbindung.
An sich ist das ganze wohl schon möglich.
Unter Android verwende ich den OVPN-Client von Arne Schwabe auf nicht gerouteten Androiden. In der App kann man einfach in den Einstellungen sagen welche Apps nicht durch den OVPN-Tunnel sollen. Hier wähle ich die Stunnel-App und schon läuft es mit der obigen TCP-Konfig für OVPN die ich auch ohne Stunnel nutze.
Unter Windows läuft es, warum auch immer, komplett ohne Anpassungen. Hier funktionieren die normalen OVPN-Konfigs auf Server und Client-Seite für TCP.
Einzig auf Client-Seite ändert man in der OVPN-Konfig remote auf localhost ab und setzt den Port auf den Port auf dem der Stunnel-Client lauscht.
Nur auf einem unixoiden Client, da muss man wohl etwas anpassen.
In den Tutorials zu OVPN + Stunnel wird zu dem Thema immer das gleiche erwähnt:
push "route x.x.x.x 255.255.255.255 net_gateway"
Ich möchte dies aber nicht pushen um nicht eine weitere Konfig/OVPN-Instanz auf Serverseite zu benötigen, sondern dies direkt in der entsprechenden Client-Konfig setzen.
Es heißt an die Stelle der x müsse die IP des Servers. Aber auch hier stellt sich die Frage welche das sein soll, die öffentliche IP (also DDNS-Name), die des Servers im privaten LAN hinter dem DSL-Router (192.168.3.x) oder die der tun-Schnittstelle auf dem Server (10.0.8.1).
Und der zweite Punkt ist was dieses net_gateway sein soll. Ist das ein OVPN-Parameter oder soll das ein Platzhalter für den Namen einer Schnittstelle sein, oder soll hier auch eine IP hin.
EDIT:
Hier ist so ein Tutorial zu dem Thema:
https://medium.com/@jayden.chua/stunnel-openvpn-server-on-ubuntu-18-04-1 ...
Zu deinen Punkten 2.1 und 2.2, ich interpretiere das Tutorial so dass diese eine Zeile auf Client-Seite diesen beiden Punkte erledigen soll (ohne weitere Skripte??).
An die X.x.x.x kommt der DDNS-Namen, und net_gateway, ist das ein Kommando aus Linux heraus, oder aus OVPN heraus, der genau den Punkt 2.2 durchführt, also das Gateway ermittelt???
Zitat von @aqui:
OK, mit dem Gateway Redirect sendet der OVPN Client dann alles in den OVPN Tunnel. Am Client liegt es also dann de facto nicht und die sind dann generell raus.
OK, mit dem Gateway Redirect sendet der OVPN Client dann alles in den OVPN Tunnel. Am Client liegt es also dann de facto nicht und die sind dann generell raus.
Ich denke schon dass es am Client liegt, denn dass alles in den OVPN-Tunnel geleitet wird, das ist falsch.
Siehe dem Titel des Threads, darf die Stunnel-Verbindung nicht in den OVPN-Tunnel.
Solche Ausnahmen muss man unter unixoiden OSen, soweit ich das herausfinden konnte, über routing-Einträge vornehmen.
Lies dir auch das bitte durch was ich gerade an BirdyB geantwortet habe.
Ich denke es geht um genau das was du mir bisher erklären wolltest, also dass man diese redirect gateway für eine ganz bestimmte Verbindung übersteuert, also dass alles in den Tunnel soll, ausser die Verbindung des Stunnel-Clients.
Der Stunnel-Client möcht sich verbinden zu irgendwas.ddns.de auf Port 4444.
Ganz dunkel meine ich mit zu erinnern dass es beim Routing auch Prioritäten gab.
Die zusätzliche Route müsste also eine höhere Prio bekommen wie das redirect gateway um sozusagen auszubrechen.
Aber wie?
Jetzt muss auf Clientseite dafür gesorgt werden dass eine Verbindung auf irgendwas.ddns.de:4444 NICHT mehr unter redirect gateway fällt.
Und hier würde ich als Laie sagen, das was du oben rot geschrieben hast mit Zielhost, da muss irgendwas.ddns.de:4444 hin.
Da es sich nur um die eine IP handelt, wäre Subnetzmaske 255.255.255.255.
Aber was ist der Next-Hop?
Verstehst du mein Problem? Ich meine die Idee, was du mir sagen wolltest, das habe ich meine ich schon verstanden. Aber mir fehlt es an der konkreten Umsetzung.
Ich hatte ja gerade BirdyB geantwortet dass in Tutorials zu dem Thema es heißt:
route x.x.x.x 255.255.255.255 net_gateway
Das ist ja genau das was du mir erklärt hast. Die 4 X stehen für den DDNS-Namen, und das net_gateway für den Next_Hop.
Ich interpretiere die Tutorials so dass es auf Clientseite nur eine Zeile in der OVPN-Konfig benötigt und keine weiteren Skripte usw., sondern dass dieses net_gateway eben das Gateway nach aussen ermittelt, also den Next-Hop.
Zitat von @blacksun:
nun, soweit ich das gelesen habe, sieht der verschlüsselte Traffic von OpenVPN von aussen nicht wie normaler SSL-Traffic aus da OVPN wohl eine andere Verschlüsselung benutzt.
Als Lösung wird vorgeschlagen dass man den OVPN-Traffic mit stunnel oder obfuscation in einen SSL-Tunnel packt so dass es für eine DPI nach normalem Verkehr aussieht und ihn nicht blockiert.
Dass das ganze erheblich Performance kostet (einmal durch TCP anstatt UDP bei OVPN, und durch das zweite Verpacken durch stunnel), das ist mir bewusst. Aber eine langsamere Verbindung ist immer noch besser als gar keine Verbindung.
Also: Was möchtest du jetzt genau? In deiner initialen Fragestellung schreibst du, dass du eine stunnel-Verbindung parallel zu deiner OpenVPN-Verbindung aufbauen willst. Jetzt schreibst du, dass du deine OpenVPN-Verbindung über den stunnel aufbauen möchtest. Letzteres ist ja wohl mehr als einfach. Erst die stunnel-Verbindung aufbauen und dann die OpenVPN-Verbindung. Da musst du auch an den Routen nix machen, da die bereits bestehende Tunnel-Verbindung einfach so bleibt, wie Sie ist.Zitat von @BirdyB:
So wie du dir das vorstellst funktioniert es aber nicht. Mal abgesehen davon, dass sich mir der Sinn der zusätzlichen stunnel-Verbindung nicht wirklich erschließt, gibt es nur zwei Möglichkeiten dein Ziel zu erreichen:
1) Du leitest nicht das Default-Gateway über dein OpenVPN-Netz, sondern nur das Netz, auf welches hinter deinem OVPN-Server zugegriffen werden soll. Dann wird der stunnel über das Default-Gateway des Clients aufgebaut.
2) Du setzt eine Route für deinen stunnel-Server auf das jeweilig lokale Gateway. Das bringt folgende Schwierigkeiten mit sich:
2.1) Du kennst die IP-Adresse des lokalen Gateways nicht
2.2) Du kennst die IP-Adresse deines stunnel-servers nicht (da DDNS)
So wie du dir das vorstellst funktioniert es aber nicht. Mal abgesehen davon, dass sich mir der Sinn der zusätzlichen stunnel-Verbindung nicht wirklich erschließt, gibt es nur zwei Möglichkeiten dein Ziel zu erreichen:
1) Du leitest nicht das Default-Gateway über dein OpenVPN-Netz, sondern nur das Netz, auf welches hinter deinem OVPN-Server zugegriffen werden soll. Dann wird der stunnel über das Default-Gateway des Clients aufgebaut.
2) Du setzt eine Route für deinen stunnel-Server auf das jeweilig lokale Gateway. Das bringt folgende Schwierigkeiten mit sich:
2.1) Du kennst die IP-Adresse des lokalen Gateways nicht
2.2) Du kennst die IP-Adresse deines stunnel-servers nicht (da DDNS)
nun, soweit ich das gelesen habe, sieht der verschlüsselte Traffic von OpenVPN von aussen nicht wie normaler SSL-Traffic aus da OVPN wohl eine andere Verschlüsselung benutzt.
Als Lösung wird vorgeschlagen dass man den OVPN-Traffic mit stunnel oder obfuscation in einen SSL-Tunnel packt so dass es für eine DPI nach normalem Verkehr aussieht und ihn nicht blockiert.
Dass das ganze erheblich Performance kostet (einmal durch TCP anstatt UDP bei OVPN, und durch das zweite Verpacken durch stunnel), das ist mir bewusst. Aber eine langsamere Verbindung ist immer noch besser als gar keine Verbindung.
An sich ist das ganze wohl schon möglich.
Ja, aber nicht so, wie du dir das vorstellstUnter Android verwende ich den OVPN-Client von Arne Schwabe auf nicht gerouteten Androiden. In der App kann man einfach in den Einstellungen sagen welche Apps nicht durch den OVPN-Tunnel sollen. Hier wähle ich die Stunnel-App und schon läuft es mit der obigen TCP-Konfig für OVPN die ich auch ohne Stunnel nutze.
Es mag sein, dass dein Android-Client da irgendwelche Komfort-Funktionen eingebaut hat, die dann bestimmte Sachen ausklammern. Der Standard-OpenVPN-Client hat das eben nicht.Unter Windows läuft es, warum auch immer, komplett ohne Anpassungen. Hier funktionieren die normalen OVPN-Konfigs auf Server und Client-Seite für TCP.
Einzig auf Client-Seite ändert man in der OVPN-Konfig remote auf localhost ab und setzt den Port auf den Port auf dem der Stunnel-Client lauscht.
Richtig.Einzig auf Client-Seite ändert man in der OVPN-Konfig remote auf localhost ab und setzt den Port auf den Port auf dem der Stunnel-Client lauscht.
Nur auf einem unixoiden Client, da muss man wohl etwas anpassen.
In den Tutorials zu OVPN + Stunnel wird zu dem Thema immer das gleiche erwähnt:
push "route x.x.x.x 255.255.255.255 net_gateway"
Ich möchte dies aber nicht pushen um nicht eine weitere Konfig/OVPN-Instanz auf Serverseite zu benötigen, sondern dies direkt in der entsprechenden Client-Konfig setzen.
Es heißt an die Stelle der x müsse die IP des Servers. Aber auch hier stellt sich die Frage welche das sein soll, die öffentliche IP (also DDNS-Name), die des Servers im privaten LAN hinter dem DSL-Router (192.168.3.x) oder die der tun-Schnittstelle auf dem Server (10.0.8.1).
Und der zweite Punkt ist was dieses net_gateway sein soll. Ist das ein OVPN-Parameter oder soll das ein Platzhalter für den Namen einer Schnittstelle sein, oder soll hier auch eine IP hin.
Du hast leider immer noch nicht die Grundlagen zum Thema Routing gelesen oder verstanden. Im Routing geht es nur um IP-Adressen. Irgendwelche DNS-Namen haben da nichts verloren. Du kannst keine Route an Hand des DNS-Namens setzen.In den Tutorials zu OVPN + Stunnel wird zu dem Thema immer das gleiche erwähnt:
push "route x.x.x.x 255.255.255.255 net_gateway"
Ich möchte dies aber nicht pushen um nicht eine weitere Konfig/OVPN-Instanz auf Serverseite zu benötigen, sondern dies direkt in der entsprechenden Client-Konfig setzen.
Es heißt an die Stelle der x müsse die IP des Servers. Aber auch hier stellt sich die Frage welche das sein soll, die öffentliche IP (also DDNS-Name), die des Servers im privaten LAN hinter dem DSL-Router (192.168.3.x) oder die der tun-Schnittstelle auf dem Server (10.0.8.1).
Und der zweite Punkt ist was dieses net_gateway sein soll. Ist das ein OVPN-Parameter oder soll das ein Platzhalter für den Namen einer Schnittstelle sein, oder soll hier auch eine IP hin.
EDIT:
Hier ist so ein Tutorial zu dem Thema:
https://medium.com/@jayden.chua/stunnel-openvpn-server-on-ubuntu-18-04-1 ...
Zu deinen Punkten 2.1 und 2.2, ich interpretiere das Tutorial so dass diese eine Zeile auf Client-Seite diesen beiden Punkte erledigen soll (ohne weitere Skripte??).
An die X.x.x.x kommt der DDNS-Namen, und net_gateway, ist das ein Kommando aus Linux heraus, oder aus OVPN heraus, der genau den Punkt 2.2 durchführt, also das Gateway ermittelt???
Ja, Punkt 2.2. geht dann auch mit net_gateway. Und an die Stelle mit dem x.x.x.x kommt die öffentliche IP deines Servers. Also die IP auf die dein DDNS-Name auflöst. Die musst du halt ermitteln, denn nochmal: Routing geht nicht mit DNS-Namen, nur mit IP-Adressen.Hier ist so ein Tutorial zu dem Thema:
https://medium.com/@jayden.chua/stunnel-openvpn-server-on-ubuntu-18-04-1 ...
Zu deinen Punkten 2.1 und 2.2, ich interpretiere das Tutorial so dass diese eine Zeile auf Client-Seite diesen beiden Punkte erledigen soll (ohne weitere Skripte??).
An die X.x.x.x kommt der DDNS-Namen, und net_gateway, ist das ein Kommando aus Linux heraus, oder aus OVPN heraus, der genau den Punkt 2.2 durchführt, also das Gateway ermittelt???
Ich denke schon dass es am Client liegt, denn dass alles in den OVPN-Tunnel geleitet wird, das ist falsch.
Siehe dem Titel des Threads, darf die Stunnel-Verbindung nicht in den OVPN-Tunnel.
Solche Ausnahmen muss man unter unixoiden OSen, soweit ich das herausfinden konnte, über routing-Einträge vornehmen.
Siehe dem Titel des Threads, darf die Stunnel-Verbindung nicht in den OVPN-Tunnel.
Solche Ausnahmen muss man unter unixoiden OSen, soweit ich das herausfinden konnte, über routing-Einträge vornehmen.
Wenn die stunnel-Verbindung vorher schon besteht, dürfte das keine Rolle spielen.
Ich denke es geht um genau das was du mir bisher erklären wolltest, also dass man diese redirect gateway für eine ganz bestimmte Verbindung übersteuert, also dass alles in den Tunnel soll, ausser die Verbindung des Stunnel-Clients.
Der Stunnel-Client möcht sich verbinden zu irgendwas.ddns.de auf Port 4444.
Der Stunnel-Client möcht sich verbinden zu irgendwas.ddns.de auf Port 4444.
Ganz dunkel meine ich mit zu erinnern dass es beim Routing auch Prioritäten gab.
Die zusätzliche Route müsste also eine höhere Prio bekommen wie das redirect gateway um sozusagen auszubrechen.
Aber wie?
Brauchst du eigentlich nicht, da die spezifischere Route eher greift, als die allgemeine RouteDie zusätzliche Route müsste also eine höhere Prio bekommen wie das redirect gateway um sozusagen auszubrechen.
Aber wie?
Jetzt muss auf Clientseite dafür gesorgt werden dass eine Verbindung auf irgendwas.ddns.de:4444 NICHT mehr unter redirect gateway fällt.
Und hier würde ich als Laie sagen, das was du oben rot geschrieben hast mit Zielhost, da muss irgendwas.ddns.de:4444 hin.
Da es sich nur um die eine IP handelt, wäre Subnetzmaske 255.255.255.255.
Aber was ist der Next-Hop?
Next-Hop wäre dann eben das lokale Gateway, denn darüber soll die Verbindung ja geroutet werdenUnd hier würde ich als Laie sagen, das was du oben rot geschrieben hast mit Zielhost, da muss irgendwas.ddns.de:4444 hin.
Da es sich nur um die eine IP handelt, wäre Subnetzmaske 255.255.255.255.
Aber was ist der Next-Hop?
Verstehst du mein Problem? Ich meine die Idee, was du mir sagen wolltest, das habe ich meine ich schon verstanden. Aber mir fehlt es an der konkreten Umsetzung.
Ich hatte ja gerade BirdyB geantwortet dass in Tutorials zu dem Thema es heißt:
route x.x.x.x 255.255.255.255 net_gateway
Das ist ja genau das was du mir erklärt hast. Die 4 X stehen für den DDNS-Namen, und das net_gateway für den Next_Hop.
Nein. Keine DDNS-Namen beim Routing!route x.x.x.x 255.255.255.255 net_gateway
Das ist ja genau das was du mir erklärt hast. Die 4 X stehen für den DDNS-Namen, und das net_gateway für den Next_Hop.
Ich interpretiere die Tutorials so dass es auf Clientseite nur eine Zeile in der OVPN-Konfig benötigt und keine weiteren Skripte usw., sondern dass dieses net_gateway eben das Gateway nach aussen ermittelt, also den Next-Hop.
Ja, korrekt.Zitat von @BirdyB:
Also: Was möchtest du jetzt genau? In deiner initialen Fragestellung schreibst du, dass du eine stunnel-Verbindung parallel zu deiner OpenVPN-Verbindung aufbauen willst. Jetzt schreibst du, dass du deine OpenVPN-Verbindung über den stunnel aufbauen möchtest.
Also: Was möchtest du jetzt genau? In deiner initialen Fragestellung schreibst du, dass du eine stunnel-Verbindung parallel zu deiner OpenVPN-Verbindung aufbauen willst. Jetzt schreibst du, dass du deine OpenVPN-Verbindung über den stunnel aufbauen möchtest.
Das hast du falsch herausgelesen.
Mein OVPN-Server bietet mehrere Zugänge: auf einem Port nach aussen an der öffentlichen IP nimmt er Verbindungen per UDP entgegen, auf einem zweiten Port nimmt er TCP-Verbindungen an. Und auf einem 3. Port lauscht der Stunnel-Server.
Stunnel-Server und OVPN-Server laufen wie gesagt hinter dem DSL-Router auf der gleichen Maschine im 192.168-LAN
Der Stunnel-Server leitet dann wiederum auf den gleichen TCP-Port auf localhost um auf den der DSL-Router den für TCP-OVPN-Verbindungen (also ohne Stunnel) vorgesehen Port auch weiterleitet.
Kurzum, ich habe 3 Möglichkeiten mich zu meinem OVPN-Server zu verbinden, je nach Erfordernis.
Auf dem Server laufen 2 OVPN-Instanzen, eine für UDP und eine für TCP.
Die zusätzlich Konfig-Einträge, die der Client bei der Variante über Stunnel benötigt, möchte ich nicht in die TCP-Server-Konfig schreiben und per push an den Client senden, sondern direkt in der Client-Konfig vornehmen so dass die push-Einträge auf dem Server sowohl für Variante 2 als auch Variante 3 passen.
Würde ich die für Variante 3 nötigen Einträge in die Server-Konfig schreiben mit push, dann wären diese falsch bei Nutzung von Variante2.
Ist es jetzt deutlicher was ich gemeint habe?
Letzteres ist ja wohl mehr als einfach. Erst die stunnel-Verbindung aufbauen und dann die OpenVPN-Verbindung. Da musst du auch an den Routen nix machen, da die bereits bestehende Tunnel-Verbindung einfach so bleibt, wie Sie ist.
Leider ist das nicht ganz so einfach.
Soweit ich das gesehen habe, baut Stunnel erst dann eine Verbindung zu seinem Server auf wenn diese auch angefordert wird, so wie ein Browser erst dann einen Webserver kontaktiert wenn eine Seite angefordert wird.
Der OVPN-Client sagt dem Stunnel-Client auf localhost dass er eine Verbindung wünscht, und dann verbindet der Stunnel-Client zu Stunnel-Server.
Ich kann also - anders wie bei OVPN - nicht sagen starte mal die Verbindung und halte diese für den Fall dass was kommt was durch den Tunnel soll. Sprich wenn der Stunnel-Client als Dienst startet, dann wird noch keine Verbindung aufgebaut.
Anmerkung: Ob OVPN-Client und OVPN-Server von natur aus eine Verbindung aufrecht erhalten, oder ob das durch keep-Alive passiert, kann ich nicht sagen.
Dass durch die Verbindungsanforderung des OVPN-Client an den Stunnel-Client dieser erst eine Verbindung zum Stunnel-Server aufgebaut wird und über diesen Tunnel dann die OVPN-Verbindung geschickt wird, das ist mir klar.
Meinen wir trotzdem das gleiche?
Ausserdem ist nicht der Verbindungsaufbau das Problem. Das funktioniert tatsächlich ohne Fehler im OVPN-Log.
Der OVPN-Client teilt dem Stunnel-Client auf localhost mit dass er verbinden soll. Dieser verbindet sich dann zu seinem Stunnel-Server. Der Stunnel-Server leitet das dann weiter auf an den OVPN-Server auf localhost.
Mein Problem ist dass keinerlei Übertragung möglich ist. Ich kann per Ping auf dem Client nichts erreichen, weder öffentliche IPs erreichen, noch die 10.0.8.1 die das tun-Device auf dem Server hat, und auch keine IPs im LAN des Servers, z.B. 192.168.3.100, DNS-Server, nichts.
Du hast leider immer noch nicht die Grundlagen zum Thema Routing gelesen oder verstanden. Im Routing geht es nur um IP-Adressen. Irgendwelche DNS-Namen haben da nichts verloren. Du kannst keine Route an Hand des DNS-Namens setzen.
Ich denke hier liegt ein Mißverständnis vor.
Selbstverständlich weiß ich dass Routing mit IP-Adressen gemacht wird.
Wenn ich aber
route add irgendwas.ddns.de mask 255.255.255.255 <Next_Hop_IP>
auf dem Client ausführe, dann wird in diesem Moment vom OS der Namen über den DNS zur IP aufgelöst. Und genau diese IP landet dann auch in der Routing-Tabelle.
Sprich das OS übernimmt genau das was du mit Skript angedeutet hast, also die öffentliche IP des Servers ermitteln.
Probier's mal aus
Ja, Punkt 2.2. geht dann auch mit net_gateway. Und an die Stelle mit dem x.x.x.x kommt die öffentliche IP deines Servers. Also die IP auf die dein DDNS-Name auflöst. Die musst du halt ermitteln, denn nochmal: Routing geht nicht mit DNS-Namen, nur mit IP-Adressen.
siehe Absatz zuvor, das OS übernimmt die Auflösung in IP im Rahmen des Route-Befehls.
Wenn die stunnel-Verbindung vorher schon besteht, dürfte das keine Rolle spielen.
siehe oben, meinen wir das gleiche mit dem Zuerst bestehen?Next-Hop wäre dann eben das lokale Gateway, denn darüber soll die Verbindung ja geroutet werden
Verstehst du mein Problem? Ich meine die Idee, was du mir sagen wolltest, das habe ich meine ich schon verstanden. Aber mir fehlt es an der konkreten Umsetzung.
Ich interpretiere die Tutorials so dass es auf Clientseite nur eine Zeile in der OVPN-Konfig benötigt und keine weiteren Skripte usw., sondern dass dieses net_gateway eben das Gateway nach aussen ermittelt, also den Next-Hop.
Ja, korrekt.Damit wir nicht aneinander vorbeireden:
Ich habe deshalb bei den Routen immer DDNS-Namen geschrieben weil das OS im Moment der Ausführung das für mich zur IP macht.
Was mir nicht klar ist und wo ich am grübeln bin:
- dieses net_gateway ist also ein Befehl. Wie wende ich das nun konkret an?
- aqui (du auch?) meinte ja ich soll auf dem Client einfach von "Hand", also z.B. per Skript bevor ich überhaupt eine Verbindung mit Stunnel/OVPN aufbaue, die route setzen. Wäre es nicht besser wenn ich das in die OVPN-Client-Konfig schreibe? Denn ich benötige diesen Routing-Eintrag ja nur wenn die OVPN-Verbindung aufgebaut wird. Wenn der OVPN-Client die Verbindung wieder abbaut, dann macht der Client das automatisch wieder rückgangig.
Ich stelle mir das vor wie bei redirect gateway in der OVPN-Client-Konfig. Dieses wird bei Verbindungsaufbau angewendet, und beim Abbau automatisch wieder rückgängig gemacht.
Kann ich das mit dem route setzen nicht auf die gleiche Art nutzen?
Wenn wirklich alle Dienste wie Stunnel und die zahllosen anderen Connections UDP usw. zentral auf dem OVPN Server laufen ist das doch kein Problem. Dieser Server ist dann für den Client auch der zentrale Router auf alle diese Links, IP Netze usw.
Essentiell wichtig ist dann das auf diesem Server IP Forwarding aktiviert ist damit dieser die Zielnetze die der Client anfragt routen kann. Ohne aktives IP Forwarding (Routing) klappt das logischerweise nicht.
Da der Client ja ein Gateway Redirect macht schickt er all seinen Traffic generell in den Tunnel. Sprich sowie der OVPN Client aktiv ist geht dessen Traffic generell komplett in den Tunnel zum OpenVPN Server.
Am OpenVPN Server ist es dann essentiell wichtig das der alle diese Zielnetze kennt um die Client Requests entsprechend routen zu können.
Wie bereits mehrfach gesagt: Der OVPN Server ist der erste Routing Hop des OVPN Clients. Folglich muss also der Server eine wasserdichte Routing Tabelle haben in die Zielnetze, Firewall Regeln (sofern auf ihm überhaupt eine Firewall aktiv ist !) und natürlich IP Forwarding.
Der OVPN Server bestimmt einzig und allein WO der Traffic des Clients in die Zielnetze hingeht.
Traceroute und/oder Pathping (Winblows) sind also immer deine besten Freunde hier !
Essentiell wichtig ist dann das auf diesem Server IP Forwarding aktiviert ist damit dieser die Zielnetze die der Client anfragt routen kann. Ohne aktives IP Forwarding (Routing) klappt das logischerweise nicht.
Da der Client ja ein Gateway Redirect macht schickt er all seinen Traffic generell in den Tunnel. Sprich sowie der OVPN Client aktiv ist geht dessen Traffic generell komplett in den Tunnel zum OpenVPN Server.
Am OpenVPN Server ist es dann essentiell wichtig das der alle diese Zielnetze kennt um die Client Requests entsprechend routen zu können.
Wie bereits mehrfach gesagt: Der OVPN Server ist der erste Routing Hop des OVPN Clients. Folglich muss also der Server eine wasserdichte Routing Tabelle haben in die Zielnetze, Firewall Regeln (sofern auf ihm überhaupt eine Firewall aktiv ist !) und natürlich IP Forwarding.
Der OVPN Server bestimmt einzig und allein WO der Traffic des Clients in die Zielnetze hingeht.
Traceroute und/oder Pathping (Winblows) sind also immer deine besten Freunde hier !
Zitat von @aqui:
Essentiell wichtig ist dann das auf diesem Server IP Forwarding aktiviert ist damit dieser die Zielnetze die der Client anfragt routen kann. Ohne aktives IP Forwarding (Routing) klappt das logischerweise nicht.
Da der Client ja ein Gateway Redirect macht schickt er all seinen Traffic generell in den Tunnel. Sprich sowie der OVPN Client aktiv ist geht dessen Traffic generell komplett in den Tunnel zum OpenVPN Server.
Essentiell wichtig ist dann das auf diesem Server IP Forwarding aktiviert ist damit dieser die Zielnetze die der Client anfragt routen kann. Ohne aktives IP Forwarding (Routing) klappt das logischerweise nicht.
Da der Client ja ein Gateway Redirect macht schickt er all seinen Traffic generell in den Tunnel. Sprich sowie der OVPN Client aktiv ist geht dessen Traffic generell komplett in den Tunnel zum OpenVPN Server.
- IP-Forwarding ist natürlich aktiviert
- firewall wie etwa iptables gibt es nicht
a) ich kann vom Client eine OVPN-Verbindung (ohne Stunnel) per UDP zum OVPN-Server aufbauen und alle Verbindungen laufen erfolgreich über den Server. ich kann alle Netze erreichen, sowohl öffentlich als auch meinen privaten.
b) ich kann vom Client eine OVPN-Verbindung (ohne Stunnel) per TCP zum OVPN-Server aufbauen und alle Verbindungen laufen erfolgreich über den Server. ich kann alle Netze erreichen, sowohl öffentlich als auch meinen privaten.
c) ich kann vom Client eine OVPN-Verbindung MIT stunnel per TCP zum OVPN-Server aufbauen, aber ich kann dann keinerlei IP erreichen, weder öffentliche private.
Die OVPN-Konfig auf dem Client ist bei c) die gleiche b), nur dass remote und der Port eben auf den Stunnel-Client auf localhost zeigen
routing-Tabelle auf dem client bei b) ---> alle funktioniert
root@android-at2qt0is15mk13b:/home/pi# route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.9.1 128.0.0.0 UG 0 0 0 tun0
default _gateway 0.0.0.0 UG 303 0 0 wlan0
10.0.9.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
HSI-KBW-095-208 _gateway 255.255.255.255 UGH 0 0 0 wlan0
128.0.0.0 10.0.9.1 128.0.0.0 UG 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0
root@android-at2qt0is15mk13b:/home/pi#routing-Tabelle auf dem client bei c)
root@android-at2qt0is15mk13b:/home/pi# route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.9.1 128.0.0.0 UG 0 0 0 tun0
default _gateway 0.0.0.0 UG 303 0 0 wlan0
10.0.9.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
localhost _gateway 255.255.255.255 UGH 0 0 0 wlan0
128.0.0.0 10.0.9.1 128.0.0.0 UG 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0
root@android-at2qt0is15mk13b:/home/pi# wo liegt der Fehler?
ich antworte mir mal selbst da ich den Fehler gefunden habe.
Das Tutorial
https://medium.com/@jayden.chua/stunnel-openvpn-server-on-ubuntu-18-04-1 ...
hatte doch recht.
- Man kann bei der OVPN-Server-Konfig die gleiche Server-Konfig verwenden die man auch bei einer OVPN-Verbindung ohne Stunnel nehmen würde.
- Auf Client-Seite müssen nur
a) der Zielserver - also der Eintrag bei Remote - auf den stunnel-Client (bei mir localhost) geändert werden
b) der Port muss ggf angepasst werden auf den Port des Stunnel-Clients
c) Ein einziger Eintrag muss in der OVPN-Client-Konfig ergänzt werden:
Mein Fehler war dass es eben kein "add" und kein "mask" in die Zeile gehört.
net_gateway spricht automatisch das richtige Gateway an, sprich es wird dynamisch ermittelt
And die Stelle der x kommt die öffentliche IP der Maschine auf der der Stunnel-Server (!) läuft.
Statt der IP kann auch ein DNS-Namen, z.B. ein DDNS-Namen, eingetragen werden. Das Betriebssystem löst dynamisch über DNS bei der Ausführung der Zeile den Namen zur richtigen IP auf und nimmt damit den richtigen Routing-Eintrag vor.
In einigen Tutorials wird davon gesprochen dass nicht für die eine IP des Stunnel-Servers ein Routing-Eintrag gesetzt wird, sondern ein ganzes Subnetz (route x.x.x.0 255.255.255.0 net_gateway). Dies macht nur in den Fällen Sinn wenn mehrere IPs erreicht werden sollen.
Bei mir laufen Stunnel-Server und OVPN-Server auf der gleichen Maschine. Die Maschine steht hinter einem Router in einem privaten LAN (192.168.x.x). Der OVPN-Server vergibt Adressen aus einem anderen privaten Bereich (z.B. 10.x.x.x)
Über den Router ist der Server von aussen über eine öffentliche IP Erreichbar.
Um nun meine Frage zu beantworten welche IP man nehmen muss anstelle der X.x.x.x, es ist die öffentliche IP (es kann wie beschrieben auch ein DNS-Namen verwendet werden)
Und die Frage nach dem Next_Hop auf dem Client, das ist eben nicht der VPN-Server (keine IP von dem), sondern das ist das Gateway des Clients (!) über den die Verbindung zum Stunnel-Server gehen soll.
Der Stunnel-Client soll bei mir sich über das Internet zum Stunnel-Server verbinden. Daher ist das das Gateway des Clients in's Internet. Und dieses wird über die die Funktion net_gateway vom OS beim Verbindungsaufbau dynamisch ermittelt.
Um in einem Satz die Frage des Threads zu beantworten, eine Ausnahme für die Stunnelverbindung, dass diese nicht in den OVPN-Tunnel geleitet wird, wird über Routingeintrag in der OVPN-Client-Konfig angelegt der nach diesem Muster aufgebaut ist:
Das Tutorial
https://medium.com/@jayden.chua/stunnel-openvpn-server-on-ubuntu-18-04-1 ...
hatte doch recht.
- Man kann bei der OVPN-Server-Konfig die gleiche Server-Konfig verwenden die man auch bei einer OVPN-Verbindung ohne Stunnel nehmen würde.
- Auf Client-Seite müssen nur
a) der Zielserver - also der Eintrag bei Remote - auf den stunnel-Client (bei mir localhost) geändert werden
b) der Port muss ggf angepasst werden auf den Port des Stunnel-Clients
c) Ein einziger Eintrag muss in der OVPN-Client-Konfig ergänzt werden:
route x.x.x.x 255.255.255.255 net_gatewayMein Fehler war dass es eben kein "add" und kein "mask" in die Zeile gehört.
net_gateway spricht automatisch das richtige Gateway an, sprich es wird dynamisch ermittelt
And die Stelle der x kommt die öffentliche IP der Maschine auf der der Stunnel-Server (!) läuft.
Statt der IP kann auch ein DNS-Namen, z.B. ein DDNS-Namen, eingetragen werden. Das Betriebssystem löst dynamisch über DNS bei der Ausführung der Zeile den Namen zur richtigen IP auf und nimmt damit den richtigen Routing-Eintrag vor.
In einigen Tutorials wird davon gesprochen dass nicht für die eine IP des Stunnel-Servers ein Routing-Eintrag gesetzt wird, sondern ein ganzes Subnetz (route x.x.x.0 255.255.255.0 net_gateway). Dies macht nur in den Fällen Sinn wenn mehrere IPs erreicht werden sollen.
Bei mir laufen Stunnel-Server und OVPN-Server auf der gleichen Maschine. Die Maschine steht hinter einem Router in einem privaten LAN (192.168.x.x). Der OVPN-Server vergibt Adressen aus einem anderen privaten Bereich (z.B. 10.x.x.x)
Über den Router ist der Server von aussen über eine öffentliche IP Erreichbar.
Um nun meine Frage zu beantworten welche IP man nehmen muss anstelle der X.x.x.x, es ist die öffentliche IP (es kann wie beschrieben auch ein DNS-Namen verwendet werden)
Und die Frage nach dem Next_Hop auf dem Client, das ist eben nicht der VPN-Server (keine IP von dem), sondern das ist das Gateway des Clients (!) über den die Verbindung zum Stunnel-Server gehen soll.
Der Stunnel-Client soll bei mir sich über das Internet zum Stunnel-Server verbinden. Daher ist das das Gateway des Clients in's Internet. Und dieses wird über die die Funktion net_gateway vom OS beim Verbindungsaufbau dynamisch ermittelt.
Um in einem Satz die Frage des Threads zu beantworten, eine Ausnahme für die Stunnelverbindung, dass diese nicht in den OVPN-Tunnel geleitet wird, wird über Routingeintrag in der OVPN-Client-Konfig angelegt der nach diesem Muster aufgebaut ist:
route x.x.x.x 255.255.255.255 net_gateway ich kann vom Client eine OVPN-Verbindung (ohne Stunnel) per UDP zum OVPN-Server aufbauen
"ohne Stunnel"" ist ja unsinnig, sorry. Der Client "sieht" ja nur seine Default Route auf den Server. Er schickt dann seinen sämtlichen Traffic in den VPN Tunnel bei einem Redirect. Wenn er das Stunnel Zielnetz erreichen will dann natürlich auch den Stunnel Traffic. Die o.a. Aussage ist also technisch falsch oder zumindestens sehr unglücklich formuliert, weisst du auch sicher selber....?!ich kann alle Netze erreichen, sowohl öffentlich als auch meinen privaten.
Aber wenn das stimmt geht doch alles ?! Das inkludiert ja dann auch den Stunnel Netz oder wie ist das zu verstehen ?? Was diskutieren wir dann hier also ??Die Beschreibung ist generell wirr und mit den obigen Angaben noch verworrener. Jetzt sagst du mit einmal der nicht der OpenVPN Server eine Stunnel Connection aufbaut sondern mit einmal der Client....
Was denn nun ??
Wenn der Client parallel zu OpenVPN auch noch eine zusätzliche VPN Verbindung aufbaust, sprich also 2 parallele VPN Tunnel (OVPN plus Stunnel) hast dann hast du ja auf dem Client einen Konflikt.
Vermutlich greifen dann irgendwelche Gateway Prioritäten, denn der Client hat ja mit einem aktiven OpenVPN Tunnel der ihm per Gateway Redirect zwingt ALLES an Traffic in den OVPN Tunnel zu leiten jetzt einen gravierenden Konflikt mit dem Stunnel VPN. Dessen Traffic fällt dann hinten über oder noch schlimmer...wenn dort auch ein Gateway Redirect erzwungen wird dreht sich der Client im Kreis...
Das ist doch eine simple Logik, die aber mit deinen immer wechselnden Beschreibungen nicht klarer wird.
Generell ist natürlich 2 unterschiedliche VPN protokolle auf einem Endgerät zu haben die nichts voneinander wissen keine besonders intelligente Idee. Das weisst du sicher auch selber....
Die Routing Tabellen zeigen ja auch das es keinerlei Routen in ein etwaiges Stunnel Interface gibt. tun0 ist das OpenVPN Tunnel Interface und dort zeigt ja auch wie gewollt die default Route hin. Works as designed...
Von Stunnel ist (jedenfalls am Client) weit und breit nix zu sehen in der Routing Tabelle !!
Zitat von @aqui:
Die Beschreibung ist generell wirr und mit den obigen Angaben noch verworrener. Jetzt sagst du mit einmal der nicht der OpenVPN Server eine Stunnel Connection aufbaut sondern mit einmal der Client....
Die Beschreibung ist generell wirr und mit den obigen Angaben noch verworrener. Jetzt sagst du mit einmal der nicht der OpenVPN Server eine Stunnel Connection aufbaut sondern mit einmal der Client....
Das stimmt doch gar nicht.
Ein Server stellt nur Dienste bereit. Die Nutzung wird immer von einem Client initiert.
Der OVPN-client sagt dem Stunnel-Client dass eine Verbindung gewünscht wird
Der Stunnel-Client kontaktiert den Stunnel-Server
Der Stunnel-Client reicht die Nutzdaten des OVPN-Clients an den Stunnel-Server weiter
Der Stunnel-Server gibt die übermittelten Daten an den OVPN-Server weiter.
Wenn der Client parallel zu OpenVPN auch noch eine zusätzliche VPN Verbindung aufbaust, sprich also 2 parallele VPN Tunnel (OVPN plus Stunnel) hast dann hast du ja auf dem Client einen Konflikt.
Was habt ihr beide immer mit 2 parallelen VPN-Verbindungen???
Es wird ein Tunnel durch den anderen Tunnel aufgebaut.
Der OVPN-Tunnel geht durch den Stunnel-Tunnel.
Der OVPN-Client startet und schubst den Stunnel-Client an. Der Stunnel-Client und der Stunnel Server bauen eine Verbindung auf. Wenn diese steht, dann vervollständigen OVPN-Client und OVPN-Server ihre Verbindung durch den Stunnel-Tunnel hindurch.
Zu meinem OVPN-Server hat man 3 Zugangsmöglichkeiten:
per UDP, per TCP, und über Stunnel (Tunnel in Tunnel).
Du bist mir gekommen mit ip-Forwarding nicht gesetzt und Fehler auf dem Server suchen. Die ersten beiden Möglichkeiten sollten dir sagen dass die OVPN-Konfig in Ordnung ist und die Kommunikation bei diesen beiden Möglichkeiten wie gewünscht funktioniert, mehr nicht.
Wenn es mit den gleichen Konfigs dann bei Variante 3 nicht geht, dann kann es nur an Stunnel oder am Routing liegen.
Vermutlich greifen dann irgendwelche Gateway Prioritäten, denn der Client hat ja mit einem aktiven OpenVPN Tunnel der ihm per Gateway Redirect zwingt ALLES an Traffic in den OVPN Tunnel zu leiten
Um es nochmal deutlicher zu machen:
Es soll auch wirklich aller Traffic des Clients durch den Tunnel im Tunnel gehen!
Es geht nicht nur darum das private Netzwerk hinter dem Server erreichbar zu machen.
Anders formuliert: Wenn ich auf dem Client im Browser www.test.de aufrufe, dann soll das durch den Tunnel gehen. Und wenn ich mir ein Laufwerk von einem NAS in meinem privaten LAN mounten will, dann soll dies auch durch den Tunnel gehen.
Richtig, das Gateway Redirect von OVPN zwingt ALLES in den eigenen Tunnel, so auch die Verbindung Stunnel-Client zu Stunnel-Server.
Und genau deshalb muss durch den zusätzlichen Routingeintrag dem Stunnel-Client der Weg zum Stunnel-Server gezeigt werden.
Die Verbindung zum Stunnel-Server soll also NICHT in den OVPN-Tunnel. Verstehst du jetzt warum ich im Thread-Titel geschrieben habe "Ausnahme anlegen".
Die Routing Tabellen zeigen ja auch das es keinerlei Routen in ein etwaiges Stunnel Interface gibt.
Was soll das für ein Interface sein???
Weder der Stunnel-Client noch der Stunnel-Server legen ein weiteres Interface an. wenn ich mit ifconfig schaue, dann gibt es keinen weiteren Eintrag.
OVPN-client und OVPN-Server, die legen jeweils ein tun-Device an.
Wenn du mit Putty einen SSH-Tunnel machst, dann wird doch auch kein weiteres virtuelles Device angelegt.
Oder ein Browser, der legt doch auch kein Device an wenn er einen Webserver kontaktiert.
OK, dann bleibt es also glücklicherweise beim Server das der das dann beides macht und der Client reint nur OpenVPN. Gut....
Wenn ja: Was ergibt ein Traceroute dahin ??
Ist das Stunnel Interface ggf. eine Bridging was über den Tunnel nur ein eh vorhandenes lokales LAN bridged ?
Wichtig ist die Routing Tabelle des Servers NICHT der Clients !!
Auf dem Server also bitte einmal ein ip route show oder netstat -r -n ausführen !
Dort MUSS ja eine Route über den Stunnel Link zu sehen sein !
Letztlich ist es ganz einfach: Alles was der Server über Stunnel erreichen kann kann dann auch der OVPN Client. Das ist auch logisch, denn der OVPN Client schickt ja alles an den Server und der routet dann weiter.
Spannend ist hier aber die Rückroute !!
Der OVPN Client kommt ja am Server mit einer IP Adresse des internen OVPN Netzwerkes 10.0.9.x an.
Erreicht diese IP nun das Endgerät am anderen Ende des Stunnel Tunnels und hat dieses keine Route die das 10.0.9.0er Netz wieder zurück in den Stunnel Tunnel zum Server schickt dann landet das Antwort Paket für den OVPN Client im Nirwana.
Geht dann über den lokalen Router dort und da RFC 1918 Privatnetz dann in den Datenmülleimer beim Provider. Genau das ist vermutlich deine Situation, das die Rückroute nicht via Stunnel Tunnel geht !
Auf der remoten Stunnel Seite müssen also beide IP Netze 192.168.100.0 und 10.0.9.0 in den Stunnel Tunnel geroutet werden !
Sprich von remote (Stunnel Ende) muss man den OVPN Server mit beiden IP Adressen in seinem 192.168.100.0 und 10.0.9.0 Netz pingbar sein !
Traceroute ebenso denn das zeigt dir auch den Routing Weg an.
wenn ich mit ifconfig schaue, dann gibt es keinen weiteren Eintrag.
Sehr komisch... Du kannst aber Endgeräte am remoten Stunnel Ende über den Stunnel Link vom Server aus pingen ??Wenn ja: Was ergibt ein Traceroute dahin ??
Ist das Stunnel Interface ggf. eine Bridging was über den Tunnel nur ein eh vorhandenes lokales LAN bridged ?
Wichtig ist die Routing Tabelle des Servers NICHT der Clients !!
Auf dem Server also bitte einmal ein ip route show oder netstat -r -n ausführen !
Dort MUSS ja eine Route über den Stunnel Link zu sehen sein !
Letztlich ist es ganz einfach: Alles was der Server über Stunnel erreichen kann kann dann auch der OVPN Client. Das ist auch logisch, denn der OVPN Client schickt ja alles an den Server und der routet dann weiter.
Spannend ist hier aber die Rückroute !!
Der OVPN Client kommt ja am Server mit einer IP Adresse des internen OVPN Netzwerkes 10.0.9.x an.
Erreicht diese IP nun das Endgerät am anderen Ende des Stunnel Tunnels und hat dieses keine Route die das 10.0.9.0er Netz wieder zurück in den Stunnel Tunnel zum Server schickt dann landet das Antwort Paket für den OVPN Client im Nirwana.
Geht dann über den lokalen Router dort und da RFC 1918 Privatnetz dann in den Datenmülleimer beim Provider. Genau das ist vermutlich deine Situation, das die Rückroute nicht via Stunnel Tunnel geht !
Auf der remoten Stunnel Seite müssen also beide IP Netze 192.168.100.0 und 10.0.9.0 in den Stunnel Tunnel geroutet werden !
Sprich von remote (Stunnel Ende) muss man den OVPN Server mit beiden IP Adressen in seinem 192.168.100.0 und 10.0.9.0 Netz pingbar sein !
Traceroute ebenso denn das zeigt dir auch den Routing Weg an.
Zitat von @aqui:
Sehr komisch... Du kannst aber Endgeräte am remoten Stunnel Ende über den Stunnel Link vom Server aus pingen ??
Wenn ja: Was ergibt ein Traceroute dahin ??
Sehr komisch... Du kannst aber Endgeräte am remoten Stunnel Ende über den Stunnel Link vom Server aus pingen ??
Wenn ja: Was ergibt ein Traceroute dahin ??
Selbstverständlich. ping ist ja das erste womit man prüft ob eine funktionierende Verbindung besteht. Ich kann von beiden Seiten aus pingen, sowohl mit dem DNS-Namen als auch mit IP
Und traceroute liefert auch den korrekten Weg
Ist das Stunnel Interface ggf. eine Bridging was über den Tunnel nur ein eh vorhandenes lokales LAN bridged ?
Eine Brücke würde ja auch wieder ein eigenes virtuelles Device erzeugen wie ein br01, oder?
Wichtig ist die Routing Tabelle des Servers NICHT der Clients !!
Auch die Tabelle auf dem Client ist wichtig. Ist dort kein Eintrag vorhanden wie der Client zu seinem Server findet, dann bringt alles andere nichts.
Du hast es doch mit IP-Forward selbst gesagt. Damit finden sich alle Netze die der Server kennt
Auf dem Server also bitte einmal ein ip route show oder netstat -r -n ausführen !
Dort MUSS ja eine Route über den Stunnel Link zu sehen sein !
Auch wenn du es nicht glaubst, es gibt da nichts:Dort MUSS ja eine Route über den Stunnel Link zu sehen sein !
default via 192.168.3.103 dev wlan0 onlink
10.0.8.0/24 dev tun0 proto kernel scope link src 10.0.8.1
10.0.9.0/24 dev tun1 proto kernel scope link src 10.0.9.1
192.168.3.0/24 dev wlan0 proto kernel scope link src 192.168.3.1020.0.0.0 192.168.3.103 0.0.0.0 UG 0 0 0 wlan0
10.0.8.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.0.9.0 0.0.0.0 255.255.255.0 U 0 0 0 tun1
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0Letztlich ist es ganz einfach: Alles was der Server über Stunnel erreichen kann kann dann auch der OVPN Client. Das ist auch logisch, denn der OVPN Client schickt ja alles an den Server und der routet dann weiter.
Eben, das ist ja überhaupt das große Ganze dass bei mir über dem Thema Tunnel, VPN, usw. steht, nämlich einen Client von aussen über sichere Wege in das heimische LAN zu bringen.
Spannend ist hier aber die Rückroute !!
Der OVPN Client kommt ja am Server mit einer IP Adresse des internen OVPN Netzwerkes 10.0.9.x an.
Erreicht diese IP nun das Endgerät am anderen Ende des Stunnel Tunnels und hat dieses keine Route die das 10.0.9.0er Netz wieder zurück in den Stunnel Tunnel zum Server schickt dann landet das Antwort Paket für den OVPN Client im Nirwana.
Der OVPN Client kommt ja am Server mit einer IP Adresse des internen OVPN Netzwerkes 10.0.9.x an.
Erreicht diese IP nun das Endgerät am anderen Ende des Stunnel Tunnels und hat dieses keine Route die das 10.0.9.0er Netz wieder zurück in den Stunnel Tunnel zum Server schickt dann landet das Antwort Paket für den OVPN Client im Nirwana.
Das geht einfach.
Der DSL-Router auf Server-Seite hat zwei statische Routing-Einträge. Wenn also im 192.168.x.0 Netz jemand zu einem Host in 10.0.9.x oder 10.0.8.x will, dann sagt ihm der DSL-Router dass eben die besagte Server-Maschine 192.168.x.x der Zugang in diese beiden Netzte ist.
Und da sind wir wieder bei dem was ich schon mehrfach erwähnt habe. Der Server hat mehrere IP-Adressen aus unterschiedlichen Netzen:
192.168.3.102
10.0.8.1
10.0.9.1
Und die Übergabe zwischen diesen, genau dafür ist das IP-Forwarding zuständig das man auf dem Server einschaltet.
Aber das hat überhaupt nichts mit dem Problem/Ursache zu tun mit dem ich diesen Thread gestartet habe.
Auf der remoten Stunnel Seite müssen also beide IP Netze 192.168.100.0 und 10.0.9.0 in den Stunnel Tunnel geroutet werden !
das glaube ich nicht. Darum kümmert sich OVPN.
192.168.100.0 ist das Netz in dem der Client sich verbunden hat, also z.B. das Hotspot-Netz.
Schau mal in die OVPN-Doku was dort bei redirect gateway steht. Das "Gateway-Netzwerk", also das "Hotspot-Netz", wird als einziges nicht in den Tunnel geschickt.
Das wäre ja auch ein Sicherheitsrisiko wenn jemand anderer aus 192.168.100.0 in den Tunnel gelangen könnte.
Mit redirect gateway block-local zusätzlich könntest du noch verhindern dass mein Client nicht zu anderen in dem fremden Netz 192.168.100.0 kommt.
Letztendlich muss man sich aber immer bewusst sein dass der Client in seinem IP-Stack physikalisch ein fremdes Netz mit den eigenen Netzen verbindet.
Auch die Tabelle auf dem Client ist wichtig.
Nein, das ist unsinnig. Logisch, denn den Client schickt eh alles in den OVPN Tunnel. Wo und warum ist denn da eine Routing Tabelle wichtig ??ping ist ja das erste womit man prüft ob eine funktionierende Verbindung besteht.
Richtig !Relevant ist aber immer die Absender IP des Pings. Wichtig ist also für einen Ping vom Server zu einem Endgerät am Ende des Stunnel Tunnels das der Server unbedingt seine OVPN IP Adresse 10.0.9.x als Absender IP verwendet ! Also ping -c 4 -S 10.0.9.1 x.y.z.h
x.y.z.h ist hier die Endgeräte IP am Stunnel Netz. Hast du das so gepingt ??
Nur so kannst du doch sicher verifizieren das auch die Rückroute aus dem Stunnel Netz zum Server auch OK und richtig ist. Eigentlich sollte dieser Ping von deinem Server scheitern.
Scheitert das wider Erwarten nicht, dann wäre es unverständlich warum dann der Client Traffic in dieses Netz nicht geroutet wird. Dann bleibt nur noch iptables Firewall oder Firewall an den Clients oder sowas.
Auch wenn du es nicht glaubst, es gibt da nichts:
Glaube ich schon... Das sieht ja auch gut aus, denn dort gibt es ja 2 Tunnel. 10.0.9.0 ist OpenVPN und 10.0.8.0 der Stunnel Tunnel.Das Routing vom DSL Router ist auch absolut OK und hat in der Tat mit der eigentlichen Aufgabestellung nix zu tun.
das glaube ich nicht. Darum kümmert sich OVPN.
Sorry, jetzt wirds schon wieder wirr und unverständlich... Das liegt daran das du keinerlei Skizze erstellt hast und das IP Routing hier nicht sauber beschrieben hast ??
Wir gehen jetzt davon aus das der Server einmal das OpenVPN Netz bedient und einmal das Stunnel Netz.
Jetzt nach der Äußerung ist das wohl wieder falsch und der Stunnel ist nur ein Overlay !?!
Sprich du hast VPN seitig ALLES mit OpenVPN gemacht und sattelst dann dort von OVPN Client zu OVPN Client noch einen Stunnel obendrauf ?? Ist das jetzt so richtig ?!
Wenn ja hast du Recht !
Dann "sehen" IP technisch die OVPN Clients nur das internen OVPN Netz, dann passiert das Routing in den Stunnel Tunnel rein nur auf den Clients. Der Server ist dann komplett aussen vor. Das würde aber dann erzwingen das du eine Clit zu Client Kommunikation im OpenVPN erlaubst was dann zwingend das Kommando client-to-client in der OVPN Server Konfig erzwingt. Andernfalls ist eine direkt Client Kommunikation nicht möglich.
Desweiteren wirst du durch diesen Tunnel in einem Tunnel massiv in MTU Problematiken rennen, denn die Stunnel MTU muss dann erheblich kleiner sein um Fragmentierung zu vermeiden. Fragmentierung bedeutet das diese Frames dann geblockt werden.
Was dann aber der Sinn dieses doppelten Tunnels sein soll erschliesst sich einem nicht wirklich. Normal ist sowas Blödsinn. Wozu auch wenn du alles schon wasserdicht sicher mit OpenVPN überträgst.
Verstehen tut man das nicht wirklich...
Hoffentlich ist denn nun endlich diese letzte Version deines Designs die die man verstehen muss...
So wie ich es jetzt verstanden habe, will der TO folgendes:
Einen stunnel aufbauen und dann über den stunnel eine OpenVPN-Verbindung aufbauen.
Einen stunnel aufbauen und dann über den stunnel eine OpenVPN-Verbindung aufbauen.
Zitat von @aqui:
Auch die Tabelle auf dem Client ist wichtig.
Nein, das ist unsinnig. Logisch, denn den Client schickt eh alles in den OVPN Tunnel. Wo und warum ist denn da eine Routing Tabelle wichtig ??du erinnerst dich was ich gesagt habe, OVPN-UDP-only und OVPN-TCP-only funktionieren, OVPN-Stunnel-tcp nicht?
Der Stunnel-Client braucht eine Route zum Stunnel-Server.
Und wo läuft der Stunnel-Client? Richtig, auf dem Client. Und in welcher Tabelle muss die Route eingetragen sein? Richtig, die auf dem Client. Ergo, wenn es da keine Route gibt, bringt die alles andere nichts, oder?
Glaube ich schon... Das sieht ja auch gut aus, denn dort gibt es ja 2 Tunnel. 10.0.9.0 ist OpenVPN und 10.0.8.0 der Stunnel Tunnel.
Das sieht ja auch gut aus, denn dort gibt es ja 2 Tunnel. 10.0.9.0 ist OpenVPN und 10.0.8.0 der Stunnel Tunnel.leider falsch
Wie du am Device (= tun0 und tun1) erkennen kannst, sind das die beiden Instanzen des OVPN-Servers, eine für UDP und eine für TCP
Das liegt daran das du keinerlei Skizze erstellt hast und das IP Routing hier nicht sauber beschrieben hast ??
doch, ich habe es sauber in Worten beschriebenWir gehen jetzt davon aus das der Server einmal das OpenVPN Netz bedient und einmal das Stunnel Netz.
etwas unglücklich formuliert, aber ja, wie ich auch bereits geschrieben habe OVPN-Server und Stunnel-Server laufen auf der gleichen Maschine.Sprich du hast VPN seitig ALLES mit OpenVPN gemacht und sattelst dann dort von OVPN Client zu OVPN Client noch einen Stunnel obendrauf ?? Ist das jetzt so richtig ?!
???
OVPN-Client zu OVPN-Client??? nein
Der Stunnel-Client sprich mit dem Stunnel-Server. Und der OVPN-Client spricht mit dem OVPN-Server durch den SSH-Tunnel.
Da sprechen keine Clients miteinander.
Das würde aber dann erzwingen das du eine Clit zu Client Kommunikation im OpenVPN erlaubst was dann zwingend das Kommando client-to-client in der OVPN Server Konfig erzwingt. Andernfalls ist eine direkt Client Kommunikation nicht möglich.
Ich habe aber definitiv client-to-client deaktiviert Desweiteren wirst du durch diesen Tunnel in einem Tunnel massiv in MTU Problematiken rennen, denn die Stunnel MTU muss dann erheblich kleiner sein um Fragmentierung zu vermeiden.
ich hatte doch geschrieben dass ich mir des Performance-Verlustes bewusst bin.
Und dass man die MTU-Größen aufeinander abstimmen muss, das ist auch richtig, da ja ein tcp-Paket wieder in ein Tcp-Paket gepackt wird.
Was dann aber der Sinn dieses doppelten Tunnels sein soll erschliesst sich einem nicht wirklich. Normal ist sowas Blödsinn. Wozu auch wenn du alles schon wasserdicht sicher mit OpenVPN überträgst.
auch dazu hatte ich was geschrieben.
OVPN-Traffic nutzt keine SSL-Verschlüsselung wie sie z.B. bei Webservern der Fall ist. Eine DPI oder was auch immer kann somit relativ einfach von aussen feststellen dass da kein SSL-Verkehr stattfindet.
Stunnel und auch obfuscation beheben dieses Problem.
Jetzt kommt bestimmt die Frage warum man dann überhaupt OVPN nutzt und nicht nur einen SSH-Tunnel. Ganz einfach, weil keines der Tools für einen SSH-Tunnel eine Funktion wie redirect gateway def1 kennt wie es OVPN kann.
Und es ist ja mehr wie mühselig für jeden Dienst einen separaten Tunnel zu machen bzw. jeden Dienst von Hand so zu konfigurieren dass er den Weg durch den Tunnel nimmt.
Dieses "redirect gateway def1" ist absolut sexy. Das leitet für alle Anwendungen völlig transparent den Traffic durch einen Tunnel ohne dass in der Anwendung was konfiguriert werden muss.
Gib doch einfach in eine Suchmaschine deiner Wahl OVPN + Stunnel ein. Die ersten Treffer beschreiben alles dieses Problem.
Einen stunnel aufbauen und dann über den stunnel eine OpenVPN-Verbindung aufbauen.
Ist ja genau der gleiche Unsinn in Grün. Den Sinn davon muss man erstmal verstehen wenn man so oder so schon OVPN nutzt.Muss man sicher auch nicht verstehen...und sinnfrei sich noch weiter damit abzumühen.
Zitat von @aqui:
Einen stunnel aufbauen und dann über den stunnel eine OpenVPN-Verbindung aufbauen.
Ist ja genau der gleiche Unsinn in Grün. Den Sinn davon muss man erstmal verstehen wenn man so oder so schon OVPN nutzt.das Zitat ist zwar von BirdyB, aber hast du die Antwort von mir vom 09.10. gelesen?
Da hatte ich genau beschrieben welchen Sinn das ganze hat.
Du bestätigst da ja auch den hier befürchteten Unsinn einen Tunnel im Tunnel zu machen. Was soll der tiefere Sinn davon sein ?
Gut, aber wenigstens ist nach der endlosen Eierei die Technik denn nun endlich mal geklärt.
Dann muss man natürlich beide Welten vollkommen getrennt sehen aus IP Adressierungs Sicht. Der Stunnel Link ist dann wie eine separate IP Punkt zu Punkt Verbindung zu sehen. Dadurch das die eh einen Bridge Charakter hat wird man darüber nicht routen können bzw. wenn dann nur über die Primärinterfaces die routingtechnisch zu sehen sind in der Routing Tabelle. Der Stunnel Tunnel hat ja keine virtuellen Interfaces und ist deshalb nicht sichtbar in der Routing Tabelle. Vermutlich schliesst das dann ein Routing mehrere IP Netze schon rein physisch aus.
Ob das so ist müsste man einmal in einem Laboraufbau testen. Generell ist das aber Unsinn. Allein schon die massive MTU Problematik von solchen Doppeltunnels wäre schon ein NoGo. Wie gesagt...die Sinnhaftigkeit erschliesst sich einem da nicht wirklich.
Gut, aber wenigstens ist nach der endlosen Eierei die Technik denn nun endlich mal geklärt.
Dann muss man natürlich beide Welten vollkommen getrennt sehen aus IP Adressierungs Sicht. Der Stunnel Link ist dann wie eine separate IP Punkt zu Punkt Verbindung zu sehen. Dadurch das die eh einen Bridge Charakter hat wird man darüber nicht routen können bzw. wenn dann nur über die Primärinterfaces die routingtechnisch zu sehen sind in der Routing Tabelle. Der Stunnel Tunnel hat ja keine virtuellen Interfaces und ist deshalb nicht sichtbar in der Routing Tabelle. Vermutlich schliesst das dann ein Routing mehrere IP Netze schon rein physisch aus.
Ob das so ist müsste man einmal in einem Laboraufbau testen. Generell ist das aber Unsinn. Allein schon die massive MTU Problematik von solchen Doppeltunnels wäre schon ein NoGo. Wie gesagt...die Sinnhaftigkeit erschliesst sich einem da nicht wirklich.
Zitat von @aqui:
Du bestätigst da ja auch den hier befürchteten Unsinn einen Tunnel im Tunnel zu machen. Was soll der tiefere Sinn davon sein ?
Allein schon die massive MTU Problematik von solchen Doppeltunnels wäre schon ein NoGo. Wie gesagt...die Sinnhaftigkeit erschliesst sich einem da nicht wirklich.
Du bestätigst da ja auch den hier befürchteten Unsinn einen Tunnel im Tunnel zu machen. Was soll der tiefere Sinn davon sein ?
Allein schon die massive MTU Problematik von solchen Doppeltunnels wäre schon ein NoGo. Wie gesagt...die Sinnhaftigkeit erschliesst sich einem da nicht wirklich.
Weißt du einen besseren Weg wie man OVPN-/VPN-Verbindungen verstecken kann so dass sie durch eine DPI nicht blockiert werden können?
zu MTU: Nun, eine schlechte/langsame Verbindung ist besser als gar keine Verbindung durch Blockade, oder?
