Open-VPN - Tun-Device?

myrken

Neuer User
Mitglied seit
17 Jan 2007
Beiträge
22
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich besitze eine FB 7170 mit der neusten Labor-Firmware (29.04.63-12661).

Ich möchte, dass die FB sich auf einen schon vorhandenen OVPN-Server einklinkt, das will allerdings nicht so recht, weil das Programm kein TUN-Device findet. Ich habe schon im Forum gesucht und bin auf den Pfad /dev/misc/net/tun gestoßen. Gibt's bei mir allerdings nicht (Tue Nov 11 16:10:29 2008 Cannot open TUN/TAP dev /dev/misc/net/tun: No such file or directory (errno=2)).

Hat sich da mit den neueren Firmwares etwas verändert?

Danke.
 
Hallo myrken,

ich denke so kann Dir keiner weiter helfen.
Bitte poste, welche openvpn Version du drauf hast, nach welcher Beschreibung Du vorgegangen bist und was gegen Freetz spricht;
 
Danke für die Antwort. :)

Ich besitze die Version 2.1_rc1 (openvpn-with-lzo). Noch ein Relikt, als ich schon vor einem guten Jahr mal probierte und aufgab.

Ich habe zwischenzeitlich eine Lösung für das oben genannte Problem gefunden.

Und zwar habe ich mittels mknod /var/tmp/tun c 20 100 das nötige Device "erstellt" und entsprechend in der client.conf darauf verwiesen.

Die Verbindung steht. Ich kann per ping-Befehl in der FritzBox alle Rechner im Netz des VPN-Servers (PC mit IPCop) erreichen.

Allerdings kann ich das nicht von den Rechnern, die an der FritzBox klemmen.
Vermutlich eine route-Geschichte, hinter die ich nicht so ganz komme.

Die Situation:

Die Rechner im VPN-Server-Netzwerk haben den IP-Bereich 192.168.4.xxx.
"Mein" Netzwerk hinter der FB als ovpn-Client den Standard-Bereich von 192.168.178.xxx.

In der FB gibt es folgende, relevante Route (in der conf festgelegt):
192.168.4.0 10.11.12.25 255.255.255.0 UG 0 0 0 tun0

Müsste die nicht eigentlich reichen?

An die Server-Konfiguration komme ich vor morgen nicht.


Ach so: gegen freetz spräche ein nichtvorhandener Linux-Rechner. ;)
 
Zuletzt bearbeitet:
... mit großer Wahrscheinlichkeit fehlt eher die "Rückroute", damit die Geräte aus dem Servernetz auch wissen, wohin das Netz 192.168.178.0 zu routen ist. Wenn der VPN-Server das Defaultgateway im "Servernetz" ist, reicht es, wenn der die Route kennt (und gegebenenfalls einen iroute Eintrag für das Netz hat)

Jörg
 
Ist er. :)

Müsste ich da quasi "iroute 192.168.178.0 255.255.255.0" hinzufügen?
 
... dabei sind zwei Dinge zu beachten:
Zum einen muss das Betriebssystem wissen, dass das "Fritz-Netz" eben "hinter" der Fritz hängt. Das mach ein "normales" Routing, entweder "von Hand" auf der Maschine oder als Parameter in der Config. Das schickt die Pakete dann quasi zum openvpn Prozess.
Wenn der Server so konfiguriert ist, dass er mehrere Clients bedienen kann, muss noch zu zusätzlich der iroute Parameter eingefügt werden (damit routet das OpenVPN intern zwischen den unterschiedlichen Clients). Dieser Parameter wird durch ein "client-connect" Skript oder Einträge in einem "client-config-dir". Das schau dir am besten mal auf der OpenVPN Seite an.
Ich kenne den Server nicht, es kann aber auch sein, dass der ipcop das irgendwie schon intern macht, sofern man Netze beim Client dort "anlegen" kann?

Jörg
 
Ich schau's mir morgen mal an. Und melde mich wieder.

Vielen Dank für die Antworten!
 
Irgendetwas liegt da im Argen.

Die Fritzbox bekommt vom VPN-Server die IP 10.11.12.6.
Beim connecten macht sie folgendes:

Wed Nov 12 13:38:14 2008 /sbin/ifconfig tun0 10.11.12.6 pointopoint 10.11.12.5 mtu 1500
Wed Nov 12 13:38:14 2008 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.11.12.5
Wed Nov 12 13:38:14 2008 /sbin/route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.11.12.5
Wed Nov 12 13:38:15 2008 /sbin/route add -net 10.11.12.1 netmask 255.255.255.255 gw 10.11.12.5

Die Routing-Tabelle der FB sieht dann wie folgt aus:

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.11.12.1 10.11.12.5 255.255.255.255 UGH 0 0 0 tun0
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
10.11.12.5 * 255.255.255.255 UH 0 0 0 tun0
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 * 255.255.255.0 U 0 0 0 lan
192.168.4.0 10.11.12.5 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 10.11.12.5 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 0.0.0.0 U 2 0 0 dsl

Muss ich das verstehen?
Die Routen liegen auf 10.11.12.5, aber darüber findet sich die FB nicht mal selbst.
 
Die .5 ist ja auch der Server. Dein VPN-Interface selbst hat die IP 10.11.12.6 und auf "der anderen Seite" (pointopoint) ist der Server mit 10.11.12.5.

Dass die 10.11.12.5 über das Interface tun0 zu erreichen ist, steht auch so in deiner Routingtabelle:
Code:
10.11.12.5 * 255.255.255.255 UH 0 0 0 tun0

Jörg
 
Der Server hat aber die 10.11.12.1 (P-T-P 10.11.12.2).
 
Der hat sicher mehrere...
Da ist sicher was in der Art "server 10.11.12.0 255.255.255.0" oder "ifconfig pool ...." oder sowas.
Die genannte IP hat dann der Server zum ersten Client, die nächsten Clients liegen dann in jeweils P-t-p Netzen (.5 - .6 , .9 -.10 usw) dahinter, dabei ist die "Serverseite" eigentlich nicht wirklich vergeben, sondern wird eigentlich nur für das Routing genutzt, an sich hat der Server nur die .1...

Jörg
 
Ah, verstehe (so halbwegs). Danke.
Dachte, das wäre der richtige Ansatz.

Kann vielleicht jemand einen Fehler/etwas fehlendes in den jeweiligen Configs entdecken?

server.conf
#OpenVPN Server conf
daemon openvpnserver
writepid /var/run/openvpn.pid
dev tun
tun-mtu 1400
proto udp
port 1194
tls-server
ca /var/ipcop/ovpn/ca/cacert.pem
cert /var/ipcop/ovpn/certs/servercert.pem
key /var/ipcop/ovpn/certs/serverkey.pem
dh /var/ipcop/ovpn/ca/dh1024.pem
server 10.11.12.0 255.255.255.0
push "route 192.168.4.0 255.255.255.0"
route 192.168.178.0 255.255.255.0
status-version 1
status /var/ipcop/ovpn/server.log 30
cipher BF-CBC
comp-lzo
max-clients 100
tls-verify /var/ipcop/ovpn/verify
crl-verify /var/ipcop/ovpn/crls/cacrl.pem
user nobody
group nobody
persist-key
persist-tun
verb 3

client.conf
#OpenVPN Client conf
tls-client
client
dev tun
dev-node /var/tmp/tun
proto udp
route 192.168.0.0 255.255.255.0
remote xxx 1194
pkcs12 xxx.p12
cipher BF-CBC
comp-lzo
verb 3
--ping-restart 0

Wie gesagt. Verbindung steht, die Rechner an der FB als Client (192.168.178.0) können jedoch die Rechner im Server-Netzwerk (192.168.4.0/10.11.12.0) nicht erreichen.
 
Ein direkter "Fehler" ist da nicht drin, aber das ist prinzipiell eine "Multi-Client-Config". Sofern du das nicht brauchst, solltest du das leicht verändern:
Code:
[...]
key /var/ipcop/ovpn/certs/serverkey.pem
dh /var/ipcop/ovpn/ca/dh1024.pem
[B]#[/B]server 10.11.12.0 255.255.255.0
[B]ifconfig 10.11.12.1 10.11.12.2[/B]
push "route 192.168.4.0 255.255.255.0"
route 192.168.178.0 255.255.255.0
[...]

und ein ensprechendes ifconfig 10.11.12.2 10.11.12.1 in der Client config.

Damit sparst du dir die sonst nötigen "iroute" Einträge

Jörg
 
Um die, fürchte ich, komme ich nicht herum.
Das ist in der Tat eine Multi-Client-Config und sie wird auch als solche benötigt.

Wie muss denn so eine iroute aussehen? Mit "iroute 192.168.178.0 255.255.255.0" lies sich openvpn nicht mehr starten.
 
siehe oben ;-)

Der Parameter muss ins "client-config-dir" oder in einem "client-connect" Skript gesetzt werden.

Ich mache sowas mit dem ersteren: In die Server-Config kommt z.B. ein "client-config-dir /var/ipcop/ovpn/ccd" (oder wo auch immer du ein solches Verzeichnis "ccd" anlegen kannst). In dem Verzeichnis liegt dann eine Datei die so heisst, wie der Name deines Zertifikates ist (sagen wir mal "fbox"), dann müsste die Datei /var/ipcop/ovpn/ccd/fbox diesen Inhalt haben (die Routen würde ich auch da reinpacken):

Code:
ifconfig-push 10.11.12.222 10.11.12.1
iroute 192.168.178.0 255.255.255.0
push "route-gateway 10.11.12.1"
In der Server-Config den route-Eintrag so ergänzen:
route 192.168.178.0 255.255.255.0 10.11.12.222


Jörg

EDIT Nee, Zugriff auf das Servernetz braucht wohl jeder, das push "route 192.168.4.0 255.255.255.0" also drin lassen!
 
Danke! :)

Ich habe das mal so übernommen, aber irgendwas scheint noch zu fehlen.

Beim Verbinden spuckt die FB nun folgendes aus:

Wed Nov 12 20:08:23 2008 /sbin/ifconfig tun0 10.11.12.222 pointopoint 10.11.12.1 mtu 1500
Wed Nov 12 20:08:23 2008 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.11.12.1
Wed Nov 12 20:08:23 2008 /sbin/route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.11.12.1
Wed Nov 12 20:08:24 2008 OpenVPN ROUTE: omitted no-op route: 10.11.12.1/255.255.255.255 -> 10.11.12.1

Die Route sieht so aus:

Destination Gateway Genmask Flags Metric Ref Use Iface
10.11.12.1 * 255.255.255.255 UH 0 0 0 tun0
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 * 255.255.255.0 U 0 0 0 lan
192.168.4.0 10.11.12.1 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 10.11.12.1 255.255.255.0 UG 0 0 0 tun0
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 0.0.0.0 U 2 0 0 dsl

Rechner aus dem 192.168.178.0er-Netz finden trotzdem nix. Auch nicht 10.11.12.1.
 
Kannst du denn von der Box die 10.11.12.1 anpingen?
Können die Geräte aus dem lokalen Netz die 10.11.12.222 anpingen?
Kann der Server per Ping die IP der Box (192.168.178.1) erreichen?
Könntest du ein "route -n" vom Server posten?

Jörg
 
Kannst du denn von der Box die 10.11.12.1 anpingen?

Ja.

Können die Geräte aus dem lokalen Netz die 10.11.12.222 anpingen?

Ja. :)

Kann der Server per Ping die IP der Box (192.168.178.1) erreichen?

Nein. Nur eben per 10.11.12.222. :(

route -n vom Server:

root@vpn:~ #route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.11.12.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.11.12.0 10.11.12.2 255.255.255.0 UG 0 0 0 tun0
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
194.8.210.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
0.0.0.0 194.8.210.193 0.0.0.0 UG 0 0 0 eth2
 
Da haben wir es doch schon? Hast du sicher in der Server-Konfig die Zeile
Code:
route 192.168.178.0 255.255.255.0 10.11.12.222
eingefügt? Diese Route fehlt!
 
[Edit frank_m24: Sinnfreies Fullquote vom Beitrag direkt darüber gelöscht. Lies noch mal die Forumregeln.]

Die Zeile steht drin, aber der Server scheint die Zeile zu ignorieren oder nicht zu akzeptieren.
 
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.