routing tabelle bei nutzung von openvpn

xsapling

Mitglied
Mitglied seit
30 Jan 2005
Beiträge
755
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich benutze OpenVPN und mir gelingt es auf meinem Android 2.2.1 die OpenVPN Verbindung erfolgreich zur FritzBox herzustellen. Aber es scheint, als würden nicht alle Daten über die Fritz!Box geschickt werden. Denn wenn ich einen IP-Check mache, dann erscheint nicht die Box der Fritz!Box, sondern die des lokalen Netzes.

Ich habe mal ein ip-route auf dem androiden gemacht:

Code:
# ip route
ip route
87.185.223.46 via 192.168.137.1 dev eth0
172.30.1.0/24 via 172.30.1.1 dev tap0
172.30.1.0/24 dev tap0  src 172.30.1.203
192.168.137.0/24 dev eth0  src 192.168.137.183
default via 192.168.137.1 dev eth0
default via 172.30.1.1 dev tap0
#
ifconfig

Code:
busybox ifconfig
eth0      Link encap:Ethernet  HWaddr 90:21:55:E0:05:86
          inet addr:192.168.137.183  Bcast:192.168.137.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3404 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2806 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2482357 (2.3 MiB)  TX bytes:656437 (641.0 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:800 errors:0 dropped:0 overruns:0 frame:0
          TX packets:800 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:50312 (49.1 KiB)  TX bytes:50312 (49.1 KiB)

tap0      Link encap:Ethernet  HWaddr 9A:E8:2E:5F:4B:B7
          inet addr:172.30.1.203  Bcast:172.30.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1784 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1828 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1515838 (1.4 MiB)  TX bytes:277970 (271.4 KiB)
Die config auf dem Androiden schaut so aus

Code:
#  OpenVPN 2.1 Config, Tue Mar 18 04:06:30 CET 2008
route delete
#iproute /data/data/misc/iproute-wrapper.sh

proto tcp-client
dev tap
#secret D:\\Programme\\OpenVPN\\sample-config\\key
remote domain.org 143
tls-client
ns-cert-type server

ca ca.crt
cert client01.crt
key client01.key

tls-auth key 1

script-security 2

nobind
#pull

#



route delete

#iproute /data/data/misc/iproute-wrapper.sh

dhcp-option DNS 172.30.1.1
dhcp-option DNS 172.30.1.1
route 172.30.1.0 255.255.255.0
route-gateway 172.30.1.1
redirect-gateway

#dhcp+redirect + route-gateway = internet ueber opvn-server

ifconfig 172.30.1.203 255.255.255.0
tun-mtu 1500
mssfix
verb 3
#daemon
cipher AES-256-CBC
#comp-lzo
float
keepalive 10 120
resolv-retry infinite
Soweit ich das mit meinem "Latein" annahm, sollte mit dieser config eigentlich alles so sein, dass der Verkehr ausschließlich über die OpenVPN-Verbindung laufen sollte. Das ist genau das was ich brauch. Denn ich habe hier eine App namens FRITZ!App Fon, die sich zwar zur Box verbindet, von der ich sogar Telefonate aufbauen kann, jedoch nichts höre. Sowie, wenn Telefonate reinkommen, dann werden diese nicht auf der App signalisiert. Ich kann SIP nur dann über OpenVPN benutzen, wenn ich eine andere Software (3CXPhone) benutzem, die jedoch ein paar Bug hat und nicht so gute, wenn auch "recht" gute Resultate liefert.

Gibt es irgendwie eine Möglichkeit zu erzwingen, sämtlichen Verkehr über die OpenVPN-Verbindung zu leiten?
 
Den "gesamten Verkehr durch den Tunnel" wird wohl nicht gehen, denn der Tunnel selbst braucht ja auch Verkehr und eine IP Verbindung. Hier hilft nur intelligentes Routing und zwar auf beiden Seiten des Tunnels. Es wäre hilfreich mal die Gesamtkonfiguration zu posten (Beide Boxen ifconfig + Routingtabellen)
 
ich würde jetzt erstmal fix versuchen, ob ich mehr erfolg habe, wenn ich meine openvpn-verbindung durch die cyanogen-eigene software verwalten lassen.

Jedoch komme ich da an einer Stelle nicht weiter. Und zwar, muss ich eine pkcs12 erstellen. Ein Beispiel auf der wiki-Seite (http://wiki.cyanogenmod.com/index.php?title=OpenVPN) ist folgendermaßen wiedergegeben:
Code:
openssl pkcs12 -export -in client.crt -inkey client.key -certfile ca.crt -out client.p12
Diese Zeile hat nur ein Problem, wo lass ich meinen statischen key aus der config "tls-auth key 1"?? Zumindest erhalte ich beim Versuch der Aufbau der Verbindung folgenden Fehlerlog

Code:
Thu Jan 13 17:35:23 2011 MULTI: multi_create_instance called
Thu Jan 13 17:35:23 2011 Re-using SSL/TLS context
Thu Jan 13 17:35:23 2011 Control Channel MTU parms [ L:1591 D:168 EF:68 EB:0 ET:0 EL:0 ]
Thu Jan 13 17:35:23 2011 Data Channel MTU parms [ L:1591 D:1450 EF:59 EB:4 ET:32 EL:0 ]
Thu Jan 13 17:35:23 2011 Local Options hash (VER=V4): '173d8fc4'
Thu Jan 13 17:35:23 2011 Expected Remote Options hash (VER=V4): 'b8d42479'
Thu Jan 13 17:35:23 2011 TCP connection established with [AF_INET]xxx.xxx.xxx.xxx:123:53974
Thu Jan 13 17:35:23 2011 TCPv4_SERVER link local: [undef]
Thu Jan 13 17:35:23 2011 TCPv4_SERVER link remote: [AF_INET]xxx.xxx.xxx.xxx:123:53974
Thu Jan 13 17:35:24 2011 xxx.xxx.xxx.xxx:123:53974 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:123:53974, sid=cdc351af 74cc3bba
Thu Jan 13 17:35:24 2011 xxx.xxx.xxx.xxx:123:53974 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]xxx.xxx.xxx.xxx:123:53974
Thu Jan 13 17:35:24 2011 xxx.xxx.xxx.xxx:123:53974 Fatal TLS error (check_tls_errors_co), restarting
Thu Jan 13 17:35:24 2011 xxx.xxx.xxx.xxx:123:53974 SIGUSR1[soft,tls-error] received, client-instance restarting
Thu Jan 13 17:35:24 2011 TCP/UDP: Closing socket

soweit ich das log verstehe, ist der key erfoderlich. oder? nur wie bekomm ich ihn dann in die pkcs12?
 
Die Nutzung von tls-auth hat mit dem anderen Key/Cert nix zu tun, das ist ein eigener Key (siehe OpenVPN: "Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key"). Entweder den Key draufbringen oder tls-auth ausschalten.

Jörg
 
so jetzt habe ich das tls mal deaktiviert. nun komm ich von dem cyanogen aus auf die fritzbox rein. aber wenn ich in dem client die option, den ganzen datenverkehr über die openvpn-verbindung leiten auswähle, geht gar nichts mehr. D. h. ich kann keine Seiten mehr aufrufen, noch sonst was erreichen.

Das hat der Android-Mod draus gemacht:
Code:
ip route
87.185.223.46 via 192.168.137.1 dev eth0
172.30.1.0/24 dev tap0  src 172.30.1.202
192.168.137.0/24 dev eth0  src 192.168.137.178
0.0.0.0/1 via 172.30.1.201 dev tap0
128.0.0.0/1 via 172.30.1.201 dev tap0
default via 192.168.137.1 dev eth0
Code:
busybox ifconfig
eth0      Link encap:Ethernet  HWaddr 90:21:55:E0:05:86
          inet addr:192.168.137.178  Bcast:192.168.137.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3246 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2958 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:983002 (959.9 KiB)  TX bytes:393818 (384.5 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:388 errors:0 dropped:0 overruns:0 frame:0
          TX packets:388 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:26768 (26.1 KiB)  TX bytes:26768 (26.1 KiB)

tap0      Link encap:Ethernet  HWaddr 86:FB:77:37:22:32
          inet addr:172.30.1.202  Bcast:172.30.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:1476 (1.4 KiB)
Wo liegt denn da der Haken?
 
Ich tippe mal blind auf den DNS, der nicht gefunden wird.
Mach mal den Gegentest: Ping (vorher) auf heise.de und rufe dann mit VPN im Browser die IP davon auf.
Ggf. dann auf der FB den DNS "VPN-IP der FB" bei den erweiterten Einstellungen als Option mit übergeben

Jörg
 
das hat es leider auch nicht gebracht, d.h. die IP kann auch nicht aufgerufen werden, während der Tunnel aufgebaut ist.
 
Wird da vielleicht ein Proxy genutzt, der nur vom Android aus erreichbar ist? Hast du da eine Shell drauf, wo du mal einen Trace auf die Adresse absetzen kannst?
 
ja, habe shell, busybox und su auf dem Androiden drauf. ein traceroute ergab folgendes:
Code:
traceroute heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 38 byte packets
 1  172.30.1.203 (172.30.1.203)  3001.709 ms !H  3009.796 ms !H  3009.888 ms !H
#
 
Zuletzt bearbeitet:
Ist 172.30.1.203 die IP der FB? Kanst du die IP der FB erreichen (und ihre GUI sehen)?
Warum nutzt du eigentlich "TAP" und nicht TUN?
 
172.30.1.203 ist die lokale ip des androiden, die er erhält, wenn er sich als client mit dem openvpn-server verbindet.
tap deshalb, weil ich wollte, dass die clients so erscheinen, als ob sie im heim-netzwerk sind. also einem physischem netzwerk, so nah wie möglich kommen.
 
Wie lautet denn die Routingtabelle und ifconfig jetzt? Eigentlich sagt die Meldung ja, dass er keine Route dafür hätte...
Kannst du die FB erreiche, über die "VPN-IP" ? über die "LAN-IP"?

Jörg
 
Code:
# ip route
ip route
87.185.161.193 via 173.30.1.222 dev eth0
172.30.1.0/24 dev tap0  src 172.30.1.202
173.30.1.0/24 dev eth0  src 173.30.1.25
0.0.0.0/1 via 172.30.1.201 dev tap0
128.0.0.0/1 via 172.30.1.201 dev tap0
default via 173.30.1.222 dev eth0
#

#

# busybox ifconfig
busybox ifconfig
eth0      Link encap:Ethernet  HWaddr 90:21:55:E0:05:86
          inet addr:173.30.1.25  Bcast:173.30.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34378 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33455 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:16912876 (16.1 MiB)  TX bytes:6315659 (6.0 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2485 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2485 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:165408 (161.5 KiB)  TX bytes:165408 (161.5 KiB)

tap0      Link encap:Ethernet  HWaddr 36:9F:94:38:1C:4D
          inet addr:172.30.1.202  Bcast:172.30.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:846 (846.0 B)

#
Die entfernte FB kann ich weder per LAN-Ip noch über VPN-IP erreichen ...
 
Oben hattest du die FB mal als 172.30.1.1 drin, jetzt ist es 172.30.1.201??
Aber das wichtigste: So kann das nicht gehen, wenn du im (W)LAN bist, durch das LAN eine VPN-Verbindung auf die Box aufbaust und dem VPN dann noch eine IP aus dem LAN gibst! Es geht einfach nicht, die VPN-Gegenstelle durch das VPN zu erreichen ;-)!

Wenn du unbedingt im Heimnetz testen willst, nutze ein anderes Netz als "Internetersatz" (z.B. 192.168.178.0/24, FB hat 192.168.178.1, Android 192.168.178.22 mit DG=FB-IP=192.168.178.1).

Dann kannst du mit Experimenten beginnen...

Jörg
 
naja die .201 ist die IP des gebrückten TAP-Interfaces der FritzBox ist, während die .1 die IP des Standardinterface der selben FritzBox ist.

Was heißt denn die DG-Abkürzung bei dir?

Ich bin ja nicht im selben Lan der Heimbox, sondern in einem anderen Wlan einer anderen Box in einem anderen Internetanbieter mit meinem Androiden, das intern mit 173 statt mit 172 (Heimnetz) beginnt. Oder meintest du was anderes?
 
DefaultGateway.
Aber wie gesagt: So wie es "ganz oben" war (IP 192.168.137.183) wäre es vermutlich möglich, aber das "Transfernetz" zwischen den VPN-Endpunkten muss sich vom VPN-Netz unterscheiden...

EDIT: Peinlich, 172 ist ungleich 173, hätte ich auch selbst drauf kommen können. Ich denk nochmal nach ...
 
Zuletzt bearbeitet:
na ist doch kein problem, hab die immerhin so gewählt, dass ich die auch manchmal durcheinanderbringe. die sachen die wir gerade durchgespielt haben, habe ich mit den integrierten openvpn-client der cyanogenmod gemacht, während ich jetzt wieder auf das tool "openvpn settings" zurückgreifen werde, weil das integrierte openvpn-ding momentan nicht weiterführt.

Das scheint nun zu klappen.

So sieht ein Auszug aus
Code:
# ip route
ip route
87.185.161.193 via 173.30.1.222 dev eth0
172.30.1.0/24 via 172.30.1.1 dev tap0
172.30.1.0/24 dev tap0  src 172.30.1.203
173.30.1.0/24 dev eth0  src 173.30.1.25
default via 172.30.1.1 dev tap0
# busybox ifconfig
busybox ifconfig
eth0      Link encap:Ethernet  HWaddr 90:21:55:E0:05:86
          inet addr:173.30.1.25  Bcast:173.30.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1304 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1253 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:340685 (332.7 KiB)  TX bytes:357071 (348.7 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:591 errors:0 dropped:0 overruns:0 frame:0
          TX packets:591 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:37778 (36.8 KiB)  TX bytes:37778 (36.8 KiB)

tap0      Link encap:Ethernet  HWaddr 4A:B6:05:CC:D2:E7
          inet addr:172.30.1.203  Bcast:172.30.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:90 errors:0 dropped:0 overruns:0 frame:0
          TX packets:291 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:13557 (13.2 KiB)  TX bytes:62452 (60.9 KiB)

#
die dazugehörige config so

Code:
#  OpenVPN 2.1 Config, Tue Mar 18 04:06:30 CET 2008
#route delete
#iproute /data/data/misc/iproute-wrapper.sh

proto tcp-client
dev tap
#secret D:\\Programme\\OpenVPN\\sample-config\\key
remote url.org 3132
tls-client
ns-cert-type server

ca ca.crt
cert client01.crt
key client01.key

#tls-auth key 1

script-security 2

nobind
#pull

#



route delete

#iproute /data/data/misc/iproute-wrapper.sh

dhcp-option DNS 172.30.1.1
dhcp-option DNS 172.30.1.1
route 172.30.1.0 255.255.255.0
route-gateway 172.30.1.1
redirect-gateway

#dhcp+redirect + route-gateway = internet ueber opvn-server

#ifconfig 172.30.1.203 172.30.1.201
ifconfig 172.30.1.203 255.255.255.0
tun-mtu 1500
mssfix
verb 3
#daemon
cipher AES-256-CBC
#comp-lzo
float
keepalive 10 120
resolv-retry infinite
Das Problem ist hier wieder, ich kann mit der FritzAppPhone zwar Gespräche aufbauen, aber nichts hören.
Was ich mich deshalb frage, ob ich noch irgendwie manuell routen anlegen kann, damit ich den fritz eigenen SIP-server auf der 172.30.1.1 mit der fritzappphone richtig, also auch mit ton, den ich jetzt nicht hören kann, verwenden kann. Kann man da irgendwas machen?
 
Hast Du mal gepingt? Kommen Antwortpakete? Wenn ja, liegt es nicht am routing. Vielleicht hast Du ja noch irgendwo eine Firewall Regel aktiv, die die Kommunikation verhindert?

Mit pingen meine ich einmal die Fritzbox und dann noch dein ip-phone, was du erreichen willst. Die box vermittelt ja nur das Gespräch. Die Kommunikation findet zwischen beiden Endgeräten statt. Also muss auch die freetz firewall die Kommunikation öffnen wenn die Gegenstelle außerhalb liegt und die ankommenden Pakete per NAT und route durch den Tunnel zu deinem Open VPN Client durchstellen. Es reicht also nicht nur eine Route zum LAN, sondern es muss eine route durch den Tunnel zum Rest der Welt her - außer zur dyndns Adresse der Box (sonst bricht dir der Tunnel zusammen).
 
Zuletzt bearbeitet:
Das Problem ist hier wieder, ich kann mit der FritzAppPhone zwar Gespräche aufbauen, aber nichts hören.
Das halte ich eher für eine Konfig-Problematik oder Anwendungs-Problem denn eine Routing-Geschichte. Wie Cando schon sagte: Wenn du darüber Daten hin- und herschicken kannst, ist das Routing o.k.. Geht es denn im WLAN der eigenen Box? Was wird da in "FritzAppPhone" eingetragen (IPs, Namen...)? Sind (oder müssen sein) auch im Android etho und tap0 gebridged? Ist die Brücke in der FB auch sicher gesetzt?
Zumindest eine FB selbst war schon immer recht pingelig damit, auf welchem Interface SIP-Pakete denn nun kommen oder beantwortet werden...

Jörg
 
@ cando. Ein traceroute oder ein ping laufen sauber und ohne Probleme durch.

@MaxMuster
Das AVM eigene SIP funktioniert im heimischen Netz sogar über LAN. Dort ist die Box, auf der SIP-Server läuft über LAN-Kabel mit einer weiteren Fritz!Box verbunden, auf der der WLAN abgewickelt wird. Und auf dieser WLAN-Box ist auch der Androide angemeldet, wenn über die SIP-Software erfolgreich telefoniert werden kann.

In der FritzApp ist die IP der Box eingetragen.

Wie kann ich herausfinden, ob gebridged ist oder nicht?
Wie kann ich auf der Box herausfinden, ob die Brücke in der Box sicher gesetzt ist? Soweit ich mich erinnere, habe ich das damals in der ar7.cfg gemacht.
Könnte man nicht notfalls, ein wenig an den Interface herumspielen, um die FB in diesem Zusammenhang zum erfolgreichen Telefonieren zu bewegen?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.