OpenVPN-Paket

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Hi Jörg,

freut mich, dass wir zum gleichen Schluss kommen. Ich habe mir heute morgen die 2.1er Man-page genau angesehen und kam zum gleichen Schluss wie Du. Die topology ist definitiv das Problem und muss auf Subnet gestellt werden.

ich werde im laufe des Mittags hoffentlich dazu kommen eine funktionierende Config zu bauen (Das ist mein Ehrgeiz) und anschließend Dein Script testen. Wenn dann Dein Script genau die Konfig liefert, die ich vorher gebastelt habe, sind wir uns einig ;)

wengi

EDIT 14:40 Uhr
Hier mal eine funktionierende Server-Config:
Code: 
# OpenVPN 2.1 Config
# Config for TUN multi-client Server by wengi
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem

mode server
tls-server
topology subnet

ifconfig 10.0.0.1 255.255.255.0
ifconfig-pool 10.0.0.2 10.0.0.254 255.255.255.0
route-gateway 10.0.0.1
route 10.0.0.0 255.255.255.0
route 192.168.202.0 255.255.255.0
route 192.168.203.0 255.255.255.0

client-config-dir /var/tmp/ovpn

push "topology subnet"
push "route-gateway 10.0.0.1"
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
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
Jetzt wird Jörgs Script getestet.

EDIT 15:00 Uhr

Hilfe! Wie passe ich die openvpn-lzo.cgi an ???

EDIT 15:15 Uhr

Noch eine Frage:
openvpn-lzo.cfg -> sind Voreinstellungen
openvpn-lzo.cgi -> ist das Webinterface
openvpn-lzo_conf -> erstellt die .conf in Echtzeit
rc.openvpn-lzo -> FRAGE: Ist das normale RC-Script für OpenVPN? Und warum muss das angepasst werden?
 
Zuletzt bearbeitet:
Was willst du denn anpassen??
Wenn du die Originalversion mit der im RAM "überdeckt" hast (mount -o bind /var/tmp/openvpn-lzo.cgi /usr/lib/cgi-bin/openvpn-lzo.cgi) kannst du die Version im /var/tmp einfach mit einem vi editieren, das ist dann quasi das CGI, was die WebGUI nutzt...


Jörg
 
Code: 
mount -o bind /var/tmp/openvpn-lzo.cgi /usr/lib/cgi-bin/openvpn-lzo.cgi
Das hat mir gefehlt. Das steht zwar schon mal in diesem Thread, ich habs aber nicht gefunden :rolleyes:

EDIT: Webinterface meldet "Fehler: Kein Skript für das Paket 'openvpn-lzo'." Ein "cat /usr/lib/cgi-bin/openvpn-lzo.cgi" zeigt mir aber den Inhalt Deiner Datei. ???? Ich bin zu blöd. Nach einem umount gehts wieder mit dem Alten....

EDIT2: Doch nicht blöd. Der chmod +x hat gefehlt :)
 
Zuletzt bearbeitet:
Sorry, deine Nachfragen habe ich jetzt erst gesehen:
wengi schrieb:
openvpn-lzo.cfg -> sind Voreinstellungen
openvpn-lzo.cgi -> ist das Webinterface
openvpn-lzo_conf -> erstellt die .conf in Echtzeit
rc.openvpn-lzo -> FRAGE: Ist das normale RC-Script für OpenVPN? Und warum muss das angepasst werden?
Zum Vergrößern anklicken....

Ja,
Ja,
Ja,
Weil ich die "openvpn-lzo_conf" umgemodelt habe. Früher wurde die so aufgerufen und die Ausgabe in die .conf Datei geschoben (also letztlich /Pfad/zur/openvpn-lzo_conf > /mod/etc/openvpn-lzo.conf) .
Das fand ich etwas "ungeschickt" weil ich z.B. keine Kommentare ausgeben konnte sondern die auch in der Config landeten (oder ich hätte sie als Fehler ausgeben müssen oder so) und deshalb habe ich das so umgebaut, dass die "Umleitung" in der openvpn-lzo_conf erfolgt. Dafür rufe ich die Datei mit dem Parameter der Zieldatei auf (also /Pfad/zur/openvpn-lzo_conf /mod/etc/openvpn-lzo.conf). Dieser minimal geänderte Aufruf steht da drin. Ich habe aber als "Sicherheit" abgefragt, ob es einen Parameter gibt, ansonsten gebe ich halt auf dem "Standardpfad" aus, so dass es auch mit dem alten Script klappen sollte, solange ich nichts zusätzliches ausgebe...


wengi schrieb:
Der chmod +x hat gefehlt :)
Zum Vergrößern anklicken....
Hatte ich das falsch gepackt, oder hast du es evtl under Windows entpackt?!?

Jörg
 
Hi,

ich habe jetzt Deine Dateien benutzt. Allerdings wäre ich Dir für eine kurze Anleitung dankbar, da ich nicht genau weis, welche dateien überschrieben werden müssen :confused: Ich habe jetzt einfach alle vorhandenen Dateien mit identischem Namen "übermountet".

