OpenVPN Routing will nicht funktionieren

[Tosog]

Hallo!

Ich hab folgendes Setup:
Server mit subnet 192.168.64.0/24 und vpn ip 10.8.0.1 = 192.168.64.1
Client mit subnet 192.168.1.0/24 und vpn ip 10.8.0.6 = 192.168.1.1

Ziel ist es, dass ich von einem Server ins jeweils andere subnet pingen kann, also von 10.8.0.1 auf 192.168.1.* und von 10.8.0.6 auf 192.168.64.*

Ich hatte das früher schon so funktionierend am laufen, ich habe jetzt aber den Server neu aufgesetzt und bringe das routing nicht mehr zusammen. Am client habe ich (außer den neuen keys) nichts verändert.

Firewalls sind beide deaktiviert und ip_forwarding ist überall auf 1 gesetzt.

Ich kann vom VPN Client (10.8.0.6) zwar auf 192.168.64.1 pingen, einen anderen Rechner dahinter leider nicht. Umgekehrt vom Server auf 192.168.1.1 aber nicht.

Meine Server config:
port 1194
proto tcp
dev tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key # This file should be kept secret
dh keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.64.0 255.255.255.0"
client-config-dir ccd
route 192.168.1.0 255.255.255.0
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

und die dazugehörige ccd/epia:
iroute 192.168.1.0 255.255.255.0

und die client-conf:
client
dev tun
proto tcp
remote naik 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca keys/ca.crt
cert keys/epia.crt
key keys/epia.key
ns-cert-type server
comp-lzo
verb 3

Was mir dabei etwas komisch vorkommt ist die Ausgabe von ifconfig.
vom server (inkl. route):

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:252 (252.0 B) TX bytes:3184 (3.1 KiB)

naik:/etc/openvpn# route | grep tun0
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0



und vom client:
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.8.0.6 P-z-P:10.8.0.5 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metrik:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:100
RX bytes:252 (252.0 B) TX bytes:252 (252.0 B)

epia:/etc/openvpn# route | grep tun0
10.8.0.5 * 255.255.255.255 UH 0 0 0 tun0
192.168.64.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0


Ich wäre euch wirklich sehr dankbar, wenn mir jemand helfen könnte. Ich schlag mich schon seit dem Wochenende rum und komm da einfach nicht weiter.

lg, Christoph

[honkstar]

Deine Routen sind anscheinend nicht ganz vollständig, d.h. die Clients in 192.168.64.x/24 kennen die Routen ins Netz 192.168.1.x/24 nicht und umgekehrt genauso.
Wenn du die einträgst, sollten sich alle Geräte unterhalten können.

[Tosog]

Hallo, danke für die Antwort

die routen sollten eigentlich stimmen, hab sie im 1. post gequoted.

dass das server-subnet auch am client (und deren subnet) verfügbar ist, hab ich mittlerweile hinbekommen. ich konnt ja schon vom vpn-client auf 192.168.64.1 pingen und hab dann am server NAT aktiviert damit ich auch aufs dahinterliegende subnet kann.

Andersrum funktionierts aber noch immer nicht, zumal 192.168.1.1 nicht vom VPN-Server pingbar ist obwohl die routen usw. stimmen sollten:

192.168.1.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
wobei der client aber die ip 10.8.0.6 hat. sollte das so richtig sein? (der client hat ja ein 4er netz, also 10.8.0.4/30 - 4=netz, 5=router, 6=ip, 7=bcst - ich kann aber z.B. keine route von 192.168.1.0/24 auf 10.8.0.5 setzen)

[Tosog]

ich habs jetzt hinbekommen. ich hab einen testrechner ebenfalls als openvpn-client eingerichtet - mit der selben config - und dort hats auf anhieb funktioniert.

serverlogs verglichen und dann gabs dieses "wahh" erlebnis, nämlich: ich hatte das client-zertifikat zwar mit dem Namen "epia" erstellt und dabei epia.key, epia.crt bekommen, im client-config-dir (ccd) musste das file jedoch nicht unter epia, sondern unter epia.xyz.at gespeichert werden, also mit domainname. File umbenannt, restart und schon hats funktioniert.


vielleicht hilft das ja jemand anderen der (so wie ich) über google hier hergekommen ist