adm999
Goto Top

Autostart (Debian) funktioniert nicht

Hallo Forum,

habe ein kleines Problem mit dem Raspberry Pi 2 (OSMC),
Per SSH habe ich über das System (Debian) OpenVPN installiert und die VPN-Verbindung funktioniert, diese lasse ich per Autostart starten.

Wenn man das Gerät vom Strom getrennt wird, wird keine VPN-Verbindung mehr hergestellt wenn das Gerät wieder eingeschaltet wird.
Hier muss man manuel die Verbindung herstellen und bei jedem weiteren Neustart funktioniert es - nur nicht bei einer Stromtrennung.

Autostart über update-rc.d
#!/bin/sh
### BEGIN INIT INFO
# Provides:          OpenVPN
# Required-Start:    
# Required-Stop:     
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Stellt eine OpenVPN-Verbindung her 
# Description:       
### END INIT INFO
 
# Actions
case "$1" in  
    start)
       openvpn /etc/openvpn/client.conf
        ;;
    stop)
        # STOP
        ;;
    restart)
       openvpn /etc/openvpn/client.conf
        ;;
esac
 
exit 0

Wo habe ich einen gemacht Fehler?

Content-Key: 273977

Url: https://administrator.de/contentid/273977

Ausgedruckt am: 29.03.2024 um 13:03 Uhr

Mitglied: Arano
Arano 07.06.2015 um 15:25:56 Uhr
Goto Top
Hi adm999,

Was steht denn in solch einem Fall in dem OpenVPN.log-File.
Meine letzte OpenVPN Konfiguration ist jetzt schon ein paar Jahre her
Über die Konfigurations-Datei lässt sich auch das Loglevel einstellen, das könnte man für die Fehlerbehebung auch erhöhen.

Könnte mir vorstellen, das OpenVPN sein eigenes PID-File finden und dann behauptet es würde bereits laufen und ein erneuter Start somit nicht nötig ist.
Wo hingegen bei einem Neustart durch das "Prozessbeenden-Signal" und der Beendigung von OpenVPN das PID-File ordnungsgemäß gelöscht wird und somit ein sauberes Starten möglich ist.

Das dürfte sich aber auch im Logfile wiederfinden.

Ich kann mich aber auch daran erinnern, das sich OpenVPN über die Konsole starten lässt OHNE in den Hintergrund zu wechseln. So das man sämtliche Ausgaben direkt angezeigt bekommt satt im Log zu landen nehme ich mal an.


~Arano
Mitglied: 16568
16568 07.06.2015 um 15:39:52 Uhr
Goto Top
Wie wäre es, das RICHTIG einzurichten?

Entsprechendes Runlevel?


Lonesome Walker
Mitglied: adm999
adm999 07.06.2015 um 15:50:00 Uhr
Goto Top
@Arano - Wo finde ich die Logs?

@16568 - Welcher Fehler liegt im Runlevel?
Mitglied: Arano
Arano 07.06.2015 um 15:58:11 Uhr
Goto Top
Hallo...

steht in der Config-Datei face-wink
  status /var/log/openvpn-status.log
  #log /tmp/openvpn.log
  verb 3
Vielleicht musst du es auch erst einkommentieren.
Dann aber auch darauf achten das OpenVPN die nötigen Rechte hat die Log-Datei zu erstellen.

Mit verb kann man die "Geschwätzigkeit" des Loggens einstellen.


~Arano
Mitglied: 16568
16568 07.06.2015 um 17:29:23 Uhr
Goto Top
Zitat von @adm999:
@16568 - Welcher Fehler liegt im Runlevel?

Die Runlevel selbst sind i.O.

WO liegt Dein Script?
Und required start haste auch vergessen...

Normalerweise liefert OpenVPN doch entsprechende Scripte mit...?