Das Ergebnis:
Code: 
/var/tmp $ cat /mod/etc/openvpn-lzo.conf
##############################################################
#
#  OpenVPN 2.1 Config, generated Fri Aug 10 10:46:19 CEST 2007
#
##############################################################
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
server 192.168.200.0 255.255.255.0
client-config-dir /var/tmp/ovpn
topology subnet
max-clients  2
push "route 192.168.201.1 255.255.255.0 192.168.200.1"
route 192.168.202.0  255.255.255.0  192.168.200.2
route 192.168.203.0  255.255.255.0  192.168.200.3
route 192.168.203.0  255.255.255.0  192.168.200.4
route 192.168.204.0  255.255.255.0  192.168.200.5
route 192.168.205.0  255.255.255.0  192.168.200.6
tun-mtu 1500
mssfix
daemon
verb 3
cipher AES-128-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
/var/tmp $
/var/tmp $
/var/tmp $
/var/tmp $ ls -la /var/tmp/ovpn
drwxr-xr-x    2 root     root            0 Aug 10 10:46 .
drwxr-xr-x    6 root     root            0 Aug 10 10:46 ..
-rw-r--r--    1 root     root          120 Aug 10 10:46 client202
-rw-r--r--    1 root     root          122 Aug 10 10:46 client203
-rw-r--r--    1 root     root          122 Aug 10 10:46 client3
-rw-r--r--    1 root     root          122 Aug 10 10:46 client4
-rw-r--r--    1 root     root          122 Aug 10 10:46 client5
/var/tmp $
/var/tmp $ 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
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
192.168.201.0   *               255.255.255.0   U     0      0        0 lan
192.168.200.0   *               255.255.255.0   U     0      0        0 tun0
192.168.203.0   192.168.200.4   255.255.255.0   UG    0      0        0 tun0
192.168.203.0   192.168.200.3   255.255.255.0   UG    0      0        0 tun0
192.168.202.0   192.168.200.2   255.255.255.0   UG    0      0        0 tun0
192.168.205.0   192.168.200.6   255.255.255.0   UG    0      0        0 tun0
192.168.204.0   192.168.200.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
/var/tmp $
Erläuterung:
Ich habe versucht die VPN-IPs auf 10.0.0.x umzustellen. Das wird im Moment immer auf 192.168.200.x zurückgesetzt...

Auch wenn nur zwei Clients ausgewählt wurden (Client202 und Client 203) werden die restliche 3 Clients dennoch in der Config eingefügt. Dementsprechend werden die Routen falsch gesetzt.

Also habe ich das mal manuell umgebaut:
Code: 
/var/tmp/ovpn $ cat /var/tmp/openvpn-lzo.conf
##############################################################
#
#  OpenVPN 2.1 Config, generated Fri Aug 10 10:46:19 CEST 2007
#
##############################################################
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
server 192.168.200.0 255.255.255.0
client-config-dir /var/tmp/ovpn
topology subnet
max-clients  2
push "route 192.168.201.1 255.255.255.0 192.168.200.1"
route 192.168.202.0  255.255.255.0  192.168.200.2
route 192.168.203.0  255.255.255.0  192.168.200.3
tun-mtu 1500
mssfix
daemon
verb 3
cipher AES-128-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log
/var/tmp/ovpn $
/var/tmp $
/var/tmp $ 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
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
10.0.0.0        *               255.255.255.0   U     0      0        0 tun0
192.168.201.0   *               255.255.255.0   U     0      0        0 lan
192.168.203.0   10.0.0.3        255.255.255.0   UG    0      0        0 tun0
192.168.202.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 $
Der Routingbereich im WebIF ("Entferntes Netzwerk:") ist in dieser Konstellation übrigens hinfällig, da Du die entfernten Netze ja bei der Client-Config angibst.

Die Option "Clients dürfen untereinader kommunizieren" im Webinterface ändert nichts an der conf Datei. Laut 2.1er manpage müsste da die Option "--client-to-client" rein, oder?

Deine Änderungen sind schon ein riesiger Schritt in die richtige Richtung. Vielen Dank! :)
wengi

PS: Ich hab mir gerade alles nochmal angesehen und habe die restlichen Routen entdeckt. Also passt ja alles.
 
Zuletzt bearbeitet:
Hi,

das mit den Routen liegt an der Abfrage in der "Config-Erstell-Script", dort frage ich nur ab, ob in dem "Netz für den Client was drin steht". Ist natürlich blöd, besser wenn ich die "Anzahl" abfrage, das sollte zu machen sein.

Das "Client-to-Client" ändert doch was (sollte es zumindest)! In der "Ursprungsversion" macht das nichts weiter, als das Netz, was für die Tunnel benutzt wird, an die Clients zu schicken. Das ist aber in unserem Fall nicht ausreichend, denn (zumindest interpretire ich das so) in diesem Szenario sollen sich die Client-Netze gegenseitig sehen. Also wird (dass kannst du ja mal checken) in den Client-Configs im "client-config-dir" an die Clients jeweils alle Netze der anderen Clients gepushed (momentan (s.o.) natürlch noch mit allen Netzen, solange da was dirnsteht, das ist aber in der gleichen Abfrage und wird dann "mitkorrigiert").

