OpenVPN-Paket

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Die "normale" GUI nimmt dir u.a. das Erstellen des client-config-dirs sowie der Config-Dateien darin ab. Diese Dateien werden beim Start erzeugt und liegen nicht "resetfest" im Flash.

Für die "simple" GUI musst du das alles "von Hand anlegen" (ggf. im flash, um es wieder verwenden zu können), und dann auf das angelegte Verzeichnis referenzieren.

Alternativ kann man "ähnliches" über ein "Client-Connect-Skript" erreichen. Ein Beispiel dafür habe ich in der "Mini-Doku" zur neuen GUI gegeben:

http://freetz.org/wiki/packages/openvpn#NeuesimpleGUIGUI2
 

JokerGermany

Mitglied
Mitglied seit
7 Aug 2007
Beiträge
564
Punkte für Reaktionen
5
Punkte
18
Ok, habe jetzt
Code:
--client-config-dir /var/tmp/flash/openvpn/clients_openvpn
genutzt und den Ordner selber angelegt.
Heute abend wenn ich der ClientFritz!Box Thetering gebe, werde ich mal schauen, ob es gefruchtet hat, die Initialisierung sieht vielversprechend aus.

cat /var/tmp/debug_openvpn.out
Code:
Tue Mar 15 15:10:19 2016 OpenVPN 2.3.10 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Feb 26 2016
Tue Mar 15 15:10:19 2016 library versions: OpenSSL 1.0.1r  28 Jan 2016, LZO 2.09
Tue Mar 15 15:10:20 2016 Diffie-Hellman initialized with 2048 bit key
Tue Mar 15 15:10:20 2016 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Tue Mar 15 15:10:20 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 15 15:10:20 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 15 15:10:20 2016 Socket Buffers: R=[87380->87380] S=[16384->16384]
Tue Mar 15 15:10:20 2016 TUN/TAP device tun0 opened
Tue Mar 15 15:10:20 2016 TUN/TAP TX queue length set to 100
Tue Mar 15 15:10:20 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Mar 15 15:10:20 2016 /sbin/ifconfig tun0 192.168.200.1 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Tue Mar 15 15:10:20 2016 /sbin/route add -net 192.168.188.0 netmask 255.255.255.0 gw 192.168.200.2
Tue Mar 15 15:10:20 2016 Listening for incoming TCP connection on [undef]
Tue Mar 15 15:10:20 2016 TCPv4_SERVER link local (bound): [undef]
Tue Mar 15 15:10:20 2016 TCPv4_SERVER link remote: [undef]
Tue Mar 15 15:10:20 2016 MULTI: multi_init called, r=256 v=256
Tue Mar 15 15:10:20 2016 IFCONFIG POOL: base=192.168.200.100 size=151, ipv6=0
Tue Mar 15 15:10:20 2016 MULTI: TCP INIT maxclients=9 maxevents=13
Tue Mar 15 15:10:20 2016 Initialization Sequence Completed

Also macht die SimpleGUI gar nichts einfacher sondern die GUI ist einfach simple? XD
 

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Also macht die SimpleGUI gar nichts einfacher sondern die GUI ist einfach simple? XD
Ja, genau so ist es!

So sollte denjenigen, die eine "fertige Konfig" haben die Möglichkeit gegeben werden, die einfach in das Textfeld einzufügen und das nicht in die GUI-Felder zu "übersetzen".
Je komplexer die Aufgabenstellung (z.B. Multi-Client-Server mit "iroutes") um so mehr muss man halt auch tun ;-)
Den recht häufigen Spezialfall mit Netzen bei den Clients (was mit dem Client-Config-Dir zu erledigen ist) hatten wir deshalb in die (normale) GUI mit eingearbeitet.
 
Zuletzt bearbeitet:

JokerGermany

Mitglied
Mitglied seit
7 Aug 2007
Beiträge
564
Punkte für Reaktionen
5
Punkte
18
Ja, genau so ist es!
Dann hätte ich lieber nicht umsteigen sollen, aber jetzt ist zu spät. Aber solange ich euch habe, kann das Tal noch so Finster sein ;)

