[Gelöst] Freetz-OpenVPN startet nicht

[colonia27]

Hallo zusammen,

seit einiger Zeit habe ich jetz schon das OpenVPN-Paket mit Freetz-devel in meine Box gebaut. Mittlerweile auch als "External" auf nem USB-Stick.
Alles auf Basis der aktuellen AIO-13014.
Das alles findet ihr auch in meiner Sig. bzw. in den Anhängen.

Die Serverseitige Config:

#  OpenVPN 2.1 Config, Mon Nov 24 13:34:02 CET 2008
proto tcp-server
dev tun
secret /tmp/flash/static.key
port 1194
ifconfig 10.0.0.1 10.0.0.2
tun-mtu 1500
mssfix
verb 3
daemon
cipher AES-128-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn.log

und die Client-Seite:

ifconfig 10.0.0.2 10.0.0.1
remote xxxyyyzzz.dyndns.org                                           
secret C:\\Programme\\OpenVPN\\config\\static.key                       

dev tun
proto tcp-client
port 443

# ping 15
# ping-restart 300 # 5 minutes
# resolv-retry 300 # 5 minutes
# resolv-retry infinite

#route 10.0.0.0 255.255.0.0
#route 192.168.78.0 255.255.255.0
#http-proxy 10.20.10.10 8080
#push "route 10.0.0.0 255.255.255.0"
#push "dhcp-option DNS 10.0.0.1"
#route-gateway 10.0.0.1
#redirect-gateway

tun-mtu 1500
mssfix
cipher AES-128-CBC
comp-lzo
keepalive 10 120
persist-tun
persist-key
verb 5

Leider klappt das Starten des OVPN-Dienstes nicht mehr über die Sart-/Stop-Buttons im Web-IF.

Ausgabe der Prozesse nach Start:

ps
  PID USER       VSZ STAT COMMAND
    1 root      1180 S    init       
    2 root         0 SWN  [ksoftirqd/0]
    3 root         0 SW   [watchdog/0]
    4 root         0 SW<  [events/0]
    5 root         0 SW<  [khelper]
    6 root         0 SW<  [kthread]
   18 root         0 SW<  [kblockd/0]
   33 root         0 SW   [pdflush]
   34 root         0 SW<  [kswapd0]
   35 root         0 SW<  [aio/0]
   71 root         0 SW   [pm_info]
   75 root         0 SW<  [CPMAC]
   79 root         0 SW   [mtdblockd]
  101 root         0 SW   [tffsd_mtd_0]
  192 root         0 SW   [cleanup_timer_f]
  362 root         0 SWN  [jffs2_gcd_mtd5]
  424 root         0 SW<  [capi_oslib]
  425 root         0 SW<  [capi_oslib]
  426 root         0 SW   [capitransp]
  433 root         0 SW   [glob_codecs]
  437 root         0 SW   [avm_dect_thread]
  454 root         0 SW<  [khubd]
  521 root      8148 S N  /usr/bin/avm/ctlmgr 
  701 root      8148 S N  /usr/bin/avm/ctlmgr 
  703 root      8148 S N  /usr/bin/avm/ctlmgr 
  705 root      8148 S N  /usr/bin/avm/ctlmgr 
  805 root         0 SW<  [scsi_eh_0]
  806 root         0 SW<  [usb-storage]
  820 root      2920 S    igdd 
  855 root      2460 S    multid -t 
  876 root      3084 S    dsld -i -n 
  887 root      5284 S    telefon a127.0.0.1 
  893 root      4628 S <  voipd 
  896 root      2324 S    pbd 
  897 root      2324 S    pbd 
  902 root      2324 S    pbd 
  903 root      2324 S    pbd 
  905 root      1180 S    /usr/sbin/inetd 
  926 root      5284 S    telefon a127.0.0.1 
  927 root      5284 S    telefon a127.0.0.1 
  928 root      5284 S    telefon a127.0.0.1 
  935 root      2324 S    dect_manager 
  938 root       776 S    /bin/run_clock -c /dev/tffs -d 
  951 root      2376 S    /usr/bin/faxd -a 
 1042 root         0 SW<  [loop0]
 1062 root      1180 S    httpd -P /var/run/webcfg.pid -p 81 -c /mod/etc/httpd.
 1109 root         0 SW<  [loop1]
 1115 root      1196 S    syslogd -L -C 
 1117 root      1180 S    /sbin/klogd -c 4 
 1141 root      1188 S    /bin/sh /usr/bin/spindown sda 900 3 
 1155 root         0 SW<  [loop2]
 1180 root         0 SW<  [loop3]
 1275 root      2920 S    igdd 
 1276 root      2920 S    igdd 
 1277 root      2920 S    igdd 
 1363 root      5284 S    telefon a127.0.0.1 
 1364 root      5284 S    telefon a127.0.0.1 
 1365 root      5284 S    telefon a127.0.0.1 
 1374 root         0 RWN  [kdsld_token]
 1450 root      9300 S <  /var/media/ftp/uStor02/webtransmission_1.34_v2.1.1/tr
 1479 root      9300 S <  /var/media/ftp/uStor02/webtransmission_1.34_v2.1.1/tr
 1480 root      9300 S <  /var/media/ftp/uStor02/webtransmission_1.34_v2.1.1/tr
 1533 root      1296 S    dropbear -p 22 
 1602 root      1088 S    /sbin/chronyd -f /var/tmp/chrony.conf 
 1705 root      1180 S    init       
 5306 root      1056 S    vsftpd 