Das mit dem Ändern der IP prüfe ich mal. Eventuell frage ich da eine falsche Variable ab...

Jörg
 
Auf der Clientseite gibt es anscheinend auch noch ein Problem.
Code: 
Aug 10 13:55:46 fritz daemon.notice openvpn[1746]: OpenVPN 2.1_rc4 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jul  9 2007
Aug 10 13:55:46 fritz daemon.warn openvpn[1746]: WARNING: using --pull/--client and --ifconfig together is probably not what you want
Aug 10 13:55:46 fritz daemon.warn openvpn[1746]: WARNING: file '/tmp/flash/box.key' is group or others accessible
Aug 10 13:55:46 fritz daemon.notice openvpn[1746]: LZO compression initialized
Aug 10 13:55:46 fritz daemon.notice openvpn[1746]: Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Aug 10 13:55:46 fritz daemon.notice openvpn[1746]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Aug 10 13:55:46 fritz daemon.notice openvpn[1748]: Socket Buffers: R=[110592->131072] S=[110592->131072]
Aug 10 13:55:46 fritz daemon.notice openvpn[1748]: UDPv4 link local: [undef]
Entfernen von ifconfig auf der Clientseite (In der Hoffnung, er würde die ifconfig vom Server bezihen) geht auch in die Hose.
 
Das sieht so aus, als erreiche der Client den Server nicht. Bei mir sieht das so aus:

Code: 
/var/mod/root # cat /mod/etc/openvpn-lzo.conf
##############################################################
#
#  OpenVPN 2.1 Config, generated Thu Aug  9 11:18:12 CEST 2007
#
##############################################################
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
remote xxxxxx yyyyy
nobind
pull
ifconfig 192.168.200.1 192.168.200.2
tun-mtu 1500
mssfix
#daemon
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite


/var/mod/root # openvpn --config /mod/etc/openvpn-lzo.conf
Fri Aug 10 17:34:36 2007 OpenVPN 2.1_rc2 mipsel-linux [SSL] [LZO2] built on May 29 2007
Fri Aug 10 17:34:36 2007 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Fri Aug 10 17:34:36 2007 WARNING: file '/tmp/flash/box.key' is group or others accessible
Fri Aug 10 17:34:36 2007 LZO compression initialized
Fri Aug 10 17:34:36 2007 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Aug 10 17:34:36 2007 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Aug 10 17:34:36 2007 Socket Buffers: R=[65535->65534] S=[32767->65534]
Fri Aug 10 17:34:36 2007 UDPv4 link local: [undef]
Fri Aug 10 17:34:36 2007 UDPv4 link remote: a.b.c.d:xy
Fri Aug 10 17:34:36 2007 TLS: Initial packet from a.b.c.d:xy, sid=8a1d8e17 5569c772
Fri Aug 10 17:34:41 2007 VERIFY OK: depth=1, xxxxxxxxxxxxxxxxxxxx
Fri Aug 10 17:34:41 2007 VERIFY OK: nsCertType=SERVER
Fri Aug 10 17:34:41 2007 VERIFY OK: depth=0, xxxxxxxxxxx
Fri Aug 10 17:34:48 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Aug 10 17:34:48 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 10 17:34:48 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Aug 10 17:34:48 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 10 17:34:48 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Aug 10 17:34:48 2007 [myserver] Peer Connection Initiated with 87.123.169.141:22188
Fri Aug 10 17:34:49 2007 SENT CONTROL [myserver]: 'PUSH_REQUEST' (status=1)
Fri Aug 10 17:34:49 2007 PUSH: Received control message: 'PUSH_REPLY,route 10.10.25.0 255.255.255.0 192.168.222.1,route-gateway 192.168.222.1,topology subnet,ping 10,ping-restart 120,route 192.168.202.0 255.255.255.0 192.168.222.3 ,ifconfig 192.168.222.2 255.255.255.0'
Fri Aug 10 17:34:49 2007 OPTIONS IMPORT: timers and/or timeouts modified
Fri Aug 10 17:34:49 2007 OPTIONS IMPORT: --ifconfig/up options modified
Fri Aug 10 17:34:49 2007 OPTIONS IMPORT: route options modified
Fri Aug 10 17:34:49 2007 OPTIONS IMPORT: route-related options modified
Fri Aug 10 17:34:50 2007 TUN/TAP device tun0 opened
Fri Aug 10 17:34:50 2007 TUN/TAP TX queue length set to 100
Fri Aug 10 17:34:50 2007 /sbin/ifconfig tun0 192.168.222.2 netmask 255.255.255.0 mtu 1500 broadcast 192.168.222.255
Fri Aug 10 17:34:50 2007 /sbin/route add -net 10.10.25.0 netmask 255.255.255.0 gw 192.168.222.1
Fri Aug 10 17:34:50 2007 /sbin/route add -net 192.168.202.0 netmask 255.255.255.0 gw 192.168.222.3
Fri Aug 10 17:34:50 2007 Initialization Sequence Completed


/var/mod/root # ifconfig
[...]
tun0      Link encap:Point-to-Point Protocol
          inet addr:192.168.222.2  P-t-P:192.168.222.2  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:48 (48.0 B)  TX bytes:228 (228.0 B)