Hab noch Probleme mit meiner Verbindung:
Die Fritz!Box kann ins andere Netzwerk pingen (mit mörderischen Latenzen von über 80ms), mein Rechner aber nicht.

route Client
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     2      0        0 dsl
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
192.168.2.0     192.168.200.1   255.255.255.0   UG    0      0        0 tun0
192.168.43.0    *               255.255.255.0   U     2      0        0 dsl
192.168.43.1    *               255.255.255.255 UH    2      0        0 dsl
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.188.0   *               255.255.255.0   U     0      0        0 lan
192.168.189.0   *               255.255.255.0   U     0      0        0 guest
192.168.200.0   *               255.255.255.0   U     0      0        0 tun0
192.168.200.1   192.168.200.1   255.255.255.255 UGH   0      0        0 tun0
Code:
cat /var/tmp/debug_openvpn.out
Tue Mar 15 19:37:23 2016 OpenVPN 2.3.10 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Feb 26 2016
Tue Mar 15 19:37:23 2016 library versions: OpenSSL 1.0.1r  28 Jan 2016, LZO 2.09
Tue Mar 15 19:37:23 2016 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Tue Mar 15 19:37:23 2016 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Tue Mar 15 19:37:23 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 15 19:37:23 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 15 19:37:23 2016 Socket Buffers: R=[87380->87380] S=[16384->16384]
Tue Mar 15 19:37:24 2016 Attempting to establish TCP connection with [AF_INET]xx.xxx.xx.xxx:1194 [nonblock]
Tue Mar 15 19:37:25 2016 TCP connection established with [AF_INET]xx.xxx.xx.xxx:1194
Tue Mar 15 19:37:25 2016 TCPv4_CLIENT link local: [undef]
Tue Mar 15 19:37:25 2016 TCPv4_CLIENT link remote: [AF_INET]xx.xxx.xx.xxx:1194
Tue Mar 15 19:37:25 2016 TLS: Initial packet from [AF_INET]xx.xxx.xx.xxx:1194, sid=18101f44 d2158aba
Tue Mar 15 19:37:26 2016 VERIFY OK: depth=1, C=DE, ST=Niedersachsen, L=xyz, O=Internet Ltd., OU=MyOrganizationalUnit, CN=Internet Ltd. CA, name=JokerGermany, emailAddress=JokerGermany
Tue Mar 15 19:37:26 2016 VERIFY OK: depth=0, C=DE, ST=Niedersachsen, L=xyz, O=Internet Ltd., OU=MyOrganizationalUnit, CN=stadt, name=JokerGermany, emailAddress=JokerGermanym
Tue Mar 15 19:37:29 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 15 19:37:29 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 15 19:37:29 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 15 19:37:29 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 15 19:37:29 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Tue Mar 15 19:37:29 2016 [stadt] Peer Connection Initiated with [AF_INET]87.174.47.100:1194
Tue Mar 15 19:37:31 2016 SENT CONTROL [stadt]: 'PUSH_REQUEST' (status=1)
Tue Mar 15 19:37:31 2016 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.200.1,topology subnet,route 192.168.2.0 255.255.255.0,route 192.168.200.1,ping 10,ping-restart 120,ifconfig 192.168.200.100 255.255.255.0'
Tue Mar 15 19:37:31 2016 OPTIONS IMPORT: timers and/or timeouts modified
Tue Mar 15 19:37:31 2016 OPTIONS IMPORT: --ifconfig/up options modified
Tue Mar 15 19:37:31 2016 OPTIONS IMPORT: route options modified
Tue Mar 15 19:37:31 2016 OPTIONS IMPORT: route-related options modified
Tue Mar 15 19:37:31 2016 TUN/TAP device tun0 opened
Tue Mar 15 19:37:31 2016 TUN/TAP TX queue length set to 100
Tue Mar 15 19:37:31 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Mar 15 19:37:31 2016 /sbin/ifconfig tun0 192.168.200.100 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Tue Mar 15 19:37:31 2016 /sbin/route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.200.1
Tue Mar 15 19:37:31 2016 /sbin/route add -net 192.168.200.1 netmask 255.255.255.255 gw 192.168.200.1
Tue Mar 15 19:37:31 2016 Initialization Sequence Completed

