Openvpn per stunnel verstecken (Openvpn läuft ausserhalb stunnel problemlos) (Raspberry Pi - Android)

Hallo,

ich möchte meinen Openvpn Traffic vor der Telekom verstecken, weil die per DPI den Verbindungsaufbau blocken.

Der Tunnel baut sich im stunnel problemlos auf, nur kommt kein Routing zustande.

Zum Testen steht mir ein Wlan vom Nachbarn zur Verfügung, um weitere Fehler die per UMTS auftreten könnten erstmal ausschliessen zu können.

Das VPN läuft mit der selben Konfig problemlos ausserhalb des SSL Tunnels.
Das Problem könnte sein, dass sich der OpenVpn Client auf dem Handy erst auf den localhost verbindet und von dort aus dann der SSL Tunnel aufgebaut wird. Hier ist wohl ein Routingproblem...... Da ich einen Tap Tunnel nutze, habe ich keinerlei Routing in meinen openvpn configs.

Liegt das Problem wirklich am localhost ?

Das sind meine configs.

stunnel Server

cert = /etc/stunnel/keys/cert-server.pem
key = /etc/stunnel/keys/key-server.pem
sslVersion = all
foreground = yes
pid = /var/run/stunnel4.pid
[service]
accept  = 443
connect = 192.168.11.7:8080

stunnel Client

client = yes
foreground = yes
[openvpn]
accept  = 8080
connect = meine.dyndns.adresse:443

OpenVpn Server

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
auth SHA1
cipher AES-256-CBC

dev tap0
persist-tun

proto tcp-server
local 192.168.11.7
port 8080

mode server
tls-server
ifconfig-pool 192.168.11.46 192.168.11.50 255.255.255.0
push "route-gateway 192.168.11.1"  
push "redirect-gateway def1"  
push "dhcp-option DNS 192.168.11.1"  
client-to-client
comp-lzo
keepalive 10 200
nice 1
verb 4
float

OpenVpn Client

client
ca ca.crt
cert client1.crt
key client1.key
auth SHA1
cipher AES-256-CBC
dev tap
dev-node /dev/tun
proto tcp
tun-mtu 1500
nobind
tls-client
ns-cert-type server #for OVP2.0 and below: check the server.crt
pull	
remote localhost 8080
comp-lzo
verb 4
persist-tun 
persist-key
nice 1

Mit den OpenVpn Configs kann ich problemlos den Tunnel über Wlan Hotspots aufbauen, das routing klappt, ich kann alles im Lan erreichen und den Internet Traffic über mein Heimnetz routen. Die "remote" Befehle sind hier natürlich für stunnel angepasst. Normalerweise habe ich die Dyndns Addresse dort stehen.

Client Log