/var/mod/root # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.178.0   *               255.255.255.0   U     0      0        0 lan
10.10.25.0    192.168.222.1   255.255.255.0   UG    0      0        0 tun0
192.168.202.0   192.168.222.3   255.255.255.0   UG    0      0        0 tun0
192.168.9.0     *               255.255.255.0   U     0      0        0 lan
192.168.222.0   *               255.255.255.0   U     0      0        0 tun0
default         10.10.11.1      0.0.0.0         UG    9      0        0 lan

Ansonsten gibt es später eine neuere Version, in die deine Anregungen und der entdeckte Fehler eingeflossen sind...

Jörg
 
Zuletzt bearbeitet:
... wie "versprochen" noch was fürs Wochenende ;-)

Ich glaube, so langsam "kann es sich sehen lassen".

Jörg

EDIT 2007-08-11 Noch ein Fehler im Skript, ins Client-File wurde "push-ifconfig" statt "ifconfig-push" geschrieben.
Die GUI habe ich nochmal angepasst (man gibt jetzt doch die IP des Servers ein, nicht das Netz, das fand ich zu "unüblich").
Außerdem habe ich einen "Debug" Punkt eingefügt. Bei dem kann man ein "echtes" logfile wählen und "verb" verändern.
Da die GUI-Eingabe sich doch recht stark verändert habe, lasse ich das "alte" File noch drin, falls jemand die vergleichen will kann er mir ja sagen, welches besser/schöner ist ;-)
EDIT 2007-08-12 Oops, und noch ein Fehler entdeckt. Die gestrige Version nochmal etwas bereinigt (Hat kein "topology subnet" gepushed, Vorschlag für Client-IPs war falsch, wenn die Server-IP im letzten Oktett nicht einstellig war)
 

Anhänge

  • ovpn_20070810.tar.gz
    7.3 KB · Aufrufe: 6
  • ovpn_20070812.tar.gz
    7.7 KB · Aufrufe: 11
Zuletzt bearbeitet:
Hi,

mal ein Bericht mit Deiner neuesten Version vom 12.08.
Zur Erinnerung:
192.168.200.x ist das VPN Netz.
192.168.201.x ist das Netz des Servers
192.168.202.x ist der erste Client (Zertifikatname: Client202)
192.168.203.x ist der zweite Client (Zertifikatname: Client203)

Auf allen Boxen lege ich die Dateien in /var/tmp/flash ab. Danach führe ich folgendes aus, um die Dateien zu "aktivieren":
Code: 
mount -o bind /var/tmp/flash/rc.openvpn-lzo /etc/init.d/rc.openvpn-lzo
mount -o bind /var/tmp/flash/openvpn-lzo.cgi /usr/lib/cgi-bin/openvpn-lzo.cgi
mount -o bind /var/tmp/flash/openvpn-lzo.cfg /etc/default.openvpn-lzo/openvpn-lzo.cfg
mount -o bind /var/tmp/flash/openvpn-lzo.cfg /var/mod/etc/conf/openvpn-lzo.cfg
mount -o bind /var/tmp/flash/openvpn-lzo_conf /etc/default.openvpn-lzo/openvpn-lzo_conf
Prinzipiell sollte das doch stimmern, oder? (voll die Newbie-Frage :confused:)
Danach konfiguriere ihc über das Webinterface.
Auf dem Server sieht alles gut aus. Die erzeugte Conf inkl. client-Dir:
Code: 
/var/tmp $ cat /mod/etc/openvpn-lzo.conf
##############################################################
#
#  OpenVPN 2.1 Config, generated Mon Aug 13 10:32:28 CEST 2007
#
##############################################################
proto udp
port 1194
dev tun
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
ifconfig 192.168.200.1 255.255.255.0
mode server
client-config-dir /var/tmp/ovpn
topology subnet
max-clients  2
push "route 192.168.201.0 255.255.255.0 192.168.200.1"
route 192.168.202.0 255.255.255.0 192.168.200.2
route 192.168.203.0 255.255.255.0 192.168.200.3
tun-mtu 1500
mssfix
log /var/tmp/openvpn-debug.out
daemon
verb 6
cipher AES-128-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log

/var/tmp/ovpn $ cat client202
ifconfig-push 192.168.200.2 192.168.200.1
push "topology subnet"
iroute  192.168.202.0 255.255.255.0
push "route 192.168.203.0 255.255.255.0 192.168.200.3 "

/var/tmp/ovpn $ cat client203
ifconfig-push 192.168.200.3 192.168.200.1
push "topology subnet"
iroute  192.168.203.0 255.255.255.0
push "route 192.168.202.0 255.255.255.0 192.168.200.2 "
/var/tmp/ovpn $
der Server läuft.