Die Client-Config:
Code:
proto tcp-client
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
tls-auth /tmp/flash/openvpn/static.key 1
remote xxx.myfritz.net
nobind
pull
#redirect-gateway
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher BF-CBC
comp-lzo
float
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log
persist-tun
persist-key
#http-proxy 172.30.0.30 3128
 
Zuletzt bearbeitet:

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Wo hast du denn die Änderung der GUI vorgenommen? Auf dem Client?!? Denn das "fehlerhafte" client-config-dir gehört in eine Server-Konfig.

Der Server müsste allerdings diese Einträge haben, damit er das LAN beim Client auch an diesen zurückschicken kann. Der Server braucht dazu die Einträge in der Datei für den Client, die das bewirken.
Ich denke, in etwa müsste in dem Ordner, auf den das client-config-dir verweist, eine Datei mit dem "CN"-Namen des Clients im Zertifikat sein (heißt der "Client01" muss das in dem Ordner in der Datei "Client01" sein):

Sofern in dem Netz z.B. die 192.168.200.11 "frei" ist und 192.168.180.0 255.255.255.0 das LAN dort ist
Code:
ifconfig-push 192.168.200.11 255.255.255.0
route 192.168.180.0 255.255.255.0 192.168.200.11
push "topology subnet"
iroute 192.168.180.0 255.255.255.0
 
Zuletzt bearbeitet:

JokerGermany

Mitglied
Mitglied seit
7 Aug 2007
Beiträge
564
Punkte für Reaktionen
5
Punkte
18
Wo hast du denn die Änderung der GUI vorgenommen? Auf dem Client?!? Denn das "fehlerhafte" client-config-dir gehört in eine Server-Konfig.

Ähm, ja sry das hab ich zwischenzeitlich auch gemerkt gehabt, bloß vergessen das aus dem Post hier wieder raus zu8 löschen.

@client-config-dir:
Muss dafür eine Verbindung bestehen?
In dem Verzeichnis herrscht bei mir gähnende Leere...
Muss ich Ordner und Datei selbst erstelllen?
 

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Ja, es muss der Order angelegt werden (was du ja scheinbar schon hattest). Für deinen Anwendungsfall wäre dann in dem Ordner ein Datei für den Client erforderlich (genauer für jeden Client, wo ein Netz beim Client ist).

Beim Verbinden des Clients zum Server wird die Datei "angezogen", die exakt so heißt, wie der Name (CN) des Clients im Zertifikat ist (das, was vorher in der "erweiterten Clientkonfig" in der ersten Spalte stand).

Benötigter Inhalt dieser Text-Datei steht oben (IP für diesen Client, routing für den Linux-Kernel [route ... - Zeile] und Routing für den OpenVPN-Prozess [iroute ... Zeile]).
 

JokerGermany

Mitglied
Mitglied seit
7 Aug 2007
Beiträge
564
Punkte für Reaktionen
5
Punkte
18
Ok, da ich da ja die Route bestimmen muss die das Clientnetz (188) ins Servernetz (2) nimmt, müsste dann die Route so lauten:
Code:
ifconfig 192.168.200.3 255.255.255.0 route 192.168.2.0 255.255.255.0 192.168.200.3
push "topology subnet"
iroute 192.168.2.0 255.255.255.0

Stimmt das so?
 

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Ich denke, das ist falsch, denn das Netz 192.168.2.0 255.255.255.0 ist doch beim Server, oder? Das willst du ja sicher nicht zum Client routen...

Da muss auf jeden Fall das "Netz beim Client" rein.
Laut dem Log oben hätte ich auf das Netz
192.168.180.0 255.255.255.0 getippt...

Das Routing des Servers wird in dieser Datei beschrieben!

