Suche richtig gute openVPN Howto auf deutsch

[dirk11]

Hi Leute,

ich bin auf der Suche nach wirklich guten Tutorials/HowTos zu openVPN auf deutsch.

Bisher hatte ich eine openVPN-Verbindung von einem Client (Laptop) zu meinem Server, zusammengebastelt nach hier und [url=http://wiki.openvpn.eu/index.php/OVPN-Linux]. Das hat für den einen Client auch gut funktioniert. Jetzt will ich einen zweiten Client einbinden, in dem Fall ein Android-Tablet, und irgendwie klappt das gar nicht.
Eigentlich sollte das doch mit nur einer server.conf auf dem openvpn-Server möglich sein, oder etwa nicht? Jetzt habe ich aber an einigen Stellen im Netz gelesen, ich bräuchte für jeden Client eine eigene conf-Datei, und jeder Client bräuchte auch seinen eigenen Port (also 1194, 1195, ...). Zumindest letzteres kann ich eigentlich kaum glauben, das würde ja bedeuten, dass man in Firmennetzen zig Ports nur für openvpn bereithalten müsste.

Also, falls jemand eine aktuelle(!) (meine oben verlinkten Anleitungen scheinen nur noch mäßig aktuell zu sein) gute Anleitung hat: immer her damit!

Ach ja, die Ubuntu-Anleitung aus deren wiki kenne ich, hilft mir nicht weiter.

[syssi]

Deine Konfiguration hat den Weg eines statischen Key gewaehlt. Ich uebersetze mal die ersten paar Zeilen der englischen OpenVPN-Doku:

Die Konfiguration mit einem statischen Schluessel bietet eine einfache Einrichtung und ist ideal fuer eine Punkt-zu-Punkt Verbindung oder zum testen.

Die Vorteile eines statischen Schluessels

• Einfach eingerichtet
• Man muss keine X509 Public-Key-Infrastruktur warten

Nachteile

• Es skaliert nicht: Nur ein Client pro Server moeglich.
• Mangel an Folgenlosigkeit -- knackt/findet jemand den Schluessel, dann kann er auch alte Konversationen dekodieren.
• Der geheime Schluessel muss in Plaintext vorliegen auf jedem Teilnehmer.
• Die geheime Schluessel muss zuvor irgendwie ausgetauscht werden.

http://openvpn.net/index.php/open-sourc ... howto.html

Du bist bereits ueber Punkt eins der Nachteile gestolpert. Wenn du einen Server mit vielen Clients betreiben willst, dann bietet sich an TLS zu verwenden. Die Einrichtung ist etwas komplizierter dafuer aber sicherer. Die ganzen Nachteile loesen sich dabei in Luft auf.

Gruss syssi

[TRex]

Oder du steigst auf tinc um, solange es noch nicht zu spät ist Dafür gibts auch nen Android tinc-client (tinc nutzt auch nur tun oder tap vom Linuxkernel, also nicht mehr Magie als openvpn).

[dirk11]

Du bist bereits ueber Punkt eins der Nachteile gestolpert. Wenn du einen Server mit vielen Clients betreiben willst, dann bietet sich an TLS zu verwenden. Die Einrichtung ist etwas komplizierter dafuer aber sicherer. Die ganzen Nachteile loesen sich dabei in Luft auf.

Danke dir, nach einer nachmittäglichen Session bin ich da dann auch hintergestiegen.
Halten wir at first einmal fest: openvpn mit static key funktioniert bei mir zu meinem ersten Client. Da ich einen weiteren hinzufügen möchte, habe ich mir jetzt auch überlegt, auf tls bzw. separate Keys für jeden Client umzusteigen. Problem - und das hat mich bisher schon Stunden gekostet - das funktioniert nicht
Das Erstellen der Keys mittels openssl nach oben von mir verlinkten Howtos klappt im Grunde wunderbar (bei den Befehlen sind sie ja nahezu identisch) und deckt sich auch mit anderen entsprechenden Anleitungen, die ich im Netz gefunden habe. Aber aus einem für mich nicht nachvollziehbaren Grund funktioniert die Überprüfung clientseitig nicht:

Code: Alles auswählen

# openvpn --config /etc/openvpn/eee-vpn.conf
Wed Oct 30 23:32:51 2013 OpenVPN 2.1.3 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jun  6 2013
Wed Oct 30 23:32:51 2013 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Wed Oct 30 23:32:51 2013 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Oct 30 23:32:51 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Oct 30 23:32:51 2013 /usr/bin/openssl-vulnkey -q -b 2048 -m <modulus omitted>
Wed Oct 30 23:32:51 2013 LZO compression initialized
Wed Oct 30 23:32:51 2013 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Oct 30 23:32:51 2013 Socket Buffers: R=[87380->131072] S=[16384->131072]
Wed Oct 30 23:32:51 2013 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Oct 30 23:32:51 2013 Local Options hash (VER=V4): '66600a11'
Wed Oct 30 23:32:51 2013 Expected Remote Options hash (VER=V4): 'a0001gf7'
Wed Oct 30 23:32:51 2013 Attempting to establish TCP connection with [AF_INET]127.0.0.1:44227 [nonblock]
Wed Oct 30 23:32:51 2013 TCP connection established with [AF_INET]127.0.0.1:44227
Wed Oct 30 23:32:51 2013 TCPv4_CLIENT link local: [undef]
Wed Oct 30 23:32:51 2013 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:44227
Wed Oct 30 23:32:51 2013 TLS: Initial packet from [AF_INET]127.0.0.1:44227, sid=sd0dfgac 6a0fgjh5
Wed Oct 30 23:32:51 2013 VERIFY ERROR: depth=0, error=self signed certificate: /C=DE/ST=BW/L=D/O=net/OU=server/CN=net/emailAddress=xxx@xxx.de
Wed Oct 30 23:32:51 2013 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Oct 30 23:32:51 2013 TLS Error: TLS object -> incoming plaintext read error
Wed Oct 30 23:32:51 2013 TLS Error: TLS handshake failed
Wed Oct 30 23:32:51 2013 Fatal TLS error (check_tls_errors_co), restarting
Wed Oct 30 23:32:51 2013 TCP/UDP: Closing socket
Wed Oct 30 23:32:51 2013 SIGUSR1[soft,tls-error] received, process restarting
Wed Oct 30 23:32:51 2013 Restart pause, 5 second(s)
^CWed Oct 30 23:32:55 2013 SIGINT[hard,init_instance] received, process exiting

Die beiden "WARNING" am Anfang kann man ignorieren, das hat was mit meinen settings zu tun; a) weil ich openvpn funktionieren über ssh tunnele, b) (ns-cert-type server), welches ich absichtlich herausgenommen habe.