Jetzt noch die Config des Clients (hier Client203):
Code: 
/var/tmp/flash $ cat /mod/etc/openvpn-lzo.conf
##############################################################
#
#  OpenVPN 2.1 Config, generated Mon Aug 13 10:36:07 CEST 2007
#
##############################################################
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
remote yyyyyy.dyndns.org
nobind
pull
ifconfig 192.168.200.3 192.168.200.1
tun-mtu 1500
mssfix
log /var/tmp/openvpn-debug.out
daemon
verb 6
cipher AES-128-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log
/var/tmp/flash $
Allerdings erhalte ich im Log am Client Folgendes:
Code: 
/var/tmp $ cat openvpn-debug.out
Mon Aug 13 10:36:07 2007 us=406053 OpenVPN 2.1_rc4 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jul  9 2007
Mon Aug 13 10:36:07 2007 us=408759 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Mon Aug 13 10:36:07 2007 us=424820 WARNING: file '/tmp/flash/box.key' is group or others accessible
Mon Aug 13 10:36:07 2007 us=440150 LZO compression initialized
Mon Aug 13 10:36:07 2007 us=445519 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Aug 13 10:36:07 2007 us=616480 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Aug 13 10:36:07 2007 us=625092 Socket Buffers: R=[110592->131072] S=[110592->131072]
Mon Aug 13 10:36:07 2007 us=626292 UDPv4 link local: [undef]
Mon Aug 13 10:36:07 2007 us=627205 UDPv4 link remote: 84.177.50.123:1194
Mon Aug 13 10:36:07 2007 us=634382 UDPv4 WRITE [14] to 84.177.50.123:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Mon Aug 13 10:36:07 2007 us=815970 UDPv4 READ [26] from 84.177.50.123:1194: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Mon Aug 13 10:36:07 2007 us=816943 TLS: Initial packet from 84.177.50.123:1194, sid=77e12fc7 c42c06f9
Mon Aug 13 10:36:07 2007 us=818444 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 0 ]
Mon Aug 13 10:36:07 2007 us=822256 UDPv4 WRITE [100] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=86
Mon Aug 13 10:36:08 2007 us=244811 UDPv4 READ [126] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ 1 ] pid=1 DATA len=100
Mon Aug 13 10:36:08 2007 us=248285 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 1 ]
Mon Aug 13 10:36:08 2007 us=252271 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Mon Aug 13 10:36:08 2007 us=254182 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 2 ]
Mon Aug 13 10:36:08 2007 us=256345 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=100
Mon Aug 13 10:36:08 2007 us=258246 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 3 ]
Mon Aug 13 10:36:08 2007 us=261315 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Mon Aug 13 10:36:08 2007 us=263211 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 4 ]
Mon Aug 13 10:36:08 2007 us=314182 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Mon Aug 13 10:36:08 2007 us=317293 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 5 ]
Mon Aug 13 10:36:08 2007 us=320425 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=100
Mon Aug 13 10:36:08 2007 us=322765 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 6 ]
Mon Aug 13 10:36:08 2007 us=325464 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Mon Aug 13 10:36:08 2007 us=327362 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 7 ]
Mon Aug 13 10:36:08 2007 us=329526 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Mon Aug 13 10:36:08 2007 us=332579 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 8 ]
Mon Aug 13 10:36:08 2007 us=345972 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=100
Mon Aug 13 10:36:08 2007 us=348843 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 9 ]
Mon Aug 13 10:36:08 2007 us=352002 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=10 DATA len=100
Mon Aug 13 10:36:08 2007 us=354486 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 10 ]
Mon Aug 13 10:36:08 2007 us=357157 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=11 DATA len=100
Mon Aug 13 10:36:08 2007 us=359053 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 11 ]
Mon Aug 13 10:36:08 2007 us=361708 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=12 DATA len=100
Mon Aug 13 10:36:08 2007 us=364199 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 12 ]
Mon Aug 13 10:36:08 2007 us=369624 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=13 DATA len=100
Mon Aug 13 10:36:08 2007 us=372894 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 13 ]
Mon Aug 13 10:36:08 2007 us=375416 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=14 DATA len=100
Mon Aug 13 10:36:08 2007 us=377313 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 14 ]
Mon Aug 13 10:36:08 2007 us=380740 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=15 DATA len=100
Mon Aug 13 10:36:08 2007 us=382643 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 15 ]
Mon Aug 13 10:36:08 2007 us=385309 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=16 DATA len=100
Mon Aug 13 10:36:08 2007 us=387201 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 16 ]
Mon Aug 13 10:36:08 2007 us=393769 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=17 DATA len=100
Mon Aug 13 10:36:08 2007 us=396230 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 17 ]
Mon Aug 13 10:36:08 2007 us=398889 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=18 DATA len=100
Mon Aug 13 10:36:08 2007 us=425443 VERIFY OK: depth=1, /C=DE/ST=HE/L=yyyyy/O=wengi/CN=CA/[email protected]
Mon Aug 13 10:36:08 2007 us=432730 VERIFY OK: nsCertType=SERVER
Mon Aug 13 10:36:08 2007 us=433188 VERIFY OK: depth=0, /C=DE/ST=HE/O=wengi/CN=server201/[email protected]
Mon Aug 13 10:36:08 2007 us=435903 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 18 ]
Mon Aug 13 10:36:08 2007 us=438134 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=19 DATA len=100
Mon Aug 13 10:36:08 2007 us=440555 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 19 ]
Mon Aug 13 10:36:08 2007 us=442730 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=20 DATA len=100
Mon Aug 13 10:36:08 2007 us=445266 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 20 ]
Mon Aug 13 10:36:08 2007 us=447439 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=21 DATA len=100
Mon Aug 13 10:36:08 2007 us=449352 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 21 ]
Mon Aug 13 10:36:08 2007 us=458335 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=22 DATA len=100
Mon Aug 13 10:36:08 2007 us=468035 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 22 ]
Mon Aug 13 10:36:08 2007 us=470651 UDPv4 READ [73] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=23 DATA len=59
Mon Aug 13 10:36:09 2007 us=89258 UDPv4 WRITE [126] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ 23 ] pid=2 DATA len=100
Mon Aug 13 10:36:09 2007 us=92562 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=100
Mon Aug 13 10:36:09 2007 us=94813 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Mon Aug 13 10:36:09 2007 us=97059 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Mon Aug 13 10:36:09 2007 us=182655 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 2 ]
Mon Aug 13 10:36:09 2007 us=185284 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=100
Mon Aug 13 10:36:09 2007 us=187985 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 3 ]
Mon Aug 13 10:36:09 2007 us=189653 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Mon Aug 13 10:36:09 2007 us=192321 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 4 ]
Mon Aug 13 10:36:09 2007 us=194405 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Mon Aug 13 10:36:09 2007 us=197068 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 5 ]
Mon Aug 13 10:36:09 2007 us=198659 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=100
Mon Aug 13 10:36:09 2007 us=314288 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 6 ]
Mon Aug 13 10:36:09 2007 us=316461 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=10 DATA len=100
Mon Aug 13 10:36:09 2007 us=318619 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 7 ]
Mon Aug 13 10:36:09 2007 us=320933 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=11 DATA len=100
Mon Aug 13 10:36:09 2007 us=323101 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 8 ]
Mon Aug 13 10:36:09 2007 us=325256 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=12 DATA len=100
Mon Aug 13 10:36:09 2007 us=327407 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 9 ]
Mon Aug 13 10:36:09 2007 us=328978 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=13 DATA len=100
Mon Aug 13 10:36:09 2007 us=338859 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 10 ]
Mon Aug 13 10:36:09 2007 us=341334 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=14 DATA len=100
Mon Aug 13 10:36:09 2007 us=344505 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 11 ]
Mon Aug 13 10:36:09 2007 us=346063 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=15 DATA len=100
Mon Aug 13 10:36:09 2007 us=349241 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 12 ]
Mon Aug 13 10:36:09 2007 us=351275 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=16 DATA len=100
Mon Aug 13 10:36:09 2007 us=353793 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 13 ]
Mon Aug 13 10:36:09 2007 us=355340 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=17 DATA len=100
Mon Aug 13 10:36:09 2007 us=362252 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 14 ]
Mon Aug 13 10:36:09 2007 us=364364 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=18 DATA len=100
Mon Aug 13 10:36:09 2007 us=367431 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 15 ]
Mon Aug 13 10:36:09 2007 us=368970 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=19 DATA len=100
Mon Aug 13 10:36:09 2007 us=372671 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 16 ]
Mon Aug 13 10:36:09 2007 us=374206 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=20 DATA len=100
Mon Aug 13 10:36:09 2007 us=376907 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 17 ]
Mon Aug 13 10:36:09 2007 us=378423 UDPv4 WRITE [103] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=21 DATA len=89
Mon Aug 13 10:36:09 2007 us=416944 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 18 ]
Mon Aug 13 10:36:09 2007 us=681555 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 19 ]
Mon Aug 13 10:36:09 2007 us=686387 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 20 ]
Mon Aug 13 10:36:09 2007 us=706711 UDPv4 READ [85] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ 21 ] pid=24 DATA len=59
Mon Aug 13 10:36:09 2007 us=712823 UDPv4 WRITE [126] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ 24 ] pid=22 DATA len=100
Mon Aug 13 10:36:09 2007 us=714609 UDPv4 WRITE [114] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=23 DATA len=100
Mon Aug 13 10:36:09 2007 us=716950 UDPv4 WRITE [16] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=24 DATA len=2
Mon Aug 13 10:36:09 2007 us=736899 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 22 ]
Mon Aug 13 10:36:09 2007 us=739055 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 23 ]
Mon Aug 13 10:36:09 2007 us=758329 UDPv4 READ [126] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ 24 ] pid=25 DATA len=100
Mon Aug 13 10:36:09 2007 us=761109 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 25 ]
Mon Aug 13 10:36:09 2007 us=764435 UDPv4 READ [68] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=26 DATA len=54
Mon Aug 13 10:36:09 2007 us=772379 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Aug 13 10:36:09 2007 us=773064 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Aug 13 10:36:09 2007 us=773689 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Aug 13 10:36:09 2007 us=774289 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Aug 13 10:36:09 2007 us=775312 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 26 ]
Mon Aug 13 10:36:09 2007 us=776953 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Aug 13 10:36:09 2007 us=777786 [server201] Peer Connection Initiated with 84.177.50.123:1194
Mon Aug 13 10:36:10 2007 us=891077 SENT CONTROL [server201]: 'PUSH_REQUEST' (status=1)
Mon Aug 13 10:36:10 2007 us=892711 UDPv4 WRITE [104] to 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=25 DATA len=90
Mon Aug 13 10:36:10 2007 us=934652 UDPv4 READ [22] from 84.177.50.123:1194: P_ACK_V1 kid=0 [ 25 ]
Mon Aug 13 10:36:10 2007 us=937627 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=27 DATA len=100
Mon Aug 13 10:36:10 2007 us=940611 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 27 ]
Mon Aug 13 10:36:10 2007 us=942873 UDPv4 READ [114] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=28 DATA len=100
Mon Aug 13 10:36:10 2007 us=944099 UDPv4 WRITE [22] to 84.177.50.123:1194: P_ACK_V1 kid=0 [ 28 ]
Mon Aug 13 10:36:10 2007 us=945898 UDPv4 READ [64] from 84.177.50.123:1194: P_CONTROL_V1 kid=0 [ ] pid=29 DATA len=50
Mon Aug 13 10:36:10 2007 us=948172 PUSH: Received control message: 'PUSH_REPLY,route 192.168.201.0 255.255.255.0 192.168.200.1,ping 10,ping-restart 120,topology subnet,route 192.168.202.0 255.255.255.0 192.168.200.2 ,ifconfig 192.168.200.3 192.168.200.1'
Mon Aug 13 10:36:10 2007 us=949274 OPTIONS IMPORT: timers and/or timeouts modified
Mon Aug 13 10:36:10 2007 us=950200 OPTIONS IMPORT: --ifconfig/up options modified
Mon Aug 13 10:36:10 2007 us=950662 OPTIONS IMPORT: route options modified
Mon Aug 13 10:36:10 2007 us=964696 TUN/TAP device tun0 opened
Mon Aug 13 10:36:10 2007 us=965353 TUN/TAP TX queue length set to 100
Mon Aug 13 10:36:10 2007 us=966071 /sbin/ifconfig tun0 192.168.200.3 netmask 192.168.200.1 mtu 1500 broadcast 255.255.255.255
ifconfig: SIOCSIFNETMASK: Invalid argument
Mon Aug 13 10:36:11 2007 us=44393 Linux ifconfig failed: shell command exited with error status: 1
Mon Aug 13 10:36:11 2007 us=44917 Exiting
/var/tmp $
Log am Server hänge ich als Datei an. Ist für den Beitrag zu lang.

