OpenVPN-Paket

[MaxMuster]

Wenn man weiß, wie es geht, kann man (o.k., ich vermutlich nicht, aber vielleicht knox) sicher die Gui für den Anwendungsfall erweitern.
Wie es evtl. aussehen könnte, habe ich schonmal angedacht, habe jedoch keine Ahnung von der Programmierung und erstmal soll sich ja zeigen, dass es so geht!

Jörg

 

[knox]

Entschuldigt bitte, aber ich halte client-config-dir für einen Irrweg.

Vielleicht haben wir ja auch einen Bug in OpenVPN gefunden? Immerhin wird im ds-mod ein Release Candidate verwendet, der nicht als "stabil" gelten kann.

Ich werde mir noch mal ausführlich die OpenVPN Doku anschauen, möglicher Weise habe ich irgendwas falsch verstanden oder im Package falsch umgesetzt.

--server network netmask
    A helper directive designed to simplify the configuration of OpenVPN's server mode. This directive will set up an OpenVPN server which will allocate addresses to clients out of the given network/netmask. The server itself will take the ".1" address of the given network for use as the server-side endpoint of the local TUN/TAP interface.

    For example, --server 10.8.0.0 255.255.255.0 expands as follows:

         mode server
         tls-server
         push "topology [topology]"

         if dev tun AND (topology == net30 OR topology == p2p):
           ifconfig 10.8.0.1 10.8.0.2 
           ifconfig-pool 10.8.0.4 10.8.0.251
           route 10.8.0.0 255.255.255.0
           if client-to-client:
             push "route 10.8.0.0 255.255.255.0"
           else if topology == net30:
             push "route 10.8.0.1"

         if dev tap OR (dev tun AND topology == subnet):
           ifconfig 10.8.0.1 255.255.255.0
           ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
           push "route-gateway 10.8.0.1"

Außerdem gibt es noch einen relativ neuen Parameter, den ich bisher überhaupt nicht berücksichtigt habe:

--topology mode
    Configure virtual addressing topology when running in --dev tun mode. This directive has no meaning in --dev tap mode, which always uses a subnet topology.

    If you set this directive on the server, the --server and --server-bridge directives will automatically push your chosen topology setting to clients as well. This directive can also be manually pushed to clients. Like the --dev directive, this directive must always be compatible between client and server.

    mode can be one of:

    net30 -- Use a point-to-point topology, by allocating one /30 subnet per client. This is designed to allow point-to-point semantics when some or all of the connecting clients might be Windows systems. This is the default on OpenVPN 2.0.

    p2p -- Use a point-to-point topology where the remote endpoint of the client's tun interface always points to the local endpoint of the server's tun interface. This mode allocates a single IP address per connecting client. Only use when none of the connecting clients are Windows systems. This mode is functionally equivalent to the --ifconfig-pool-linear directive which is available in OpenVPN 2.0 and is now deprecated.

    subnet -- Use a subnet rather than a point-to-point topology by configuring the tun interface with a local IP address and subnet mask, similar to the topology used in --dev tap and ethernet bridging mode. This mode allocates a single IP address per connecting client and works on Windows as well. Only available when server and clients are OpenVPN 2.1 or higher, or OpenVPN 2.0.x which has been manually patched with the --topology directive code. When used on Windows, requires version 8.2 or higher of the TAP-Win32 driver. When used on *nix, requires that the tun driver supports an ifconfig(8) command which sets a subnet instead of a remote endpoint IP address.

    This option exists in OpenVPN 2.1 or higher.

 

[MaxMuster]

Hi,

das mit "server net mask" hätte ich auch vorgeschlagen, allerdings gibt es bei einer Multi-Client-Umgebung mit Tunneln ja in der Tat zusätzlich das Problem, dass ich irgendwo festlegen muss, welche Netze "hinter" einem Client liegen.
So wie jetzt mit der GUI gelöst kann ich das zwar für einen Client machen, bei mehreren wird es momentan eng, ich muss ja den "route Netz Maske" Eintrag nun einem bestimmten Client zuordnen können (zusätzlich ja vielleicht auch noch den "iroute"-Eintrag). Geht das evtl mit einem "push" vom Client zum Server?
Ansonsten ist das client-config-dir doch gerade dafür gedacht, oder? Vielleich bin ich ja auch auf nem Holzweg und sehe das nur nicht, wie es sonst gehen könnte...

Jörg

 

[wengi]

Dann verändere die config-Datei wie folgt :

                if [ ! -d /var/tmp/ovpn ]; then
                   mkdir /var/tmp/ovpn
                fi
                cp  /var/tmp/flash/ovpn/* /var/tmp/ovpn/
                echo "client-config-dir /var/tmp/ovpn"

Hi Jörg,

das erzeugte conf file sieht so aus:

/var/tmp/flash $ cat /mod/etc/openvpn-lzo.conf
# OpenVPN 2.1 Config
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
mode server
tls-server
dh /tmp/flash/dh.pem
ifconfig-pool 10.0.0.2 10.0.0.60
ifconfig 10.0.0.1 10.0.0.2
route 10.0.0.0 255.255.255.0
client-config-dir /var/tmp/ovpn
push "route 10.0.0.0 255.255.255.0"
push "route 192.168.201.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.1"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher AES-128-CBC
route 192.168.203.0 255.255.255.0
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
/var/tmp/flash $

UND FUNKTIONIERT!
wengi

 

[MaxMuster]

Schön wenns so klappt.

Ich habe das mal "etwas nachgebaut", denn so läuft es wohl nur mit dem ersten Client. Für den zweiten müsste die datei (nennen wir sie mal "/var/tmp/flash/ovpn/client2" wie folgt heißen:

[I]# eine Eindeutige IP für die Tunneladresse beim Client, z.B. die 200.6 
# ansonsten gibt es z.B. als Paar 200.6 und 200.5, auf der Server-Seite 
# gibt es aber die 200.5 dann nicht. Deshalb nutzen wir dort auch die 200.1,
# die ja bein Starten angelegt wird.
# Ob das ein Bug oder ein Feature ist, kann ich nicht sagen.   
[/I]
ifconfig-push 192.168.200.6 192.168.200.1

[I]# Welches Netz ist hinter dem Client[/I]
iroute 192.168.205.0 255.255.255.0

Damit das dann funktioniert, muss der Befehl "route 192.168.205.0 255.255.255.0" noch in die Server-Config mit hinein, denn das iroute ist nur für die "interne Route".

Jörg

 

[wengi]

Die Tests mit dem zweiten Client werden noch einen Moment dauern, da ich den noch "dsmodden" muss. Aber die nächste Frage ergibt sich jetzt schon: Wie werden die Routen auf Clientseite eingetragen? JEDER Client muss ja alle Client-Netze (bis auf das Eigene) zum Server routen.
Wäre schön, wenn OpenVPN das auch machen würde.
Ansonsten müsste man die Routen per Hand (debug.cfg) einfügen.
Mit den DNS-Servern und -Einträgen fang ich lieber nicht an

wengi

 

[MaxMuster]

Du kannst den Configs im client-config-dir mitgeben, was der Server alles "pushen" soll. So kannst du dann allen die "anderen" Netze (und übrigens auch ein paar "DNS-Dinge") verteilen.

Alternativ könnte man die Inhalte übrigens auch per Script beim Anmelden eines Clients dynamisch erzeugen lassen. Dafür gibt es dann den Befehl "client-connect <script>" (und das Gegenstück "client-disconnect")

Das ist bisher aber nur Theorie, du darfst das aber gerne mit Praxis-Erfahrungen ergänzen ;-)

Jörg

 

[knox]

Schön, dass es anscheinend eine Lösung für das Problem gibt.

Allerdings graut es mir, wenn ich daran danke, wie aufwendig es wird, "client-config-dir" mitsammt den darin enthaltenen Configs pro Client im ds-mod Webinterface zu implementieren. Eigentlich eine Arbeit, die ich mir nicht machen möchte. Denn ich halte dieses Setup für "fortgeschritten" und nicht für erforderlich für einen "normalen Benutzer".

Ich will es auch noch nicht wirklich glauben, dass ein vernünftiger Betrieb Subnetz --TUN-- Subnetz nur mit client-config-dir funktionieren sollte. Schließlich war TUN der erste Betriebsmodus, den dieses Paket - damals noch von Lord-of-Linux betreut - angeboten hat. Und dann hätten sich doch sicher mehr Leute gemeldet, wenn das quasi von Anfang an nicht richtig funktionert haben sollte?

Ein weiterer Beleg für meine These, dass es auch ohne client-config-dir gehen sollte, hat wengi selbst gebracht; weiter oben postet er eine als funktionierend bezeichnete Konfiguration - ohne client-config-dir.

Ich selbst habe aber auch so gut wie keine Erfahrungen mit dem von Euch besprochenen Setup, da ich selbst nur im TAP Modus arbeite und auch nicht Netze miteinander verbinde, sondern nur Clients von extern Zugriff zu einem Netz bereitstelle.

Bitte helft mir also auf die Sprünge: wenn mir nochmal jemand begründen könnte, wieso es nur mit client-config-dir gehen sollte?

 

[MaxMuster]

Hi,

Erst mal das Vorweg: Deine Arbeit für den "supereinfachen" Einsatz des VPN mit der GUI ist und bleibt klasse. Es geht keinesfalls darum, dass dir hier jemand "an den Karren fahren" will, eher ein "Feature-Request".


Die Problematik entsteht nur dann, wenn der "mode server" aktiv ist. Dann ist der Server insofern "eigen", dass er ankommende Pakete nochmal auf "Plausibilität/Erlaubtheit" prüft. So kommt es dann, dass die "ursprüngliche" Konfig zwar funktioniert, aber nur, solange die Pakete nur vom Client selbst kommen. Sobald welche vom LAN hinter dem Client kommen, werden die Verworfen, weil der Server (im mode server) hinter dem Tunnel nur die Tunnel-IP oder explizit bekanntgegebene Adressen/Netze zulässt.
Daher funktioniert die Konfig oben, da der "mode server" und der "ifconfig-pool" gelöscht wurden.

Hintergrund ist, wenn ich das richtig interpretiert habe, dass dieser Modus ein "Routing über das virtuelle Interface" einführt denn es können/sollen dann ja mehrere Clients hinter diesem einen Interface hängen. Dafür gibt es zu diesem "internen Routing" dann eben die "iroute" Einträge.
Diese müssen dann einem Client zuzuordnen sein, daher geht der Weg über die "normale" Konfig nicht, sondern über dieses muss mit den Clients verknüpft sein (so verstehe ich das zumindest , und leider auch, dass das config-dir wohl nötig ist):

The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the --iroute directive routes to the specific client.
This option must be specified either in a client instance config file using --client-config-dir or dynamically generated using a --client-connect script.

Das sieht in der Praxis dann so aus, dass in der Routingtable der FBF alle Netze bei irgendeinem Client auf das Tunnel-Interface herausgeroutet werden sollen (z.B. auf die 192.168.200.2, egal ob das Netz nun wirklich an dem Client mit der 192.168.200.2, oder an dem mit der 192.168.200.6, oder wo auch immer ist). Danach "schnappt" sich der OpenVPN-Prozess die Pakete und "schiebt" sie dem richtigen Client zu (dann stehen z.B. auch im /var/log/openvpn die Netze, die der Prozess bei einem bestimmten Client sieht)

Für die GUI würde das meiner Ansicht nach bedeuten, dass in der "Standard-Konfig" mit tun nur ein Client möglich sein sollte, dann entfiele die Notwendigkeit für mode server, bei mehreren Clients (das wäre jetzt meine Idee) gäbe es als "Experten-Konfig" ein Feld, was in etwa so sein könnte:

#Client #Tunnel-IP     #Netz1      #Maske1        #Netz2      #Maske2   
client1 192.168.200.6  192.168.1.0 255.255.255.0  192.168.2.0 255.255.255.0 
client2 192.168.200.10 192.168.11.0 255.255.255.0 192.168.12.0 255.255.255.0

oder mit Kommata getrennt oder was auch immer.
Daraus wird dann ein (wie gesagt, ich bin ein mieser Skripter, aber ich hoffe, die Idee wird sichtbar):

echo "#Routen für OpenVPN-Server zu den Clients" > /tmp/ovpn_server_routes.tmp
[I]für alle Zeilen in dem Feld do[/I]
i=Anzahl_Argumente
echo i"fconfig-push $ARG_2 $OPENVPN_LZO_BOX_IP" > /tmp/ovpn/$ARG_1
x=3
while (x<i) do
  echo "iroute $ARG_(i) $ARG_(i+1)" >> /tmp/ovpn/$ARG_1
  echo "route $ARG_(i) $ARG_(i+1)" >> /tmp/ovpn_server_routes.tmp
  x+= 2
od
cat /tmp/ovpn_server_routes.tmp >> /mod/etc/openvpn-lzo.conf

Alternativ (ich habe keine Ahnung vom möglichen Aufwand) eine "Unterseite", die in Abhängigkeit der "Anzahl Clients" funktioniert:
ein Dropdownfeld mit Einstellungen für <Nummer des Clients>
ein Feld mit <IP des Clients>
ein Feld mit <Netz1,Maske1> <Netz2,Maske2> ...
(oder es gehen maximal n Netze für die es je ein Feld gibt)


Jörg

 

[wengi]

Erst mal das Vorweg: Deine Arbeit für den "supereinfachen" Einsatz des VPN mit der GUI ist und bleibt klasse. Es geht keinesfalls darum, dass dir hier jemand "an den Karren fahren" will, eher ein "Feature-Request".

Da kann ich mich nur anschließen.

Die obige Erklärung von Jörg ist einleuchtend und gut! Danke dafür.
Ich stimme mit Deiner Tabelle für eine "Experten-Konfig" allerdings nicht ganz überein oder hab noch was falsch verstanden.
Wofür benötigst Du zwei Netze pro Client?
Man braucht die Tunnel-IPs und das Netz, das hinter der Client-Box liegt.
In meinem Fall:

#Client #Tunnel-IP     #Netz1           #Maske1
client1 10.0.0.2       192.168.203.0  255.255.255.0
client2 10.0.0.3       192.168.202.0  255.255.255.0

Wofür ist das zweite Netz?

wengi

 

[MaxMuster]

Naj, ich dachte halt, wenn man schon dabei ist... Es können ja durchaus mehr als ein Netz an deinem Client dranhängen. Mit nur einem würde das ganze natürlich deutlich vereinfacht.
Das sollte man wohl auch (wenn es denn überhaupt den Sprung in eine GUI schafft) auf ein Netz beschränken. Der "Hauptanwendungsfall" wird sicher "ein Netz hinter einem Client" sein. Da gebe ich dir Recht, wer mehr braucht, braucht keine GUI!
Vergiss das mit den mehreren Netzen also, knox, da wollte ich einfach zu perfekt sein! Ich würd es ja löschen, dann stände der Beitrag von wengi aber ziemlich in der Luft.

Jörg

 

[wengi]

Auch die Kommunikation der Clientnetze untereinander würde ich auf "Alles oder Nichts" beschränken. Soll heißen: Entweder können die Clientnetze jeweils nur mit dem Server-Netz kommunizieren oder jeder mit jedem.
Das vereinfacht das ganze weiter.

Hier muss ich knox auch zu 100% Recht geben. Keep it simple. Wenn jemand sein Routing noch mehr anpassen will soll ers halt ohne GUI machen. (Wobei ich auch jetzt schon zufrieden bin, wenn es ohne GUI funktioniert.)

wengi

 

[knox]

Vielen Dank für die Blumen - und die hervorrangede Ausarbeitung der technischen Details. Ich werde mich da in einer ruhigen Minute noch mal einfuchsen.

Daher funktioniert die Konfig oben, da der "mode server" und der "ifconfig-pool" gelöscht wurden.

Dann ist es doch vielleicht im ersten Anlauf einfacher, das Package dahingehend anzupassen, dass eine solche Config erzeugt wird. Wäre jedenfalls weniger Arbeit, als eine komplexe client-config-dir Struktur aufzubauen. (Nur so ein Gedanke).

Aber wenn es tatsächlich "benötigt" wird, und sogar schon erste Ansätze zur Umsetzung existieren, wieso sollte es dann nicht seinen Weg in die GUI finden?

Falls sich noch jemand aktiv daran Beteiligen möchte: helping hands are allways welcome.

Anmerkung:

die Kommunikation der Clientnetze untereinander würde ich auf "Alles oder Nichts" beschränken. Soll heißen: Entweder können die Clientnetze jeweils nur mit dem Server-Netz kommunizieren oder jeder mit jedem.

Ich dachte, genau das bewirkt "client-to-client", was in der GUI mit "Clients dürfen untereinader Kommunizieren" bezeichnet ist.

 

[wengi]

Hi knox,

es könnte jetzt ja jemand auf die Idee kommen das noch zu differenzieren. Also " ClientNetz1 darf überall hin, ClientNetz2 nur ins Servernetz, ClientNetz3 darf ....". Und genau das wäre zu viel Aufwand.

Was die Hilfe angeht: Wenn ich kann werde ich gerne helfen.
Zunächst muss ich das zweite Client-Netz vorbereiten.
Danach werde ich versuchen eine funktionierende Konfiguration für beide Client-Netze zu erstellen.
Nachdem dies geschehen ist kann ich die openvpn-lzo_conf anpassen.
Die Modifikation der GUI wird dann aber zu viel für meine Kenntnisse.

wengi

 

[hermann72pb]

Schreck dich nicht ab, wendi. Es ist nicht so wild, GUI zu programmieren. Ich hab eure Diskussion verfolgt und verstehe nur Bahnhof (und ich dachte vorher, ich kenne mich mit OpenVPN aus). Wenn ihr schon über solche ausgeklugte Sachen hier beredet, schaffst du es sicher mit links knox zu helfen und auch GUI zu programmieren. Dafür musst du sogar nicht jedes Mal flashen. Als ich die GUI für meinen Downloader getestet hatte (und wohl gemerkt von Null angefangen), hatte ich alles erstmal im RAM gepackt. Und das hat erstaunlicherweise funktioniert! Für die Configs benutzt man die Standardwerkzeuge des mods, sodass sie dann dauerhaft gespeichert werden. Wenn GUI ausgiebig getestet ist, packt man es ins Image.
Ich wollte damit nur sagen, dass es teilweise nicht so schwierig ist, wie es aussieht. Es kostet nur nachher Zeit, wenn man es perfektioniert.

MfG

 

[MaxMuster]

Nabend,

Dann ist es doch vielleicht im ersten Anlauf einfacher, das Package dahingehend anzupassen, dass eine solche Config erzeugt wird. Wäre jedenfalls weniger Arbeit, als eine komplexe client-config-dir Struktur aufzubauen. (Nur so ein Gedanke).

Das hilft aber nur, wenn man nur einen Client hat...

Ich habe mal versucht, was zu entwerfen, wirklich nur ein allererster Schritt (ich habe halt keine Anhung davon, aber vielleicht kann es ja jemand besser machen ;-))

Zum Testen könntet ihr die Dateien nach /var/tmp laden und dann die "echten" Dateien zum testen "überladen":

mount -o bind /var/tmp/openvpn-lzo.cgi /usr/lib/cgi-bin/openvpn-lzo.cgi
mount -o bind /var/tmp/openvpn-lzo.cfg  /mod/etc/default.openvpn-lzo/openvpn-lzo.cfg
cp cp /var/tmp/openvpn-lzo_conf /var/tmp/flash

Die ganze "Ein- und Ausblenderei" ist noch nicht wie ich es gerne hätte und ich weiß auch nicht, ob alles andere damit noch geht, aber als "Proof-of-Concept" kann es ja vielleicht durchgehen ;-)

Viel Erfolg!

EDIT: Kurz zum Inhalt: Ich habe für Server und TUN die folgenden Befehle genutzt:

server <netz> <mask>
topology subnet

Die Einträge bei den Clients werden in die Config zum Routen geschrieben und in das "client-config-dir" für die iroute Einträge.

 

[wengi]

Ok. Hier mal der aktuelle Status:

ich habe gerade das zweite Clientnetz eingebunden (FBF7141 mit ds26-15.2).
Auf der Serverseite habe ich lediglich im client-config-dir die nötige Datei angelegt. Nach Neustart des OpenVPN Servers erhalte ich folgendes:

/var/tmp/flash $ cat /var/log/openvpn.log
OpenVPN CLIENT LIST
Updated,Wed Aug  8 19:31:49 2007
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client2,xxx.yyy.96.117:2054,3652,3850,Wed Aug  8 19:31:37 2007
client1,xxx.yyy.17.58:2071,3434,3706,Wed Aug  8 19:31:17 2007
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
192.168.203.0/24,client1,xxx.yyy.17.58:2071,Wed Aug  8 19:31:19 2007
10.0.0.6,client2,xxx.yyy.96.117:2054,Wed Aug  8 19:31:40 2007
10.0.0.2,client1,xxx.yyy.17.58:2071,Wed Aug  8 19:31:19 2007
192.168.202.0/24,client2,xxx.yyy.96.117:2054,Wed Aug  8 19:31:39 2007
GLOBAL STATS
Max bcast/mcast queue length,2
END
/var/tmp/flash $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
10.0.0.2        *               255.255.255.255 UH    0      0        0 tun0
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
10.0.0.0        10.0.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.201.0   *               255.255.255.0   U     0      0        0 lan
192.168.203.0   10.0.0.2        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
/var/tmp/flash $

Wie man sieht ist der Tunnel des zweiten Clients da! Allerdings wird die Route nicht eingetragen. Ich muss mich jetzt erst mal mit dem route Befehl rumärgern, um die route manuell zu setzen, und dann sollte es wohl funktionieren.

Ich bin also kurz vor meinem Ziel!

wengi

PS: Warum jetzt client2 die 10.0.0.6 hat und nicht wie konfiguriert die .3 muss ich auch nicht verstehen... Ich hab noch viel zu lesen.

 

[MaxMuster]

Welche Route wird denn wo nicht eingetragen? Die Route zum Client2-Netz auf dem Server? Hast du denn ein "route 192.168.202.0 255.255.255.0" in der Config? Überhaupt: Wie sieht denn momentan die Konfig aus?
Die Sache mit der Client-IP geht vermutlich, wenn du topology subnet beim Server benutzt.

Hast du die Konfig "von Hand" geschrieben oder mit der oben reingestellten "Alpha-GUI für Multi-Client TUN" ?

Jörg

 

[wengi]

server:

/var/tmp/flash $ cat /mod/etc/openvpn-lzo.conf
# OpenVPN 2.1 Config
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
mode server
tls-server
dh /tmp/flash/dh.pem
ifconfig-pool 10.0.0.2 10.0.0.60
ifconfig 10.0.0.1 10.0.0.2
route 10.0.0.0 255.255.255.0
client-config-dir /var/tmp/ovpn
push "route 10.0.0.0 255.255.255.0"
push "route 192.168.201.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.1"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher AES-128-CBC
route 192.168.203.0 255.255.255.0
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
/var/tmp/flash $

/var/tmp/flash $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
10.0.0.2        *               255.255.255.255 UH    0      0        0 tun0
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
10.0.0.0        10.0.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.201.0   *               255.255.255.0   U     0      0        0 lan
192.168.203.0   10.0.0.2        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
/var/tmp/flash $

Client2 (192.168.202.x)

/var/mod/root $ cat /mod/etc/openvpn-lzo.conf
# OpenVPN 2.1 Config
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
tls-client
ns-cert-type server
pull
remote mdesaster.dyndns.org
nobind
ifconfig 10.0.0.3 10.0.0.1
tun-mtu 1500
mssfix

daemon
verb 3

cipher AES-128-CBC
route 192.168.201.0 255.255.255.0
comp-lzo
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log
/var/mod/root $



/var/mod/root $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.5        *               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
10.0.0.0        10.0.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.201.0   10.0.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.202.0   *               255.255.255.0   U     0      0        0 lan
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl
/var/mod/root $

Da stimmt einiges noch nicht.
Ich muss jetzt allerdings weg. Näheres morgen.

wengi

 

[MaxMuster]

Hier liegt (neben dem fehlenden Route Eintrag) das Problem in der "topology": Standardmäßig werden für den Tunnel /30-er Subnets genutzt (mit jeweils zwei nutzbaren Adressen), der zweite Client bekommt so das nächste freie Paar, halt die .5 und .6.
Das "Problem" daran ist, dass beim Server ja nur das eine Tunnel-Interface ist, das ja schon die Adresse .1 bekommen hat.

Mit dem Parameter "topology subnet" kannst du das umgehen, damit baut der Server quasi eine "Point-to.Multipoint" Verbindung auf:
Er selbst nutzt z.B. die .1, der erste Client die .2, nächste Client die .3 usw. Der Clou dabei ist, dass alle Clients nun direkt auf das Tunnelinterface beim Server verweisen können....

Zum allgemeinen Thema "Tunnel mit mehreren Clients mit Netzen bei den Clients":
Ich habe nach einer langen Nacht mal einen erneuten Vorschlag für die GUI mit einer geringfügigen Modifikation des Config-Skriptes, was nun "vereinheitlicht" wurde (nur noch echo "x y " >> Zieldatei ) und vom rc-Script mit dem Namen der Zieldatei aufgerufen wird (also mit /mod/etc/default.$DAEMON-lzo/${DAEMON}-lzo_conf /mod/etc/$DAEMON-lzo.conf)

Ich weiß, speziell das .cgi ist nicht "schön Programmiert", aber es scheint zu funktionieren...

Vielleicht kann es ja mal jemand überarbeiten und dann in das Release mit aufnehmen...

EDIT Ich habe das nun mal auf zwei Boxen (eine ds-0.2.9-p8 mit rc2 als Client, eine ds26-15.2 mit rc4 als Server) installiert und konnte zumindest genau die gewünschte Konstellation erfolgreich nachstellen: Die Config wurde korrekt erzeugt, OpenVPN startete und die Routen wurden "gepushed und gepulled".

Jörg