Mein Problem ist der TLS Error, für den ich im Web bisher weder auf deutsch noch auf englisch eine Lösung gefunden habe. Scheinbar mag openvpn keine per openssl erstellte self-signed certificates, nur habe ich keinen blassen Schimmer, wie ich das umgehen kann.
Man kann die certs wohl auch mit easyrsa erstellen, aber da scheitere ich schon am sourcen von vars, das funktioniert um's Verrecken nicht.

Und so lange ich keine validen/funktionierenden certificates habe, kann ich das knicken, denn openvpn auf Android kann (noch) kein static key. Davon ab will ich aus o.g. Gründen ja sowieso auf certs wechseln.

[syssi]

Loesch nochmal alle Zertifikate und nutze das von OpenVPN mitgelieferte "easy-rsa"-Skript zur Erstellung aller notwendiger Schluessel. Es muesste unter /etc/openvpn/doc-old/examples/easy-rsa/2.0 liegen.

Gruss syssi

[dirk11]

Ja, danke. Ich musste die noch nichtmal löschen, nur die easyrsa-Certs woanders ablegen. Warum ich als letztes im Debian-Wiki nachgeschaut habe, weiss ich auch nicht, aber danach funktioniert es. Was auch immer easyrsa anders macht...

Jetzt habe ich aber noch mindestens drei momentan ungelöste Probleme:

a) sollen die beiden Clients feste IP bekommen, nämlich einmal .16 und einmal .37. Das funktioniert nicht. Mit .16 (Laptop) scheint es kein Problem zu geben, aber der Server ändert seine ipp.txt immer selbständig ab, dort steht dann .36 und nicht .37 für das Android-Tablet drin, und wenn ich das so probiere, quittiert der Android-Client mit einer Fehlermeldung (sinngemäß no /30 topology oder so ähnlich). Konfig server sieht momentan wie folgt aus:

Code: Alles auswählen

port 1194
proto tcp
dev tun # notwendig für openvpn via ssh
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.1.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
#route 10.1.0.0 255.255.255.252
route 10.1.0.0 255.255.255.192
keepalive 10 120
comp-lzo
max-clients 10
persist-key
persist-tun
verb 3

Der Androide bekommt eine vpn.ovpn zugeschickt, die er dann importieren kann. Sieht wie folgt aus:

Code: Alles auswählen

client
dev tun
remote name.org
ifconfig 10.1.0.37 10.1.0.1
comp-lzo
persist-tun
persist-key
verb 3
script-security 2
proto tcp
<ca>...</ca><cert>...</cert><key>...</key>

b) muss auf dem Android-Client automatisch eine Route gesetzt werden. Auf dem Laptop geschieht das mit Hilfe der ausführbaren Datei home.up mit dem simplen Inhalt route add -net 192.168.1.0 netmask 255.255.255.0 gw $5
das funktioniert so auf dem Android natürlich nicht. Ich habe aber auch nichts gefunden, wie ich das auf dem Androiden automatisch hinbekomme. Ich hatte es heute Nacht um 04h einmal manuell im Terminal geschafft (ist gerootet) mit route add -net... na ja jedenfalls so irgendwie, aber danach hat sich dann mein drittes Problem aufgezeigt:

c) Die TV-Headend-App auf dem Androiden behauptet, der Zugriff würde verweigert und kurz darauf meint sie auch noch "connection timeout". Das ist mir vollkommen unverständlich, denn nach manueller Eingabe der korrekten Route kann ich im Browser problemlos auf die Web-Oberfläche von TV-Headend zugreifen (http://192.168.1.1:9981).

Eine Idee, wie ich da Fehlersuche betreiben kann?

[syssi]

Zu a)

Das ipp.txt ist vergleichbar mit einer Datei voller DHCP-Leases. Sie sollte nicht editiert werden. Stattdessen fuegst du ein weitere Direktive hinzu:

Code: Alles auswählen

client-config-dir /etc/openvpn/ccd

Dieses Verzeichnis legst du ein. Hinein kannst du nun pro Client (Zertifikatname) eine Datei legen:

Code: Alles auswählen

echo "ifconfig-push 192.168.178.10 255.255.255.0" > /etc/openvpn/ccd/client1.example.com

Wichtig ist, dass die Datei genauso heisst, wie die FQDN des Zertifikats, mit welchem sich der Client anmeldet.

Zu b) In der Konfigurationsdatei fuer den Android-Client kannst du auch das Pushen einer Route aussteuern.

Zu c) Du koenntest dir mal im lokalen Netzwerk (ohne VPN) den Verkehr zwischen TV-Client und TV-Server ansehen. Moeglicherweise sieht man dabei problematische Dinge: UDP-Broadcasts, Multicasts oder andere schwer zu routende Phaenomene.

[dirk11]

Code: Alles auswählen

echo "ifconfig-push 192.168.178.10 255.255.255.0" > /etc/openvpn/ccd/client1.example.com

Wichtig ist, dass die Datei genauso heisst, wie die FQDN des Zertifikats, mit welchem sich der Client anmeldet.