Der Tunnel wird also aufgebaut.
Der Client hat aber ein Problem das Interface zu erstellen.
Hier stimmt allerdings die Netmask nicht:
Code: 
/sbin/ifconfig tun0 192.168.200.3 netmask 192.168.200.1 mtu 1500 broadcast 255.255.255.255
Da es sich um eine Push-Option handelt tippe ich auf die Server-Config.
Die Zeile mit dem "ifconfig-push" Befehl wird in den Client Dateien (hier /var/tmp/ovpn/client203) nicht richtig erzeugt. Ich hab das auf dem Server mal geändert:
Code: 
/var/tmp $ cat /var/tmp/ovpn/client203
ifconfig-push 192.168.200.3 255.255.255.0
push "topology subnet"
iroute  192.168.203.0 255.255.255.0
push "route 192.168.202.0 255.255.255.0 192.168.200.2 "
/var/tmp $
Jetzt klappts auch mit dem Nachbarn :)

In der openvpn-lzo_conf , Zeile 144, liegt wohl der Fehler:
Code: 
echo "ifconfig-push $ip $OPENVPN_LZO_BOX_IP"  > $CCD/$name
Leider weis ich nicht, ob einfach nur die Netmask reinnehmen "sauber" genug ist.
Wenn Ja, dann:
Code: 
echo "ifconfig-push $ip $mask"  > $CCD/$name