13484 root      2780 S    hostapd -B /var/tmp/hostapd_topology-ath0 
13559 root         0 SW   [pdflush]
14746 root      1356 R    dropbear -p 22 
14747 root      1208 S    -sh 
[COLOR="Red"]15490 root      1460 S    openvpn --config /mod/etc/openvpn.conf --writepid /va[/COLOR]
15606 root      1176 S    sleep 60 
15610 root      1180 R    ps 
/var/mod/home #

denke mein Problem liegt in der markierten Zeile.

Der manuelle Start auf der console funktioniert,

cat /mod/etc/openvpn*.conf | grep -v daemon > /var/tmp/ovpn.conf
openvpn /var/tmp/ovpn.conf &

und läßt mich dann auch eine VPN-Verbindung aufbauen.

Leider weiß ich nicht wo ich mit der Fehlersuche anfangen könnte. Die SuFu hier, konnte mir auch nicht helfen. Was nicht heißen soll, daß die Lösung doch evtl. irgendwo hier vergraben ist.

Grüße,
Guido

 

[MaxMuster]

Könntest du das "klappt das Starten des OVPN-Dienstes nicht mehr" etwas genauer beschreiben? Lt. der Prozessliste läuft der Dienst doch (deine rote Markierung)???

Jörg

 

[colonia27]

Das der Dienst nicht ordentlich gestartet ist, schließe ich daraus, daß ich keine VPN-Verbindung aufbauen kann.

nach dem wie oben erwähnten manuellem Start, sieht der Prozess so aus:

...
...
16035 root      1456 S    openvpn /var/tmp/ovpn.conf
...
...

und ich kann eine Verbindung aufbauen

 

[MaxMuster]

Wenn in der GUI der Dienst als gestartet steht (und auch in der Prozessliste vorkommt) ist er zunächst mal auch gestartet. ;-)

Der start "von Hand" nutzt auch komplett die identische Konfiguration nur das "in den Hintergund schieben" wird rausgefiltert.

Allerdings solltest du die angegebene Zeile nur absetzen können, nachdem du vorher den Dienst gestoppt hast?!?

Schau doch mal, wenn der Dienst über die GUI gestartet wurde in der Datei "/var/log/openvpn.log" nach, ob da was drinsteht oder mache mal den Haken beim "Debug-Mode", dann solltest du den Start (oder mögliche Probleme) ablesen können in "/var/tmp/debug_openvpn.out"


Jörg

 

[colonia27]

Allerdings solltest du die angegebene Zeile nur absetzen können, nachdem du vorher den Dienst gestoppt hast?!?