Funktioniert nur beim Xoom nicht so richtig. Wie ist denn da überhaupt die korrekte Syntax? Ich dachte, die lautet
ifconfig-push IP_des_Client_(xoom) IP_des_Server

BTW: wie kann ich das FQDN später noch auslesen, weil ich mir nicht sicher bin, ob ich da nicht Fehler gemacht habe?

Zu b) In der Konfigurationsdatei fuer den Android-Client kannst du auch das Pushen einer Route aussteuern.

Wie muss dann da die Syntax sein?

Zu c) Du koenntest dir mal im lokalen Netzwerk (ohne VPN) den Verkehr zwischen TV-Client und TV-Server ansehen. Moeglicherweise sieht man dabei problematische Dinge: UDP-Broadcasts, Multicasts oder andere schwer zu routende Phaenomene.

Hmm, ok.

[syssi]

Code: Alles auswählen

echo "ifconfig-push 192.168.178.10 255.255.255.0" > /etc/openvpn/ccd/client1.example.com

Wichtig ist, dass die Datei genauso heisst, wie die FQDN des Zertifikats, mit welchem sich der Client anmeldet.

Funktioniert nur beim Xoom nicht so richtig. Wie ist denn da überhaupt die korrekte Syntax? Ich dachte, die lautet
ifconfig-push IP_des_Client_(xoom) IP_des_Server

Der Schnippsel war so aufbereitet, dass du ihn in eine Shell pasten kannst und er eine Datei mit dem korrekten Inhalt erzeugt. Der Inhalt der Datei pro Client muss lauten:

Code: Alles auswählen

ifconfig-push 10.1.0.16 255.255.255.0

BTW: wie kann ich das FQDN später noch auslesen, weil ich mir nicht sicher bin, ob ich da nicht Fehler gemacht habe?

Code: Alles auswählen

openssl x509 -in client1.crt -text -noout
# dich interessiert, was hinter CN= steht fuer den Dateinamen:
openssl x509 -in client1.crt -text -noout | grep CN=

Zu b) In der Konfigurationsdatei fuer den Android-Client kannst du auch das Pushen einer Route aussteuern.

Wie muss dann da die Syntax sein?

Das sind die Befehle, welche in den CCD-Dateien erlaubt sind:

Code: Alles auswählen

push
push-reset
iroute
ifconfig-push
config

Du wirst also etwas in Richtung:

Code: Alles auswählen

push "route 192.168.1.0 255.255.0.0"

hinein schreiben zusaetzlich zum ifconfig-push.

[syssi]

Ein cooles FAQ (leider auf Englisch), welches fast alles enthaelt, was man so braucht: https://workaround.org/openvpn-faq

[dirk11]

Der Schnippsel war so aufbereitet, dass du ihn in eine Shell pasten kannst und er eine Datei mit dem korrekten Inhalt erzeugt. Der Inhalt der Datei pro Client muss lauten:

Also definitiv als 2. 255.255.255.0 und nicht IP_des_Server.

openssl x509 -in client1.crt -text -noout | grep CN=

Hmm. Da kommen drei bei raus, erste Zeile ist Issuer:, zweite Zeile ist Subject: und dritte Zeile ist DirName:
Die CN in Issuer und DirName ist gleich (nämlich die vom Ziel-Server), die CN unter Subject ist die vom Client. Das sollte doch so korrekt sein, oder? Jedenfalls funktioniert es.

Du wirst also etwas in Richtung:
push "route 192.168.1.0 255.255.0.0"

Danke, ich werde es testen.

[syssi]

Ups, bei der Route koenntest du noch das Subnet anpassen: 255.255.255.0.

[dirk11]

Hmm. Es ist leider immer noch unklar. Du schreibst ja, in die client-Datei gehört
ifconfig-push 10.1.0.16 255.255.255.0
An diversen Stellen finde ich aber, dass der letzte Parameter die IP des Servers ist. Was ist denn nun richtig?