Die "push"-Befehle ( für das Routing beim Client) scheinen laut Log oben ja schon zu passen...
 
Zuletzt bearbeitet:

JokerGermany

Mitglied
Mitglied seit
7 Aug 2007
Beiträge
564
Punkte für Reaktionen
5
Punkte
18

Das Routing des Servers wird in dieser Datei beschrieben!

Die "push"-Befehle ( für das Routing beim Client) scheinen laut Log oben ja schon zu passen...

Ahso seltsam, aber das ich vom Clientnetz nicht ins Servernetz pingen kann, aber vielleicht kann ich das bloß die Antwort findet den weg nicht zurück...

Ich denke, das ist falsch, denn das Netz 192.168.2.0 255.255.255.0 ist doch beim Server, oder? Das willst du ja sicher nicht zum Client routen...
Da muss auf jeden Fall das "Netz beim Client" rein.
Laut dem Log oben hätte ich auf das Netz
192.168.180.0 255.255.255.0 getippt...
Ne, ist die 188

- - - Aktualisiert - - -

Danke, funktioniert, so ganz sauber sieht es aber nicht aus...
Server-FB
Code:
cat /var/tmp/debug_openvpn.out
Wed Mar 16 21:04:41 2016 OpenVPN 2.3.10 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [IPv6] built on Feb 26 2016
Wed Mar 16 21:04:41 2016 library versions: OpenSSL 1.0.1r  28 Jan 2016, LZO 2.09
Wed Mar 16 21:04:41 2016 Diffie-Hellman initialized with 2048 bit key
Wed Mar 16 21:04:41 2016 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Wed Mar 16 21:04:41 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 16 21:04:41 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 16 21:04:41 2016 Socket Buffers: R=[87380->87380] S=[16384->16384]
Wed Mar 16 21:04:41 2016 TUN/TAP device tun0 opened
Wed Mar 16 21:04:41 2016 TUN/TAP TX queue length set to 100
Wed Mar 16 21:04:41 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Mar 16 21:04:41 2016 /sbin/ifconfig tun0 192.168.200.1 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
Wed Mar 16 21:04:41 2016 /sbin/route add -net 192.168.188.0 netmask 255.255.255.0 gw 192.168.200.2
Wed Mar 16 21:04:41 2016 Listening for incoming TCP connection on [undef]
Wed Mar 16 21:04:41 2016 TCPv4_SERVER link local (bound): [undef]
Wed Mar 16 21:04:41 2016 TCPv4_SERVER link remote: [undef]
Wed Mar 16 21:04:41 2016 MULTI: multi_init called, r=256 v=256
Wed Mar 16 21:04:41 2016 IFCONFIG POOL: base=192.168.200.100 size=151, ipv6=0
Wed Mar 16 21:04:41 2016 MULTI: TCP INIT maxclients=9 maxevents=13
Wed Mar 16 21:04:41 2016 Initialization Sequence Completed
Wed Mar 16 21:04:46 2016 TCP connection established with [AF_INET]xxx.xx.x.xx:35649
Wed Mar 16 21:04:47 2016 xxx.xx.x.xx:35649 TLS: Initial packet from [AF_INET]xxx.xx.x.xx:35649, sid=b7ea7e1e d781394f
Wed Mar 16 21:04:50 2016 xxx.xx.x.xx:35649 VERIFY OK: depth=1, C=DE, ST=Niedersachsen, L=Wolfsburg, O=Internet Ltd., OU=MyOrganizationalUnit, CN=Internet Ltd. CA, name=Simon, emailAddress=JokerGermany
Wed Mar 16 21:04:50 2016 xxx.xx.x.xx:35649 VERIFY OK: depth=0, C=DE, ST=Nordrhein-Westfalen, L=blub, O=Internet Ltd., OU=MyOrganizationalUnit, CN=blub, name=Simon, emailAddress=JokerGermany
Wed Mar 16 21:04:51 2016 xxx.xx.x.xx:35649 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Mar 16 21:04:51 2016 xxx.xx.x.xx:35649 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 16 21:04:51 2016 xxx.xx.x.xx:35649 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Mar 16 21:04:51 2016 xxx.xx.x.xx:35649 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 16 21:04:51 2016 xxx.xx.x.xx:35649 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Mar 16 21:04:51 2016 xxx.xx.x.xx:35649 [blub] Peer Connection Initiated with [AF_INET]xxx.xx.x.xx:35649
Wed Mar 16 21:04:51 2016 blub/xxx.xx.x.xx:35649 OPTIONS IMPORT: reading client specific options from: /var/tmp/flash/openvpn/clients_openvpn/blub
Wed Mar 16 21:04:51 2016 blub/xxx.xx.x.xx:35649 Options error: option 'ifconfig' cannot be used in this context (/var/tmp/flash/openvpn/clients_openvpn/blub)
Wed Mar 16 21:04:51 2016 blub/xxx.xx.x.xx:35649 Options error: option 'route' cannot be used in this context (/var/tmp/flash/openvpn/clients_openvpn/blub)
Wed Mar 16 21:04:51 2016 blub/xxx.xx.x.xx:35649 MULTI_sva: pool returned IPv4=192.168.200.100, IPv6=(Not enabled)
Wed Mar 16 21:04:51 2016 blub/xxx.xx.x.xx:35649 MULTI: Learn: 192.168.200.100 -> blub/xxx.xx.x.xx:35649
Wed Mar 16 21:04:51 2016 blub/xxx.xx.x.xx:35649 MULTI: primary virtual IP for blub/xxx.xx.x.xx:35649: 192.168.200.100
Wed Mar 16 21:04:51 2016 blub/xxx.xx.x.xx:35649 MULTI: internal route 192.168.188.0/24 -> blub/xxx.xx.x.xx:35649
Wed Mar 16 21:04:51 2016 blub/xxx.xx.x.xx:35649 MULTI: Learn: 192.168.188.0/24 -> blub/xxx.xx.x.xx:35649