war auch so. hab vorher alles mit openvpn "gekillt".

Allerdings komme ich mir gerade ziemlich lächerlich vor, weil es jetzt ohne Probleme funktioniert... auch reproduzierbar funktioniert.
Letztendlich muß das Problem also wieder nicht in der Box, sondern nen halben Meter davor zu suchen sein.
:-Ö
Bis hierhin also schonmal vielen Dank.

So einfach mach ichs dir jetzt aber dann trotzdem nicht.
Die VPN nutze ich hier und da auch mal im Büro. Um allerdings auch über meine private I-Net-Verbindung zu surfen, muß ich in der Server.conf ja das Gateway (also meine Box) "pushen".
Bisher habe ich das immer manuell über ssh in der .conf eingetragen und anschliessend die VPN gestartet.
Überseh ich den Punkt im Web-IF, oder lässt sich das mit meiner Variante nicht konfigurieren?
siehe Scrennshot in #1

 

[MaxMuster]

Das "pushen" geht eigentlich nur mit Zertifikaten, dann gibt es den Punkt "Clientverkehr umleiten", der die Option "redirect-gateway" pushed, wenn es das ist, was du meinst?

Jörg

 

[colonia27]

genau das wars was ich meinte. Dann muß ich wohl demnächst doch mal auf Zertifikate umsteigen. Hab ich nur bisher vermieden, da ich eh nur einen Client habe der eine VPN aufbauen soll.

Also werd ich hier mal zumachen, da mein nichtvorhandenes Problem gelöst ist.
Geh jetzt raus nen Schneemann bauen, zum Frustabbau. :blonk:

Trotzdem vielen Dank für die Mühe und noch nen guten Wochenstart.

Guido

 

[MaxMuster]

Kein Problem ;-)
BTW: Das "redirect-gateway" könntest du aber auch direkt in der Client-Config verankern, dafür brauchst du keine Zertifikate...

Jörg

 

[colonia27]

Darauf würde ich morgen nochmal zurückkommen wenns recht ist.
Bin dann im Büro und würd das mal testen.

Also wenn du magst kannste den Thread ja noch weiterhin abonnieren ;-)

 

[matze1985]

einfach

redirect-gateway

in deiner Client-Config hinzufügen.

 

[hermann72pb]

gehen da auch andere Sachen auf ähnliche Weise? Z.B. redirect-dns (ich spekuliere mal). Ich hatte mal ähnliche Situation wie colonia27 gehabt, wo mir Zertifikate eine Nummer zu groß waren. Ich hatte mich irgendwie daran gewöhnt immer mit IPs zu arbeiten. Oder geht DNS vom Grundsatz nicht, weil es über UDP läuft?

MfG

 

[colonia27]

einfach

redirect-gateway

in deiner Client-Config hinzufügen.

Auch das habe ich mal probiert, ohne Erfolg.
Die "surferei" lief dann immer noch über das Firmennetz.
Ist es nicht so, daß ich dafür in der sever.conf das gateway auch pushen muß? Also:

push "redirect-gateway"

So hat es dann jedenfalls wie in #5 erwähnt auch funktioniert.

 

[MaxMuster]

Das wäre interessant, da mal nachzuschauen. Denn eigentlich trägt auch ein "push" das ja nur auf der Gegenseite ein...
Überhaupt scheint das bei dir anders als in (meiner) Theorie zu sein ;-): Eigentlich geht push/pull nur im Server Mode funktioniert, der wiederum Zertifikate benötigt. Dann sollte der Client auch nur Optionen empfangen, wenn "pull" in der Konfig steht.....

Wenn du den Parameter in deiner Client Config hast: Wie verändert sich den dann die Routingtabelle (vor/nach dem Verbinden)?

Jörg

 

[colonia27]

Das werd ich dann mal alles genau durchspielen und berichten.
Allerdings doch nicht heute, da ich nur kurz im Büro sein werde.
Und heut abend gehts ins Stadion die Bayern anfeuern. :-D