Und wie ich dem Android-Tablet die korrekte route beibringe, ist mir leider auch noch nicht klar. Wäre eine Zeile wie folgt:
iroute 192.168.7.0 255.255.255.0 gw 10.1.0.1
funktionabel? Ich brauche ja keine "normale" Route, sondern eine gw-Route für das Subnetz, in dem mein Server zu Hause beheimatet ist.

Und leider sind meine paar anderen Fragen auch noch unbeantwortet...

[dirk11]

Definitiv, schreibe ich für das Android-Tablet in /etc/openvpn/ccd/xoom folgendes:
ifconfig-push 10.1.0.37 255.255.255.0
So bekomme ich auf dem Android die Fehlermeldung
0 [route] [10.1.0.1]
1[topology] [net30]
2 [ping] [10]
3 [ping-restart] [120]
4 [ifconfig] [10.1.0.37] [255.255.255.0]
TUN Error: tun_builder_error: ifconfig addresses are not in the same /30 subnet (topology net30)
EVENT: TUN_SETUP_FAILED info="tun_builder_error: ifconfig addresses are not in the same /30 subnet (topology net30)"

Dasselbe Ergebnis bekomme ich, wenn in der ccd-Datei nur
ifconfig-push 10.1.0.37 10.1.0.1
drinsteht. Einen connect erreiche ich nur, wenn die Datei nicht existiert, dann bekommt das Android-Tablet aber irgendeine Pool-IP (meist die .38 am Ende), was ich aber aus bestimmten Gründen vermeiden will.

[dirk11]

Und noch etwas: zumindest scheint ein
push "route 192.168.1.0 255.255.255.0"
in der /etc/openvpn/ccd/xoom eine passende Route zu erstellen. Jedenfalls kann ich damit jetzt nach erfolgtem Verbindungsaufbau den Rechner 192.168.1.1, auf welchem der Tunnel "rauskommt", auch unter dieser IP anpingen. Immerhin schonmal _ein_ Erfolg! Was leider immer noch nicht klappt ist die TVHeadend-App durch den Tunnel. Starte ich sie, bekomme ich erst die Meldung "Zugriff verweigert" und kurz darauf "Connection timeout". Ein Aufruf der Weboberfläche von TVheadend in einem Browser über die originale IP 192.168.1.1:9981 funktioniert aber.

[dirk11]

Und noch ein Nachtrag von mir:

Ich komme mit dem Android-Tablet auch nicht auf meine Samba-Freigabe vom Server (auf dem das andere Ende des openvpn-Tunnel läuft). Und zwar behauptet der TotalCommander im Tablet: "Keine Internetverbindung! Bitte schalten sie entweder WLAN ein oder deaktivieren sie den Flugmodus! WLAN jetzt einschalten Ja Nein?"
Irreführend, weil die VPN-Verbindung steht.

[syssi]

Routest du in deinem Heimnetz auch das VPN-Subnet (10.1.0.x) ordentlich? "iroute" nutzt man um entfernte Subnetze (hinter einem VPN-Client) vom Server aus erreichbar zu machen. Ich bleibe deshalb bei meinem Empfehlungen. "ifconfig push" mit einer Subnetzmaske als letzter Parameter und "push route", wie bereits gesagt. Zum letzten Punkt kann ich auch nur wiederholen, dass du einmal per Wireshark den Traffic ansehen solltest.

[dirk11]

Routest du in deinem Heimnetz auch das VPN-Subnet (10.1.0.x) ordentlich?

Was genau meinst Du damit? Wenn ich die VPN-Verbindung auf meinem Netbook starte (also die, die vorher schon funktionierte), dann funktioniert alles, was auf dem Server an Diensten läuft. nfs, smb beispielsweise. Irgendwas stimmt da meiner Meinung nach auf dem Android-Tablet nicht, sprich dort wird etwas nicht korrekt gesetzt. Auf dem Netbook wird nach Aufruf der openvpn-Verbindung einfach noch die folgende Route gesetzt und alles geht:

route add -net 192.168.7.0 netmask 255.255.255.0 gw $5

Jedenfalls konnte ich noch keine Einschränkungen bemerken, ausser der, dass es gefühlt ewig dauert, wenn der nfs-mount vorher von einer LAN-Verbindung schon bestand, bis das Netbook als nfs-Client bemerkt, dass sich was geändert hat. Und so lange hängt alles, was mit nfs zu tun hat, z.B. auch ein laufender mc.

"iroute" nutzt man um entfernte Subnetze (hinter einem VPN-Client) vom Server aus erreichbar zu machen. Ich bleibe deshalb bei meinem Empfehlungen. "ifconfig push" mit einer Subnetzmaske als letzter Parameter und "push route", wie bereits gesagt. Zum letzten Punkt kann ich auch nur wiederholen, dass du einmal per Wireshark den Traffic ansehen solltest.

Zu meinem Server habe ich aber nur ssh-Zugang, eine grafische Oberfläche hat der nicht. Und so lange ich noch nicht hundertprozentig verstanden habe, welche Einstellungen wo hingehören, halte ich das für nutzloses Herumstochern meinerseits.

Ich würde - um in die letzten Wirrungen Klarheit zu bringen - jetzt nochmal meine derzeitigen Konfigs posten, vielleicht kannst du ja netterweise mal direkt darauf eingehen und die deiner Meinung nach notwendigen Korrekturen direkt benennen.

/etc/openvpn/server-vpn.conf:

Code: Alles auswählen

port 1194
proto tcp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.1.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 10.1.0.0 255.255.255.192
keepalive 10 120
comp-lzo
max-clients 10
persist-key
persist-tun
status openvpn-status.log
verb 3
script-security 2

/etc/openvpn/ipp.txt:

Code: Alles auswählen

netbook,10.1.0.16
tablet,10.1.0.37

Die Tablet-IP wird merkwürdigerweise immer vom openvpn in .36 geändert hier abgespeichert.

/etc/openvpn/ccd/netbook:

Code: Alles auswählen

ifconfig-push 10.1.0.16 10.1.0.1

/etc/openvpn/ccd/tablet:

Code: Alles auswählen

push "route 192.168.1.0 255.255.255.0"

Jetzt noch die Config-Datei vom Netbook:
/etc/openvpn/netbook-vpn.conf

Code: Alles auswählen

client
dev tun
proto tcp
remote 127.0.0.1 4422
resolv-retry infinite
persist-key
persist-tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/netbook.crt
key /etc/openvpn/easy-rsa/keys/netbook.key
ifconfig 10.1.0.16 10.1.0.1
up ./home.up
comp-lzo
verb 3
script-security 2

Der Parameter dh scheint hier nicht notwendig zu sein, jedenfalls wird sein Fehlen nicht bemängelt.

/etc/openvpn/home.up

Code: Alles auswählen

route add -net 192.168.1.0 netmask 255.255.255.0 gw $5

Und zu guter letzt noch die Konfig, die dem Tablet zugeht:

Code: Alles auswählen

client
dev tun
proto tcp
remote name.org
ifconfig 10.1.0.37 10.1.0.1
comp-lzo
persist-tun
persist-key
verb 3
script-security 2
# Plus natürlich die Keys, sonst würde ja gar nichts funktionieren.

[syssi]

Als naechstes koenntest du mit deinem Tablet die VPN-Verbindung aufbauen (moeglichst nicht ueber das Heimnetz, in welches du auch am Ende zurueck willst, sondern via UMTS oder einen anderen Internetanschluss) und die Konfiguration pruefen:

Code: Alles auswählen

$ ip route
$ ip addr

[dirk11]

Das via UMTS mache ich immer, das macht das ganze auch eher umständlich.

Code: Alles auswählen