Sun Mar 16 23:05:32 2014 OpenVPN 2.1.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Jan  6 2012
Sun Mar 16 23:05:32 2014 MANAGEMENT: TCP Socket listening on 127.0.0.1:26112
Sun Mar 16 23:05:32 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables  
Sun Mar 16 23:05:32 2014 WARNING: file 'client1.key' is group or others accessible  
Sun Mar 16 23:05:32 2014 LZO compression initialized
Sun Mar 16 23:05:32 2014 Control Channel MTU parms [ L:1592 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sun Mar 16 23:05:32 2014 Data Channel MTU parms [ L:1592 D:1450 EF:60 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Mar 16 23:05:32 2014 Local Options hash (VER=V4): '44fbca6b'  
Sun Mar 16 23:05:32 2014 Expected Remote Options hash (VER=V4): '570d8093'  
Sun Mar 16 23:05:32 2014 nice 1 succeeded
Sun Mar 16 23:05:32 2014 Attempting to establish TCP connection with 127.0.0.1:8080 [nonblock]
Sun Mar 16 23:05:32 2014 TCP connection established with 127.0.0.1:8080
Sun Mar 16 23:05:32 2014 Socket Buffers: R=[1048576->131072] S=[524288->131072]
Sun Mar 16 23:05:32 2014 TCPv4_CLIENT link local: [undef]
Sun Mar 16 23:05:32 2014 TCPv4_CLIENT link remote: 127.0.0.1:8080
Sun Mar 16 23:05:32 2014 MANAGEMENT: Client connected from 127.0.0.1:26112
Sun Mar 16 23:05:32 2014 MANAGEMENT: CMD 'state'  
Sun Mar 16 23:05:32 2014 MANAGEMENT: CMD 'state on'  
Sun Mar 16 23:05:32 2014 MANAGEMENT: CMD 'bytecount 0'  
Sun Mar 16 23:05:32 2014 MANAGEMENT: >STATE:1395007532,AUTH,,,
Sun Mar 16 23:05:32 2014 TLS: Initial packet from 127.0.0.1:8080, sid=7a20735a 74cee18a
Sun Mar 16 23:05:32 2014 MANAGEMENT: CMD 'bytecount 0'  
Sun Mar 16 23:05:32 2014 VERIFY OK: depth=1, /C=DE/ST=***********************************entfernt :)
Sun Mar 16 23:05:32 2014 VERIFY OK: nsCertType=SERVER
Sun Mar 16 23:05:32 2014 VERIFY OK: depth=0, /C=DE/ST=***********************************entfernt :)
Sun Mar 16 23:05:33 2014 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key  
Sun Mar 16 23:05:33 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication  
Sun Mar 16 23:05:33 2014 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key  
Sun Mar 16 23:05:33 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication  
Sun Mar 16 23:05:33 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Mar 16 23:05:33 2014 [SERVER] Peer Connection Initiated with 127.0.0.1:8080
Sun Mar 16 23:05:34 2014 MANAGEMENT: >STATE:1395007534,GET_CONFIG,,,
Sun Mar 16 23:05:34 2014 MANAGEMENT: CMD 'bytecount 0'  
Sun Mar 16 23:05:35 2014 SENT CONTROL [SERVER]: 'PUSH_REQUEST' (status=1)  
Sun Mar 16 23:05:35 2014 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.11.1,redirect-gateway def1,dhcp-option DNS 192.168.11.1,ping 10,ping-restart 200,ifconfig 192.168.11.46 255.255.255.0'  
Sun Mar 16 23:05:35 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sun Mar 16 23:05:35 2014 OPTIONS IMPORT: --ifconfig/up options modified
Sun Mar 16 23:05:35 2014 OPTIONS IMPORT: route options modified
Sun Mar 16 23:05:35 2014 OPTIONS IMPORT: route-related options modified
Sun Mar 16 23:05:35 2014 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Mar 16 23:05:35 2014 ROUTE default_gateway=192.168.0.1
Sun Mar 16 23:05:35 2014 TUN/TAP device tap0 opened
Sun Mar 16 23:05:35 2014 TUN/TAP TX queue length set to 100
Sun Mar 16 23:05:35 2014 MANAGEMENT: >STATE:1395007535,ASSIGN_IP,,192.168.11.46,
Sun Mar 16 23:05:35 2014 /system/xbin/ifconfig tap0 192.168.11.46 netmask 255.255.255.0 mtu 1500 broadcast 192.168.11.255
Sun Mar 16 23:05:35 2014 /system/xbin/route add -net 127.0.0.1 netmask 255.255.255.255 gw 192.168.0.1
Sun Mar 16 23:05:35 2014 /system/xbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 192.168.11.1
Sun Mar 16 23:05:35 2014 /system/xbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 192.168.11.1
Sun Mar 16 23:05:35 2014 Initialization Sequence Completed
Sun Mar 16 23:05:35 2014 MANAGEMENT: >STATE:1395007535,CONNECTED,SUCCESS,192.168.11.46,127.0.0.1
Sun Mar 16 23:05:35 2014 MANAGEMENT: CMD 'bytecount 0'  
Sun Mar 16 23:05:35 2014 MANAGEMENT: CMD 'bytecount 3'  
Sun Mar 16 23:08:56 2014 [SERVER] Inactivity timeout (--ping-restart), restarting
Sun Mar 16 23:08:56 2014 TCP/UDP: Closing socket
Sun Mar 16 23:08:56 2014 SIGUSR1[soft,ping-restart] received, process restarting
Sun Mar 16 23:08:56 2014 MANAGEMENT: >STATE:1395007736,RECONNECTING,ping-restart,,
Sun Mar 16 23:08:56 2014 Restart pause, 5 second(s)
Sun Mar 16 23:08:56 2014 MANAGEMENT: CMD 'bytecount 0'  
Sun Mar 16 23:09:01 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables  
Sun Mar 16 23:09:01 2014 Re-using SSL/TLS context
Sun Mar 16 23:09:01 2014 LZO compression initialized
Sun Mar 16 23:09:01 2014 Control Channel MTU parms [ L:1592 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sun Mar 16 23:09:01 2014 MANAGEMENT: >STATE:1395007741,RESOLVE,,,
Sun Mar 16 23:09:01 2014 Data Channel MTU parms [ L:1592 D:1450 EF:60 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Mar 16 23:09:01 2014 Local Options hash (VER=V4): '44fbca6b'  
Sun Mar 16 23:09:01 2014 Expected Remote Options hash (VER=V4): '570d8093'  
Sun Mar 16 23:09:01 2014 Attempting to establish TCP connection with 127.0.0.1:8080 [nonblock]
Sun Mar 16 23:09:01 2014 MANAGEMENT: >STATE:1395007741,TCP_CONNECT,,,
Sun Mar 16 23:09:01 2014 TCP connection established with 127.0.0.1:8080
Sun Mar 16 23:09:01 2014 Socket Buffers: R=[1048576->131072] S=[524288->131072]
Sun Mar 16 23:09:01 2014 TCPv4_CLIENT link local: [undef]
Sun Mar 16 23:09:01 2014 TCPv4_CLIENT link remote: 127.0.0.1:8080
Sun Mar 16 23:09:01 2014 MANAGEMENT: >STATE:1395007741,WAIT,,,
Sun Mar 16 23:09:01 2014 MANAGEMENT: CMD 'bytecount 0'  
Sun Mar 16 23:09:01 2014 MANAGEMENT: CMD 'bytecount 0'  
Sun Mar 16 23:09:01 2014 MANAGEMENT: CMD 'bytecount 0'  
Sun Mar 16 23:09:02 2014 Connection reset, restarting [-1]
Sun Mar 16 23:09:02 2014 TCP/UDP: Closing socket
Sun Mar 16 23:09:02 2014 SIGUSR1[soft,connection-reset] received, process restarting

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

Content-ID: 232777

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

Ausgedruckt am: 13.11.2024 um 08:11 Uhr

7 Kommentare

Neuester Kommentar

Hi chr2002,

Liegt das Problem wirklich am localhost ?

Dem Client sollte hierdurch eigentlich sein Ziel unbekannt werden (remote localhost 8080).
Ausserdem hast Du in der OVPN-Server-conf. "client-to-client" stehen. Damit baust Du normalerweise einen Multiclienttunnel, der aber hier nicht benötigt wird.
Das mal auskommentieren oder Weglassen.
Poste mal bitte noch die Routing-Tabelle des Servers.
Gruß orcape

Stimmt, das client-to-client brauch ich nicht. War wohl von Anfang an drin und hat mich nicht gestört

Die Routung Tabelle sieht am Server recht übersichtlich aus.

Ziel Router Genmask Flags Metric Ref Use Iface
default ads.yahoo.com 0.0.0.0 UG 0 0 0 br0
192.168.11.0 * 255.255.255.0 U 0 0 0 br0

Ich habe den Fehler gefunden, es liegt am "push "redirect-gateway def1" " in der Server Config.
Anscheinend wird dann auch der ssl Tunnel ins VPN geleitet, was dann keinerlei kommunikation ermöglicht.

Ich habe das mal rausgenommen und kann jetzt problemlos über umts einen Openvpn Tunnel aufbauen und alles im LAN erreichen.

Jetzt ist es aber nicht mehr möglich, den Internet Traffic in den Tunnel zu leiten. Das wäre recht praktisch, wenn ich einen unsicheren Hotspot verwende.
Ich könnte jetzt mehrere Instanzen auf dem Openvpn Server starten mit einer Konfig in der das Default GW umgeleitet wird und mit einer Config wo es nicht umgeleitet wird. Irgendwie ist das auch nicht das Wahre. Ist es möglich, die Umleitung des default GWs nur in der Client Konfig festzulegen ?

Irgendwie ist das auch nicht das Wahre. Ist es möglich, die Umleitung des default GWs nur in der Client Konfig
festzulegen ?

Normalerweise wird das auf dem Server mit "push "redirect-gateway " erledigt.
Vielleicht hilft hier Iptables...

Gruß orcape

Genau das ist mein Problem, wenn ich den Server das Def GW umleiten lasse, dann leitet das auch meinen ssl Tunnel um

Auf der Clientseite wäre es sowas von einfach. Mann erstellt einfach zwei oder drei Konfig Files für OpenVpn.

Eines für stunnel ohne def GW, eines direkt ohne Stunnel mit Def GW und nochmal eines ohne Stunnel und ohne Def GW , wenn man bei Freunden ist und das Wlan sicher ist.