Lonesome Walker
Mitglied: orcape
orcape 07.06.2015 um 18:08:08 Uhr
Goto Top
Normalerweise liefert OpenVPN doch entsprechende Scripte mit...?
Richtig, und da bei Ihm der Client läuft, wird der automatisch eine Verbindung initiieren, wenn er die Möglichkeit dazu hat.
Es liegt also hier definitiv ein Fehler in der Config vor, die wir aber leider nicht kennen.
Der TO sollte die Verbindung einmal händisch mit...
openvpn /etc/openvpn/client.conf
...starten und die Ausgabe posten.
Gruß orcape
Mitglied: adm999
adm999 07.06.2015 um 21:42:17 Uhr
Goto Top
client
dev tun
persist-tun
persist-key
ping 5
ping-exit 30
nobind
comp-lzo adaptive
remote-random
ns-cert-type server
route-metric 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
remote 176.227.198.122
proto udp
Mitglied: Arano
Arano 07.06.2015 um 21:55:12 Uhr
Goto Top
Ähm...

die Ausgabe des Logs wäre trotzdem schön !
Der TO sollte die Verbindung einmal händisch mit...
openvpn /etc/openvpn/client.conf
...starten und die Ausgabe posten.


Ich weiß nicht ob es wirklich an der Konfig liegt, denn nach deiner Beschreibung funktioniert es im Normalbetrieb ja !
Also:
  1. OpenVpn starten,
  2. RasPi vom Strom ziehen,
  3. wieder verbinden,
  4. per SSH drauf,
  5. openVpn-Befehl (s.oben) ausführen und
  6. dessen Ausgabe hier posten.


~Arano
Mitglied: orcape
orcape 08.06.2015 um 08:55:08 Uhr
Goto Top
Also:
OpenVpn starten,
RasPi vom Strom ziehen,
wieder verbinden,
per SSH drauf,
openVpn-Befehl (s.oben) ausführen und
dessen Ausgabe hier posten.
..genauso.
Auch mal die Ausgabe von route -n.
In der Client.config.....
- remote 176.227.198.122 (hier fehlt der Port, z.B. 1194)
Hier mal das Bsp. einer Client.conf....
client
dev tun
proto udp
remote 79.183.69.66 1196       # statische Server-IP + VPN-Port
resolv-retry infinite
nobind
persist-key
persist-tun
tun-mtu 1432
ca /etc/openvpn/ca.crt              # Pfad zu den Zertifikaten
cert /etc/openvpn/client.crt        #
key /etc/openvpn/client.key       #
ns-cert-type server
comp-lzo
verb 3
Gruß orcape
Mitglied: adm999
adm999 08.06.2015 um 16:48:26 Uhr
Goto Top
Vielen Dank erstmal für die zahlreiche Unterstützung!

Habe nach dieser Anleitung die OpenVPN-Verbindung automatisiert und hergestellt.
Einmal verbunden im laufenden Betrieb läuft die OpenVPN-Verbindung auch nach einem Neustart; NUR beim Auschalten (vom Strom trennen)

Konfigurationsdatei in /etc/openvpn/VPN.conf
client
dev tun
persist-tun
persist-key
ping 5
ping-exit 30
nobind
comp-lzo adaptive
remote-random
ns-cert-type server
route-metric 1

route -n
status /var/log/openvpn-status.log 
log /tmp/openvpn.log 
verb 3

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
remote uk.vpnunlimitedapp.com 1194
proto udp

Status in /var/log/openvpn-status.log
Mon Jun  8 16:24:13 2015 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
Mon Jun  8 16:24:13 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
Mon Jun  8 16:24:13 2015 Socket Buffers: R=[163840->131072] S=[163840->131072]
Mon Jun  8 16:24:13 2015 UDPv4 link local: [undef]
Mon Jun  8 16:24:13 2015 UDPv4 link remote: [AF_INET]88.150.180.82:1194
Mon Jun  8 16:24:13 2015 TLS: Initial packet from [AF_INET]88.150.180.82:1194, sid=3711bef7 b695c21d
Mon Jun  8 16:24:13 2015 VERIFY OK: depth=1, C=US, ST=NY, L=New York, O=Simplex Solutions Inc., OU=Vpn Unlimited, CN=server.vpnunlimitedapp.com, name=server.vpnunlimitedapp.com, emailAddress=support@simplexsolutionsinc.com
Mon Jun  8 16:24:13 2015 VERIFY OK: nsCertType=SERVER
Mon Jun  8 16:24:13 2015 VERIFY OK: depth=0, C=US, ST=NY, L=New York, O=Simplex Solutions Inc., OU=Vpn Unlimited, CN=openvpn.vpnunlimitedapp.com, name=openvpn.vpnunlimitedapp.com, emailAddress=support@simplexsolutionsinc.com
Mon Jun  8 16:24:14 2015 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jun  8 16:24:14 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jun  8 16:24:14 2015 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jun  8 16:24:14 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jun  8 16:24:14 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Jun  8 16:24:14 2015 [openvpn.vpnunlimitedapp.com] Peer Connection Initiated with [AF_INET]88.150.180.82:1194
Mon Jun  8 16:24:16 2015 SENT CONTROL [openvpn.vpnunlimitedapp.com]: 'PUSH_REQUEST' (status=1)
Mon Jun  8 16:24:16 2015 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.200.0.1,reneg-sec 0,rcvbuf 262144,sndbuf 262144,ping 5,ping-exit 30,route 10.200.0.1,topology net30,ifconfig 10.200.54.38 10.200.54.37'
Mon Jun  8 16:24:16 2015 Options error: option 'reneg-sec' cannot be used in this context ([PUSH-OPTIONS])
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Mon Jun  8 16:24:16 2015 Socket Buffers: R=[131072->327680] S=[131072->327680]
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: route options modified
Mon Jun  8 16:24:16 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Jun  8 16:24:16 2015 ROUTE_GATEWAY 192.168.0.2/255.255.255.0 IFACE=eth0 HWADDR=b8:27:eb:13:c6:49
Mon Jun  8 16:24:16 2015 RESOLVE: Cannot resolve host address: -n: No address associated with hostname
Mon Jun  8 16:24:16 2015 OpenVPN ROUTE: failed to parse/resolve route for host/network: -n
Mon Jun  8 16:24:16 2015 TUN/TAP device tun0 opened
Mon Jun  8 16:24:16 2015 TUN/TAP TX queue length set to 100
Mon Jun  8 16:24:16 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Jun  8 16:24:16 2015 /sbin/ip link set dev tun0 up mtu 1500
Mon Jun  8 16:24:16 2015 /sbin/ip addr add dev tun0 local 10.200.54.38 peer 10.200.54.37
Mon Jun  8 16:24:16 2015 /sbin/ip route add 88.150.180.82/32 via 192.168.0.2
Mon Jun  8 16:24:16 2015 /sbin/ip route add 0.0.0.0/1 via 10.200.54.37
Mon Jun  8 16:24:16 2015 /sbin/ip route add 128.0.0.0/1 via 10.200.54.37
Mon Jun  8 16:24:16 2015 /sbin/ip route add 10.200.0.1/32 via 10.200.54.37 metric 1
Mon Jun  8 16:24:16 2015 Initialization Sequence Completed

Log in /tmp/openvpn.log
OpenVPN STATISTICS
Updated,Mon Jun  8 16:35:14 2015
TUN/TAP read bytes,2280
TUN/TAP write bytes,2280
TCP/UDP read bytes,15149
TCP/UDP write bytes,15096
Auth read bytes,4248
pre-compress bytes,0
post-compress bytes,0
pre-decompress bytes,0
post-decompress bytes,0
END
Mitglied: orcape
orcape 08.06.2015 aktualisiert um 17:51:41 Uhr
Goto Top
route -n hat nichts in der OpenVPN Client.conf zu suchen.
Du solltest mir nur mal Dein Routing-Protokoll des Raspi zeigen. face-wink
Das kannst Du also getrost wieder entfernen.
Gruß orcape
Mitglied: orcape
orcape 08.06.2015 um 17:56:32 Uhr
Goto Top
Kleiner Nachtrag....
Falls Du irgendwann mal Probleme mit der Datenübertragung hast und ein Teil Deiner Pakete verworfen werden...
Mon Jun 8 16:24:16 2015 /sbin/ip link set dev tun0 up mtu 1500
...dann liegt das an der MTU-Größe.
Hatte ich Dir aber schon in einem Deiner letzten Threads gepostet...face-wink
- tun0 up mtu 1500
MTU 1500 solltest Du reduzieren, das kann (muss nicht) zu Problemen führen.
Gruß orcape
Mitglied: adm999
adm999 08.06.2015 um 18:14:43 Uhr
Goto Top
> - tun0 up mtu 1500
> MTU 1500 solltest Du reduzieren, das kann (muss nicht) zu Problemen führen.

Stimmt; welcher Wert wäre hier angebracht?

Aus welchem Grund verliert Debian/Raspberry Pi die Autostartinformationen?
Mitglied: orcape
orcape 08.06.2015 um 19:12:34 Uhr
Goto Top
Stimmt; welcher Wert wäre hier angebracht?
..das kommt auch auf die Art Deiner Verbindung an, aber MTU 1432 ist ein guter Wert.
Bei mir musste ich nach einer technischen Änderung durch den Provider noch unter 1400 gehen, weil ich oberhalb noch Paketverlust hatte.
Du musst das aber nicht allein auf dem Client ändern, Server nicht vergessen.
Aus welchem Grund verliert Debian/Raspberry Pi die Autostartinformationen?
...kann ich Dir so nicht sagen.
Normalerweise sind bei Debian die Zertifikate und Keys unter /etc/openvpn in einzelnen Files zu finden.
In der client.conf wird nur der Pfad zu diesen eingetragen.
Fährst Du einen Multiclienttunnel oder ist das ein einzelner Tunnel, würde man an Hand der Server.conf sehen.
Auch route -n in der Konsole eingegeben, würde da schon näheres erklären.face-wink
Gruß orcape
Mitglied: adm999
adm999 08.06.2015 um 23:41:02 Uhr
Goto Top
Die Werte in Konfigurationsdatei sind von einem VPN-Anbieter; bin nur Kunde.
Bzgl. Multi Client Tunnel liegt leider ausserhalb meiner Wissensbereiches, da ich keinen Zugriff auf den Server habe.

Route -n bei einer bestehenden OpenVPN-Verbindung
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.200.54.45    128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.0.2     0.0.0.0         UG    0      0        0 eth0
10.200.0.1      10.200.54.45    255.255.255.255 UGH   1      0        0 tun0
10.200.54.45    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.200.54.45    128.0.0.0       UG    0      0        0 tun0
176.227.198.122 192.168.0.2     255.255.255.255 UGH   0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.2     0.0.0.0         255.255.255.255 UH    0      0        0 eth0

Warum ausgerechnet verliert der Raspberry Pi/Debian Wheezy bei Stromverlust die VPN-Autostart-Funktion teilweise aber das restliche System läuft Störungsfrei? Seltsam..
Mitglied: orcape
orcape 09.06.2015 um 09:19:58 Uhr
Goto Top
Die Werte in Konfigurationsdatei sind von einem VPN-Anbieter; bin nur Kunde.
Damit klärt sich zwar nicht Dein Problem, aber einiges.
Das hättest Du schon mal gleich posten sollen, ist für mich aber nun auch an Hand der Routingtabelle klar.
Somit kannst Du auch eine Änderung der MTU-Größe vergessen, da diese vom Provider auf dem Server vorgegeben wird.
Wenn Du die Vorgabe des Providers zur Einrichtung des Tunnels richtig umgesetzt hast, sollte das auch funktionieren.
Ich würde an Deiner Stelle mal beim Tunnel-Provider nachhaken.
Gruß orcape
Mitglied: adm999
adm999 09.06.2015 aktualisiert um 11:22:13 Uhr
Goto Top
Normalerweise sind bei Debian die Zertifikate und Keys unter /etc/openvpn in einzelnen Files zu finden.
In der client.conf wird nur der Pfad zu diesen eingetragen.
Ist es wirklich ratsam diese auszulagern oder nur eine Empfehlung?

Damit klärt sich zwar nicht Dein Problem, aber einiges.
Das hättest Du schon mal gleich posten sollen, ist für mich aber nun auch an Hand der Routingtabelle klar.
Mein Versehen; Kritik angenommen und wird in Zukunft umgesetzt.

Die Leitung funktioniert einwandfrei beim Einwählen inwiefern ist das ganze mit dem Stromverlust des RPi's und den Vorgaben des Anbieter usw. zusammen zu bringen? Ist das eher nicht eine lokales Softwareproblem mit Debian?

Bzgl. Umsetzung des OpenVPN's habe ich den Klienten installiert und die Konfigurationsdatei des Anbieters genutzt.

Werde beim Anbieter nachhacken.
Mitglied: orcape
orcape 09.06.2015 um 12:13:47 Uhr
Goto Top
Ist es wirklich ratsam diese auszulagern oder nur eine Empfehlung?
Bei mir laufen nur private OpenVPN-Tunnel und da sind Zertifikate und Key in extra Files untergebracht.
Ob das überhaupt etwas mit Deinem Problem zu tun hat, ist fraglich.
Wie sehen denn die Anweisungen Deines Providers aus ?
Daran solltest Du Dich halten.
Ist das eher nicht eine lokales Softwareproblem mit Debian?
...könnte schon sein.
Wenn das händische starten des OpenVPN ohne Fehlermeldungen funktioniert und kein Autostart, so könnte das schon mit Deinem System zusammenhängen.
Die Konfigurationsdatei des OpenVPN-Clients unter Debian heisst...
/etcopenvpn/client.conf
...bei Dir....
Konfigurationsdatei in /etc/openvpn/VPN.conf
Wenn die Datei bei Dir eine Namensänderung erfahren hat, könnte das schon dazu führen, das der Tunnel nicht wieder automatisch startet.
Einen Netzwerkmanager wird es ja wohl auf dem Raspi nicht geben, der da Querschlägt.
Gruß orcape
Mitglied: Arano
Arano 09.06.2015 um 12:54:13 Uhr
Goto Top
Hallo

Die Konfigurationsdatei des OpenVPN-Clients unter Debian heisst...
/etcopenvpn/client.conf
...bei Dir....
Konfigurationsdatei in /etc/openvpn/VPN.conf
Wenn die Datei bei Dir eine Namensänderung erfahren hat, könnte das schon dazu führen, das der Tunnel nicht wieder automatisch startet.
Und in deinem init-Script steht auch client.conf, das muss schon gleich lauten !

Irgend wo müssen wir das ja mal eingrenzen, können ja nicht an allen Stellen gleichzeitig "basteln" - dann funktioniert erst recht nichts. links repariert, aber rechts was kaputt gemacht

Schau doch mal, ob das init-Script überhaupt ausgeführt wird in dem du es etwas erweiterst:
/bin/echo "ovpn init-script CALL" >>"/tmp/init-test.log"  
case "$1" in   
    start) 
       /bin/echo "ovpn init-script START" >>"/tmp/init-test.log"  
       openvpn /etc/openvpn/client.conf 
       /bin/echo "ovpn init-script START = $?" >>"/tmp/init-test.log"  
        ;; 

    [...]

/bin/echo "ovpn init-script DONE" >>"/tmp/init-test.log"  
Vielleicht ist da wirklich etwas das den Aufruf des init-Scripts verhindert... oder falls das zuverlässig funktioniert, es doch ein Konfigfehler ist.
Aber dann wissen wir es !


~Arano
Mitglied: adm999
adm999 09.06.2015 aktualisiert um 15:18:32 Uhr
Goto Top
@orcape Auch die Umbennung von "VPN" in "CLIENT" zeigte keine Wirkung.
Einmal verbunden im laufenden Betrieb läuft die OpenVPN-Verbindung auch nach einem Neustart; NUR beim Auschalten (vom Strom trennen)

@Arano Habe die Methode aufgegeben und nach einem anderen Weg mit der /etc/default/openvpn (AUTOSTART="client") getestet.
Habe nach dieser Anleitung die OpenVPN-Verbindung automatisiert und hergestellt.

Vielleicht ist da wirklich etwas das den Aufruf des init-Scripts verhindert... oder falls das zuverlässig funktioniert, es doch ein Konfigfehler ist.
Aber dann wissen wir es !

Neustart (/tmp/init-test.log)
ovpn init-script START
ovpn init-script DONE
Stromverlust (/tmp/init-test.log)
ovpn init-script START = 0
ovpn init-script DONE
Erneuter Neustart (/tmp/init-test.log)
ovpn init-script START
ovpn init-script DONE
Mitglied: adm999
adm999 15.06.2015 um 13:39:21 Uhr
Goto Top
Keine weiteren Lösungen?
Mitglied: Arano
Arano 15.06.2015 um 14:46:54 Uhr
Goto Top
Oh Hi!
Sorry, mir war der untere Teil deiner Antwort entgangen, dachte das kommt später mit einer neuen Antwort.

Wie es aussieht wird immerhin das init-Script jedesmal ausgeführt, am "Autostart" liegt es also nicht.

Ich hatte in der zw.Zeit dein Script so wie es ist auf mein RasPi kopiert und ein update-rc.d -n ovpn oder ähnlich gemacht (-n = nur anzeigen was gemacht werden würde wenn). Bei mir wollte er das als "S01ovpv" in meinen runlevel verlinken.
Damit würde ovpn als einer der ersten zusätzlichen Dienste gestartet werden, eventuell noch vor dem Netzwerk.

Mit welcher Priorität wurde das denn bei dir erstellt ?
Wie LonesomeWalker schon erwähnte: den required-Tag im init-Script anpassen.


~Arano
via Mobile
Mitglied: adm999
adm999 15.06.2015 um 15:16:14 Uhr
Goto Top
Es klappt bei mir weder über die Methoden update-rc.d noch über die Konfigurationdatei openvpn mit dem Befehl "AUTOSTART="VPN"".

Mit welcher Priorität wurde das denn bei dir erstellt ?
Es wurde keine Priotität gesetzt.

Wie LonesomeWalker schon erwähnte: den required-Tag im init-Script anpassen.
Wie trage ich ein, dass es nachdem die Verfügbarkeit vom Netzwerk/Internet vorhanden ist startet?
Mitglied: Arano
Arano 15.06.2015 um 19:10:00 Uhr
Goto Top
Hi,

Mit welcher Priorität wurde das denn bei dir erstellt ?
Es wurde keine Priotität gesetzt.
Ich schätze mal da missverstehen wir uns !
Beim einrichten deines Init-Scripts mittels update-rc.d sollte in /etc/rc2.d/ ein symbolischer Link erstellt worden sein. Möglicherweise wie bei mir S01openvpn. Die Ziffernfolge "01" ist in diesem Fall "die Priorität der Reihenfolge der Scripte". Kleine Zahlen zuerst, große Zahlen zuletzt.

pi@raspberrypi ~ $ ls -l /etc/rcS.d/S11networking 
lrwxrwxrwx 1 root root 20 Jan  7  2014 /etc/rcS.d/S11networking -> ../init.d/networking

pi@raspberrypi ~ $ ls -l /etc/rc2.d/S02ntp 
lrwxrwxrwx 1 root root 13 Jan  7  2014 /etc/rc2.d/S02ntp -> ../init.d/ntp

pi@raspberrypi ~ $ head /etc/rc2.d/S02ntp 
#!/bin/sh

### BEGIN INIT INFO
# Provides:        ntp
# Required-Start:  $network $remote_fs $syslog
# Required-Stop:   $network $remote_fs $syslog
# Default-Start:   2 3 4 5
# Default-Stop: 
# Short-Description: Start NTP daemon
### END INIT INFO
pi@raspberrypi ~ $ 

rcS.d ist das runlevel für den Systemstart, hier werden unter anderem die Netzwerkadapter konfiguriert und gestartet/verbunden. Danach wird in das gewünschte runlevel gewechselt und weitere Programme/Dienste gestartet.
Natürlich kann es sein, das z.B. das Netzwerk noch gar nicht vollständig aufgebaut ist aber schon in den nächsten runlevel gewechselt wird, dann kann z.B. auch OpenVPN oder NTP nicht korrekt starten weil beide einen verfügbaren Netzwerkadapter benötigen.
Dafür der "Required-Start", dann kann init noch weiter steuern die das nun geht weiss ich aber auch nicht.

Als erste Möglichkeit also einfach mal "S01openvpn" in z.B "S99openvpn" umbenennen. Dann vergeht vielleciht noch mehr zeit zwischen dem Netzwerksetup und dem Start von OpenVPN - kann ja schon ausreichen.
Oder besser gleich das init-Script um nötige Bedingungen ergänzen.
https://wiki.debian.org/LSBInitScripts

> Falls das das Problem ist <


~Arano