Was mich auch wundert: Warum zur Hölle nutzt er den Port 35649 und nicht 1194? oO

Das hier ist die Datei:
Code:
ifconfig 192.168.200.3 255.255.255.0
route 192.168.188.0 255.255.255.0 192.168.200.3
push "topology subnet"
iroute 192.168.188.0 255.255.255.0
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,913
Punkte für Reaktionen
1,296
Punkte
113
Da ist ja auch noch einiges durcheinander ... die Einträge für die Clients sollten eher "ifconfig-push" sein als "ifconfig" und irgendwie müßtest Du auch sehen, daß Du ja mit der "iroute" bereits die Route (über diesen Client) setzt und damit das "route"-Statement (das ja in der Protokoll-Datei auch "kritisiert" wird) vollkommen überflüssig ist. Wenn Du solch ein Statement tatsächlich brauchst, gehört das in die Serverkonfiguration und nicht in die eines einzelnen Clients. Ich vermute mal, da ist auch MaxMuster etwas durcheinander gekommen ... jedenfalls nach dem, was ich so beim OpenVPN verwende (ohne solche Fehlermeldungen).

Ansonsten kann ich die Verwunderung über den verwendeten Port auch nicht so richtig nachvollziehen ... die Client-Konfiguration in #1204 enthält doch gar keine "port"-Anweisung (auch kein lport - oder rport, wobei letzteres natülich nur für den Zielport gelten würde), damit nimmt der Client einen beliebigen und verbindet auf 1194 am Server. Was sollte er sonst machen?

Was mich schon die ganze Zeit als Frage plagt, seitdem diese Diskussion hier läuft ... gibt es einen speziellen Grund, warum Du da TCP für die OpenVPN-Verbindung verwendest?
 

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
... die Einträge für die Clients sollten eher "ifconfig-push" sein als "ifconfig" ...
Oops, latürnich, Asche über mein Haupt (und deswegen ist es gut, wenn man es erzeugen lässt... ;-))

Sollte also so aussehen:

Code:
ifconfig-push 192.168.200.3 255.255.255.0
route 192.168.188.0 255.255.255.0 192.168.200.3
push "topology subnet"
iroute 192.168.188.0 255.255.255.0

Hab es oben (für spätere Leser) auch nochmal korrigiert ...
 
Zuletzt bearbeitet:

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
678
Punkte für Reaktionen
4
Punkte
18
Hallo zusammen,

ich habe noch eine Box am Laufen mit ds26-15.1.
Die Box ist 300 km von mir entfernt und ist uralt, deshalb auch die uralt-fw.

Auf der Box läuft seit Jahr und Tag openvpn mit Zertifikaten, wobei die Serverbox bei mir zu Hause steht.
Die Konfiguration habe ich damals "zu Fuß" in der debug.cfg gemacht.

Aus Gründen, die hier keine Rolle spielen, möchte ich die Konfiguration jetzt im Webinterface des ds-mod machen.
Problem: man kann die Zertifikate und Keys nich im Webinterface eingeben.
Ich gehe davon aus, dass die einfach an der richtigen Stelle liegen müssen, damit die gefunden werden.
Ist das so?
Wenn ja, wohin muss ich die schreiben?
Wenn nein, wie muss ich sonst vorgehen?

Danke im Voraus und Gruß
maceis
 

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Warum kannst du sie in der GUI denn nicht eingeben? Falscher security-level?
Was ist die Fehlermeldung?

Also, für die "damalige" GUI müssten nach diesem openvpn_conf diese Pfade bei 26-15.1 gelten:
Code:
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key

Wenn du sie also dort ablegst und mittels "modsave" abspeicherst...
 

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
678
Punkte für Reaktionen
4
Punkte
18
Danke.
Die Verbindung klappt damit auf Anhieb.

Was jetzt noch nicht funktioniert, ist das routing.
Sollte eigentlich mit pull vom Server geholt werden.
Im Server Log steht auch drin, dass der client einen PUSH_REQUEST sendet, welcher vom Server auch beantwortet wird (SENT CONTROL ... PUSH_REPLY, route ....).
In der routing Tabelle des client steht aber nichts drin.

Wenn ich damit nicht klarkomme, würde ich mich noch mal melden.

Gruß
maceis

- - - Aktualisiert - - -

Um die Frage von Max Muster noch zu beantworten.
In der GUI gibt es in dieser version noch keine Eingabefelder für Zertifikat- und Key-files.

Hab aber auch nicht Probleme:
Die routes werden jetzt zwar gepusht, ich komme aber trotzdem nicht mit dem Webbrowser auf die entfernte IP der Box oder auf entfernte Rechner.
Woran kann das liegen?

Hier mal die beiden confs zum Vergleich:

1. alte conf mit debug.cfg
Code:
[FONT=Menlo]client
no-replay[/FONT]
[FONT=Menlo]pull[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo]dev tun[/FONT]
[FONT=Menlo]dev-node /var/tmp/tun[/FONT]
[FONT=Menlo]proto udp[/FONT]
[FONT=Menlo]remote homebox.my_domain.de 1194[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo]resolv-retry infinite[/FONT]
[FONT=Menlo]nobind[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo]persist-key[/FONT]
[FONT=Menlo]persist-tun[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo]ca /var/tmp/openvpn_cfg/ca.crt[/FONT]
[FONT=Menlo]cert /var/tmp/openvpn_cfg/remotebox.crt[/FONT]
[FONT=Menlo]key /var/tmp/openvpn_cfg/remotebox.key[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo]comp-lzo[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo]verb 3[/FONT]
[FONT=Menlo];mute 20[/FONT]
[FONT=Menlo]daemon[/FONT]

2. neue conf mit ds-mod
Code:
[FONT=Menlo]# OpenVPN 2.1 Config
proto udp[/FONT]
[FONT=Menlo]port 1194[/FONT]
[FONT=Menlo]dev tun[/FONT]
[FONT=Menlo]ca /tmp/flash/ca.crt[/FONT]
[FONT=Menlo]cert /tmp/flash/box.crt[/FONT]
[FONT=Menlo]key /tmp/flash/box.key[/FONT]
[FONT=Menlo]tls-client[/FONT]
[FONT=Menlo]ns-cert-type server[/FONT]
[FONT=Menlo]pull[/FONT]
[FONT=Menlo]remote homebox.my_domain.de[/FONT]
[FONT=Menlo]nobind[/FONT]
[FONT=Menlo]ifconfig 10.8.0.14 10.8.0.1[/FONT]
[FONT=Menlo]tun-mtu 1500[/FONT]
[FONT=Menlo]mssfix[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo]daemon[/FONT]
[FONT=Menlo]verb 3[/FONT]
[FONT=Menlo]
[/FONT]
[FONT=Menlo]cipher BF-CBC[/FONT]
[FONT=Menlo]comp-lzo[/FONT]
[FONT=Menlo]keepalive 10 120[/FONT]
[FONT=Menlo]resolv-retry infinite[/FONT]


Hat jemand eine Idee, warum ich mit der conf 1 in das entfernte Netz 192.168.102.0/24 pingen kann und die Box über den Webbrowser unter der entfernten IP 192.168.102.1 erreiche und mit der conf 2 nicht?

Wie gesagt, in beiden Fällen ist die Routing Tabelle identisch und die openvpn Verbindung steht.
Aufgefallen ist mir noch, dass mit conf 2 alle zwei Minuten ein PUSH_REQUEST von der remote (=client) box kommt.

Danke und Gruß
maceis
 
Zuletzt bearbeitet:

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Du hast mit der "alten" Config eine "ohne IP", die die IP vom Server holt.
In der GUI-Version eine "mit IP", die per pull "andere Sachen" holt.
Kann es daran liegen? Diese alte GUI ermöglicht es so nicht, "alles" vom Server zu holen.

GGf. kann man aber "tricksen", denn eine Config kann man auch über ein eigenes "Config-Gegerierungs-Skript" bauen lassen.

Ist denn auch die Routing-Tabelle beim Client identisch?!?
 

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
678
Punkte für Reaktionen
4
Punkte
18
Die Routing Tabelle beim Client ist identisch.
In der ds-mod GUI habe ich unter IP Adressen bei "Lokaler Endpunkt" die Adresse eingetragen, die vorher immer vom Server kam und unter "Entfernter Endpunkt (nur für TUN)" die IP Adresse des Severs. Das sind aber nicht die Adressen aus den 192.168.er Netzen sondern aus dem 10er Netz, die ich beim Server so konfiguriert habe:

Code:
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

In der Datei ipp.txt sind die Adressen der Clientboxen (u. a. eben auch der, um die es hier geht) fest eingetragen.
Ich dachte, damit sollte es ziemlich egal sein, ob die IP Adresse beim Client im GUI eingetragen ist oder vom Server gepusht wird.
Im Moment bin ich ziemlich ratlos.
 

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Ich vermute da das Problem. Nutzt der Server "topology subnet"?

Kannst du denn noch "anders" auf die Box, um da sonst zur Not weitere Änderungen vorzunehmen?

"Testen" könntest du erstmal "trocken", indem du im RAM eine geänderte Version des Konfigurations-Skriptes ablegst:

Code:
sed '/OPENVPN_BOX_IP \$OPENVPN_REMOTE_IP/ d' /etc/default.openvpn-lzo/openvpn-lzo_conf >  /tmp/myopenvpn_conf
chmod +x   /tmp/myopenvpn_conf

Schauen, ob das Ergebnis "gut aussieht":
Code:
 /tmp/myopenvpn_conf
Sollte die Config ohne "ifconfig" ausgeben. Wenn das so ist, kannst du mit der GUI testen
Code:
mount --bind /tmp/myopenvpn_conf /etc/default.openvpn-lzo/openvpn-lzo_conf
und dann nochmal starten.

Wenn das so funktioniert, kannst du diese Datei als "/tmp/flash/openvpn-lzo_conf" abspeichern (mit "modsave" resetfest machen).
 

maceis