# ip route
default via 10.64.64.64 dev ppp0
10.1.0.1 dev tun0 scope link
10.1.0.36/30 dev tun0 proto kernel  scope  link  src 10.1.0.38
10.64.64.64 dev ppp0  scope link
10.64.64.64 dev ppp0 proto kernel  scope link src 10.156.111.130
192.168.1.0/24 dev tun0 scope link

Wie man sieht: aus irgendeinem Grund hat das Tablet nicht die gewünschte IP, das andere Tunnelende (mein Server) ist aber auch nicht die .1, sondern die .38, wenn ich das richtig verstehe.

Code: Alles auswählen

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 scope host lo
     inet6  ::1/128 scope host
        valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu1500 qdisc noop state DOWN
     link/ether 0a:71:29:33:44:55 brd ff:ff:ff:ff:ff:ff
3: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 32
     link/ether f2:f0:e7:33:44:55 brd ff:ff:ff:ff:ff:ff
4: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 32
     link/ether 8a:fe:7d:33:44:55 brd ff:ff:ff:ff:ff:ff
5: sit0: <NOARP> mtu 1452 qdisc noop state DOWN
     link/sit 0.0.0.0 brd 0.0.0.0
6: ip6tln0:  <NOARP> mtu 1452 qdisc noop state DOWN
     link/tunnel6 :: brd ::
7: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
     link/ether 98:4b:4a:33:44:55 brd ff:ff:ff:ff:ff:ff
19: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
     link/ppp
    inet 10.156.111.130 peer 10.64.64.64/32 scope global ppp0
20: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/none
    inet 10.1.0.38/30 scope global tun0

Boah, alles abtippen...

Jetzt noch

Code: Alles auswählen

# ip route
default via 10.64.64.64 dev ppp0
10.1.0.1 dev tun0 scope link
10.1.0.36/30 dev tun0 proto kernel scope link src 10.1.0.38
10.64.64.64 dev ppp0 scope link
10.64.64.64 dev ppp0 proto kernel scope link src 10.156.111.130
192.168.1.0/24 dev tun0 scope link

Mir scheint, bei der route fehlt noch was...

Habs übrigens extra auf dem Netbook ausprobiert mit vlc: der Stream klappt dort via openvpn, es hakt am Androiden.

[syssi]

Wo hast du definiert, dass der VPN-Server die 10.1.0.38 sein soll? Das widerspricht deiner Konfiguration. Die Route, ueber welche wir die ganze Zeit sprechen ist sauber gesetzt:

Code: Alles auswählen

192.168.1.0/24 dev tun0 scope link

Dort steht: Das Netz 192.168.1.x wird ueber tun0 geroutet. Sauber!

Vielmehr stimmt mit deinen ganzen Adressbereichen und Netmasken etwas nicht. Wie gross soll das 10er Netz sein? Wie lautet die Server-IP?

[dirk11]

Wo hast du definiert, dass der VPN-Server die 10.1.0.38 sein soll? Das widerspricht deiner Konfiguration.

Das ist ja genau der Knackpunkt. Meine Configs sind genau so, wie ich sie weiter oben zuletzt gepostet habe. Ich habe nirgendwo definiert, dass mein Server 10.1.0.38 haben soll. Ausgabe vom entsprechenden ifconfig-Bereich auf meinem Server bei keiner aktiven vpn-Verbindung:

Code: Alles auswählen

tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet Adresse:10.1.0.1  P-z-P:10.1.0.2  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metrik:1
          RX packets:4256 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8165 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100 
          RX bytes:277642 (271.1 KiB)  TX bytes:10966808 (10.4 MiB)

Die Route, ueber welche wir die ganze Zeit sprechen ist sauber gesetzt:

Code: Alles auswählen

192.168.1.0/24 dev tun0 scope link

Dort steht: Das Netz 192.168.1.x wird ueber tun0 geroutet. Sauber!

Ich dachte, da müsse wie am Netbook mit dem $5 noch irgendwie das gw hinzugefügt werden.

Vielmehr stimmt mit deinen ganzen Adressbereichen und Netmasken etwas nicht. Wie gross soll das 10er Netz sein? Wie lautet die Server-IP?