wengi

PS: Die Zeiten der Boxen sind genau synchron. Das Problem tritt laut Logs genau um 10:36:11 Uhr auf.
 

Anhänge

  • openvpn-debug.out.txt
    43.6 KB · Aufrufe: 3
Zuletzt bearbeitet:
Hi,

danke fürs Testen. Ja, da hast du genau den Bug lokalisiert. In meiner "alten Version" (siehe mein Log oben) habe ich wohl auch noch korrekter Weise ein "ifconfig <ip> <mask>" geschickt und das nun falsch gemacht :-(, aber es gibt ja beherzte Tester ;-)

Ich nehme es mal mit auf für ein Bug-Fix ...

Jörg

Ist übrigens ganz witzig, erst will man nicht dran (sondern es andere machen lassen), dann versucht man das immer "besser"/Userfreundlicher zu machen, obwohl es momentan in der ganzen Zeit "nur" (nix für ungut) einen User gibt, der das benötigt hat.
Aber zumindest habe ich noch ein paar Dinge in Shell-Skripting mitbekommen und erste Erfahrungen mit javascript gesammelt. Ist ja schonmal was !
 
Um das hier mal klar zu sagen:

100% der Personen, die das benötigen, sind Dir WIRKLICH DANKBAR ;)

ich hatte anfangs nur gehofft, das Ganze zum Laufen zu bringen. Dass jetzt alles schön über das WebIF geht und später evtl. im ds-mod landen wird ist natürlich die absolute Krönung!