Mitglied
Mitglied seit
9 Apr 2006
Beiträge
678
Punkte für Reaktionen
4
Punkte
18
Vielen Dank für Deine Bemühungen.
Auf die entfernte Box komme ich auch ohne VPN mit ssh, sonst könnte ich das gar nicht machen.

Das ist die Ausgabe:
Code:
# OpenVPN 2.1 Configproto udp
port 
dev tun
secret /tmp/flash/static.key
remote 
nobind
ifconfig  
tun-mtu 
mssfix


daemon
verb 


cipher

Die Zeile, die Du löschen willst, gibt es nicht (habe auch keine ähnliche gefunden).
Das ist aber auch nicht das Problem, denn wenn ich die Zeile "ifconig ..." in der config auskommentiere, funktioniert es auch nicht.

Grundsätzlich weiß ich jetzt auch, wie ich das ans Laufen bringen kann (nämlich indem ich meine "alte" config in den flash schreibe).
Das wäre schon mal ein Teilerfolg.


Mich nervt aber, wenn ich nicht verstehe, warum es nicht ohne Kopfstand funktioniert.
Die VPN Verbindung wird aufgebaut.
Es werden die selben IP Adressen wie vorher dem tun interface zugewiesen.
Die Routing Tabelle wird gepusht wie vorher.
Was kann da noch fehlen? *grübel*
 
Zuletzt bearbeitet:

MaxMuster

IPPF-Promi
Mitglied seit
1 Feb 2005
Beiträge
6,932
Punkte für Reaktionen
3
Punkte
38
Also, ein direkter Vergleich der Konfigs (mit Ausklammern der Standard-Werte ["cipher BF-CBC", "tun-mtu 1500"] und der "helper" ["client" ist ein "Helper" für die Befehle "pull" und "tls-client"]) zeigt diese Unterschiede:

Code:
ns-cert-type server
#
ifconfig 10.8.0.14 10.8.0.1
mssfix
keepalive 10 120
Also, diese "Möglichkeiten" gibt es:

- Das Zertifikat beim Server ist im Zertifikats-Sinne kein "Server-Zertifikat"
- Es liegt an der IP
- Die TCP-Anpassung dürfte m.E. keine Rolle spielen
- der "keepalive" mit dem timeout 120 Sekunden sorgt vermutlich für die periodischen "Neuanfragen" nach 2 Minuten, hat aber wohl keinen Einfluss auf das Routing

Könnte es daran liegen, dass die Verbindung wegen "falscher" Zertifikats-Einstellung gar nicht komplett aufgebaut wird?
Sonst sehe ich nichts, wenn es mit "auskommentierter" ifconfig-Zeile auch nicht geht...


Bei der "zu löschenden Zeile" geht es nicht um die erzeugte Config, sondern um das Skript, dass die Erzeugung der Config vornimmt.
Der "sed"-Befehl soll einfach die Erzeugung der "ifconfig"-Zeile aus "/etc/default.openvpn-lzo/openvpn-lzo_conf" herausnehmen
Code:
[...]
114    
115        if [ "$OPENVPN_LZO_TYPE" == "tun" ]; then
116            echo "ifconfig $OPENVPN_LZO_BOX_IP $OPENVPN_LZO_REMOTE_IP"
117        else
118            if [ "$OPENVPN_LZO_DHCP_CLIENT" != "yes" ]; then
119                echo "ifconfig $OPENVPN_LZO_BOX_IP $OPENVPN_LZO_BOX_MASK"
120            fi
121        fi
122
[...]
Die Zeile 116 sollte mit dem Befehl oben "getilgt" werden, so dass eine Config ohne "ifconfig"-Zeile entsteht...


Du kannst als "Generierungs-Skript" auch ganz simpel
Code:
cat </Pfad/zu/deinem/alten-Skript>
# also z.B. cat /tmp/flash/myopenvpn.config
nutzen. Dann werden alle Einträge in der GUI ignoriert, nur das "automatische oder manuelle" Starten bzw. ein Restart wirkt noch...
 
Zuletzt bearbeitet:

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

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.
oder via