Die Server-IP lautet, wie oben in der config angegeben, 10.1.0.1, das gesamte Netz habe ich eigentlich auf /26 bzw. 255.255.255.192 gesetzt, also 60 IP-Adressen. Das sollte locker ausreichen. Aber es wird ja irgendwie nicht akzeptiert, siehe auch die merkwürdige Fehlermeldung vom Tablet mit dem /30.

Nochmal: die aktuelle Config steht einige postings weiter oben von heute Mittag, etwas anderes gibt es nicht. Es sei denn, dort fehlt eine config-Datei, welche ich übersehen habe.

[syssi]

Ping mal vom Tablet aus den VPN-Server: "ping 10.1.0.1". Funktionert? Dann kannst du dir schonmal sicher sein, dass Daten zwischen VPN-Server und dir fliessen. Dann pingst du einmal die 192er-IP des Servers. Wie lautet sie? Das sollte funktionieren. Wenn nicht, dann solltest du dem Server beibringen, dass er Pakete fuer das 10er Netz ueber tun0 zu routen hat. Moechtest du nun noch weitere Geraete im 192er-Netz erreichen koennen, dann muessen diese Geraete eine Route zum tun0 deines Servers kennen. Ich gehe davon aus, dass dein Server nicht auch das Default-Gateway der anderen Geraete im Netzwerk ist.

Andere Geraete im Netzwerk schicken alle Packete, welche nicht zu ihrem Adressbereich (192.168.1.0/24) passen ans Default-Gateway. Vermutlich an deinem Server und dem VPN-Gateway vorbei. Entweder hinterlegst du auf dem Default-GW eine Route fuer das 10er Netz, welches auf die 192er IP deines Servers zeigt oder du musst auf jedem Client im Netz eine statische Route anlegen.

Nun pingen wir munter weiter. Kannst du von 192er Clients den 10er Endpunkt (10.1.0.38) erreichen? Die 38 war in deinem letzten Posting dein Tablet. Ich glaube du hast die Tabelle nicht ganz richtig interpretiert.

[syssi]

Wenn du das gesamte 10er Netz von deinem Tablet aus erreichen moechtest, dann solltest du noch eine weitere Route anlegen, welche das 26er-Netz ueber den VPN-Server routet. In deinem Listing ist nur zu erkennen, dass eine unmittelbare Route zum Server (10.1.0.1) gesetzt ist. Das genuegt grundsaetzlich auch, wenn du nicht mit weiteren VPN-Clients sprechen willst.

[syssi]

Ergaenz mal in deiner Server-Konfiguration folgende Zeile:

Code: Alles auswählen

push "route 10.1.0.0 255.255.255.192"

Damit stellst du sicher, dass nicht nur lokal eine Route fuers 10er Netz angelegt wird, sondern auch auf dem Client. Dann koenntest du auch gleich

Code: Alles auswählen

push "route 192.168.1.0 255.255.255.0"

in der Server-Konfiguration aufnehmen und aus deinen ccd-Files streichen. Schliesslich soll das fuer alle Clients gelten. Nach einem Server-Restart und erneuter Einwahl solltest du dann eine solche Routing-Tabelle auf deinem Client vorfinden:

Code: Alles auswählen

# ip route
default via 10.64.64.64 dev ppp0
10.1.0.1 dev tun0 scope link
10.1.0.36/30 dev tun0 proto kernel scope link src 10.1.0.38
10.64.64.64 dev ppp0 scope link
10.64.64.64 dev ppp0 proto kernel scope link src 10.156.111.130
192.168.1.0/24 dev tun0 scope link
10.1.0.0/26 dev tun0 scope link

Nun weiss das Tablet wohin mit Paketen fuer das 192er und 10er Netz. Naemlich alls richtung VPN-Server. Als naechstes solltest du noch die Routing-Tabelle des Servers pruefen und munter durch die Gegend pingen, um die Strecken zu testen.