Vielen Dank.

wengi
 
Dhcp / Dns

Hallo,

ich muss jetzt mal halb offtopic werden, aber irgendwie ist die Frage hier doch gut aufgehoben...

<offtopic>
Nachdem nun meine Netze mit tunneln verbunden sind kommt natürlich das nächste Problem: DNS
Meine Idee:
Ich möchte jedem Netz eine Top Level Domain (TLD) geben. Z.B. .netz1 .netz2 und .netz3.
Dazu muss auf jeder Box ein DNS Server laufen, der Folgendes kann:
- eine eigene TLD verwalten.
- Auflösung der lokalen DHCP- und statischen Adressen.
- Weiterleitung der anderen 'privaten' TLDs an den entsprechenden DNS Server.
- Weiterleitung der 'restlichen' Anfragen an den DNS des Providers.

Bekommt das der integrierte DNS Server/Proxy hin?
Wenn nicht: Bekommt das dnsmasq hin?
</offtopic>

EDIT: Laut Wiki ist dnsmasq wohl meine Wahl. Aber das mit den Weiterleitungen zum entsprechenden DNS muss wohl noch getestet werden. Ich glaub ich schreib mal ein HowTo wenn ich mit dem ganzen Kram fertig bin.

EDIT2: Laut dieser Seite kann er es wohl: "Dnsmasq can be configured to send queries for certain domains to upstream servers handling only those domains. This makes integration with private DNS systems easy."

Hat jemand Gegenvorschläge?

Danke
wengi
 
Zuletzt bearbeitet:
Ich hätte da noch eine minimale Verbesserung:

Wenn das Debug-Log im Webinterface ausgeschaltet wird sollte auch die Logdatei gelöscht werden.
Das ist im Moment nicht der Fall und belegt somit nur unnötig Speicher (unter der Annahme, dass der User die Datei auch in den Speicher legt).

wengi
PS: Bin gerade dabei dnsmasq zu testen.
 
... gute Idee. Ich bin gerade dabei, das ganze nochmal "neu" zu schreiben, so dass es zumindest für mich besser nachvollziehbar ist (wann das cgi welche Optionen Ein- und Ausblendet, noch ein bisschen "Zusatzhilfe" zum Vorbelegen, keine Beschränkung auf 5 Clients ). Dauert aber noch ein wenig. Jetzt kann ich noch "Wünsche" mit aufnehmen...


Jörg
 
Na wenn ich mir was wünschen darf bin ich doch sofort dabei!

Als ich das erste mal das Webinterface von OpenVPN gesehen habe war ich ziemlich verwirrt. Ich wusste nicht immer ob eine "normale" oder eine VPN-IP eingetragen werden musste.
daher würde ich vorschlagen immer ein "VPN" mit in die Beschreibung einzubauen, wenn eine IP des VPN Netzes gemeint ist.

Ich hab das hier mal exemplarisch für den VPN Server gemacht.

Das "auch" ergibt nur die Frage: Wofür denn noch? Und darauf habe zumindest ich keine Antwort.

wengi
 

Anhänge

  • VPN_WebIF.JPG
    VPN_WebIF.JPG
    64.3 KB · Aufrufe: 26
Ich hab noch einen Wunsch. Sicherlich nicht umwerfend schwierig, aber dafür um so aufwendiger...

Mehrere Konfigurationen parallel, z.B. 3x Client Modus zu 3 verschiedenen Servern, oder 1x Server, 1x Client, usw.

Im Prinzip ähnlich, wie auch bei inadyn, wo man mehrere Konfigurationen parallel betreiben kann.
 
Diese Frage hatte ich auch schon auf den ... ähhh ... Tasten.
Der VPN Server soll immer mit den anderen beiden Netzen verbunden sein.
Dennoch möchte ich mit meinem Notebook über UMTS auch ans VPN angebunden sein.

wengi
 
@knox: Meinst du unterschiedliche "Profile" (mit denen man bequem zwischen Konfigs umschalten kann) oder das Starten mehrerer Instanzen von OpenVPN? Das erstere ist vermutlich machbar (nur wegen der Speicherung der Einstellung über Umgebungsvariablen vermutlich etwas auffwendig), bei dem zweiten hätte ich schon mehr Bedenken, zum einen wegen der Ressourcen, zum anderen, wie diese dann "auseinanderhaltbar" sein sollten (wenn du z.B. dem dritten Server eine neue Konfig verpassen willst).

@wengi: Das sollte doch aber auch jetzt schon möglich sein, wenn du deinem Notebook ein Zertifikat und eine entsprechende Konfig mitgibst, kann der sich doch anmelden. Oder habe ich da noch was verpasst??

Jörg
 
Das habe ich noch nicht getestet.
Als lokales Client-Netz würde man dann ein "/32 Netzwerk" angeben?

Ich werde es bei Gelegenheit testen.

wengi
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 838 (Mitglieder: 29, Gäste: 809)

Neueste Beiträge

Statistik des Forums

Themen
246,149
Beiträge
2,246,947
Mitglieder
373,668
Neuestes Mitglied
petzbär
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück