Openvpn und DSL Zwangstrennung

[KlausHa]

Hallo,
ich habe mich durch einige Beiträge hier im Forum gearbeitet, konnte leider keinen Denkanstoss finden. Wurde dieses Theme dennoch schonmal behandelt,bitte ich um den entsprechenden Link.

Einführung
ich habe zwei syno's: eine bei mir in der Wohnung und eine bei meinen Eltern in der Wohnung. Beide sind per DSL mit dem Internet verbunden.
Täglich werden Sicherungen zwischen den beiden Synos durchgeführt auf einer sicheren Verbindung (openvpn). Das ganze funktioniert generell.
Aber ich kämpfe mit zwei Problemen bzgl. DSL Zwangstrennung und erhoffe mir von euch ein paar Ideen / Denkanstösse. Aber zunächst meine Konfiguration etwas detaillierter.


Meine Konfiguration:
-A: eine DS213 mit DSM 4.1 bei mir in der Wohnung
-B: eine DS212j mit DSM 4.1 bei meinen Eltern

-beide Synos sind per DDNS erreichbar (über noip.com), die entsprechenden Portweiterleitungen sind auf den Fritzboxen natürlich eingerichtet.
-DDNS ist sind auf den Fritzboxen jeweils eingerichtet, nicht auf den Synos.

-B ist als openvpn server konfiguriert (über die synology GUI konfiguriert also NICHT per ipkg installiert)
-A ist als openvpn client konfiguriert (über die synology GUI konfiguriert also NICHT per ipkg installiert) und ist mit B verbunden

-die Datensicherung ist ebenfalls über die synology GUI konfiguriert:
- in A (also beim openvpn-client), ist 10.8.0.1 als Ziel konfiguriert
- und in B (also im server) ist 10.8.0.6 als Ziel konfiguriert

Da openvpn Adressen als Ziele konfiguriert sind, kann ich mir sehr sicher sein, dass die Daten beim Backup tatsächlich nur über die VPN verbindung fliessen.


Problem1: Wiederverbindung des Openvpn-Clients zum Openvpn-Server nach DSL Zwangstrennung
-die DSL Zwangstrennung findet jede Nacht zwischen 4 und 5 Uhr statt. Danach schafft es auch der Client sich normalweise wieder zu verbinden.
Nur jeden Montag klappt es leider nicht. Aus irgendeinem Grund schafft es der Client NICHT sich wieder zu verbinden. Wenn ich mich aber manuell einlogge
auf die Syno-oberfläche, und auf "verbinden" im openvpn menü klicke, kommt die Verbindung wieder zu stande.

Meine Idee:
der openvpn syno GUI opberfläche liegen wahrscheinlich ähnliche scripte zu grunde wie bei der installation mittels ipkg.
also kann man ein script schreiben, das auf dem openvpn-client folgendes tut (per cronjob, einmal am Tag):
1.) Prüfe, ob ping 10.8.0.1 erfolgreich.
2.) Falls nicht: verbinde zu 10.8.0.1 (server)

Frage: wie kann ein Kommando für Schritt 2.) aussehen? Was für ein script müsste ich ansprechen, mit was für einem Parameter?


Problem2: Zuteilung einer statischen openvpn adresse nach jeder DSL Zwangstrennung
Nach jeder Zwangstrennung und dann meist erfolgreichen erneuten Verbindungsaufbau, wird dem openvpn-Client leider immer wieder eine neue VPN adresse zugeteilt.
Also 10.8.0.6 oder 10.8.0.10 oder... etc...
Das führt dazu, das Sicherungen vom Openvpn-Server zum Openvpn-Client nur dann klappen, wenn der Client wieder mal zufällig die Adresse 10.8.0.6 bekommt.

Ich weiss normalerweise kann man wohl irgendwo in der openvpn client Konfiguration ein zeile einfügen, um immer wieder die gleiche Adresse zugeteilt zu bekommen.
Aber bei der openvpn GUI (zumindest bei DSM 4.1) geht das nicht.

Fragen:
-lohnt ein Update auf DSM4.2 / DSM4.3 gibt es dort eine solche Option in der GUI?
-kann man irgendwo ein Script oder eine Konfiguration in der Openvpn GUI so patchen, das der client immer die gleiche (also statische) openvpn-ip zugeteilt bekommt? Also z.B. immer 10.8.0.6?)


Hinweis:
-installation von openvpn mittels ipkg ist für mich keine Option, weil:
- habe keine Zeit um mich zu beschäftigen, wie ipkg installiert wird.
- ich habe gelesen es gibt probleme mit ipkg und dem "schlafmodus" der syno. Also syno geht unter umständen nicht mehr "schlafen" wenn man ipkg manuell installiert. Habe keine Zeit mich damit zu beschäftigen die entsprechenden Workarounds/Anpassungen durchzuführen.
- danach müsste man dann dann den openvpn server und client jeweils selbst manuell über die entsprechenden konfigurations-scripte konfigurieren. Habe keine Zeit mich damit zu beschäftigen.
- falls ich mal aus irgendeinen Grund auf eine höhere DSM version als jetzt migrieren möchte, könnten weitere Probleme mit der ipkg installation / openvpn installation zu erwarten sein und ich müsste alles nochmal neu aufsetzen. Habe auch dazu keine Zeit.
--> ich möchte also so wenig wie möglich modifizieren.

Grüße,
KlausHa

 

[fpo4711]

Hallo KlausHa,

also ich habe mehrere Installationen mit OpenVPN zu laufen und diese überstehen alle die entsprechenden Zwangstrennungen. Allerdings komme ich auch nicht auf die Idee irgendwelche IP's des Tunnels zu nehmen. Warum sollte man das? Sprich die Zielgeräte mit ihren lokalen IP's an, setze den Haken im Clienten auf "Wiederverbinden" und fertig. Die DS versucht es nicht ewig, aber doch mehrere Male sich wiederzuverbinden. Das sollte eigentlich ausreichen.

Gruß Frank

 

[KlausHa]

Hallo Frank,
vielen Dank für Deine Tipps. Ich habe das gleich ausprobiert. Leider funktioniert es nur teilweise.

Hier die Details:

Ich hatte beiden syno's schon vor einigen wochen feste lokale ip's im netzwerk zugewiesen und darauf geachtet, dass sich der Adressraum nicht überlappt:
A: 192.168.53.201
B: 192.168.178.201
Subnetmaske bei beiden jeweils: 255.255.255.0 eingetragen. (jeweils in den Syno's im Menü Netzwerk)

(i) Nun, aufgrund deines Hinweises habe ich eben in Datensicherung von A als Ziel 192.168.178.201 (also lokale ip von B) angegeben. Das hat tatsächlich funktioniert!
(ii) In B habe ich nun genau das selbe versucht. Also als Ziel 192.168.53.201 angegeben. Aber leider klappt die Verbindung nicht.
Ich habe mich zur Kontrolle in B via ssh als root eingeloggt und ein traceroute 192.168.53.201 angegeben. Der Output sieht so aus:

BStation> traceroute 192.168.53.201
traceroute to 192.168.53.201 (192.168.53.201), 30 hops max, 38 byte packets
1 fritz.box (192.168.178.1) 1.260 ms 1.582 ms 0.845 ms
2 87.186.224.xxx (87.186.224.xxx) 41.370 ms 40.286 ms 40.593 ms
3 * * *
4 * * *
5 * * *

Nach einiger Zeit habe ich abgebrochen. Was die ip 87.186.224.xxx genau bedeuted kann ich nicht sagen, denn als externe IP meines DSL anschlusses hat noip.com eine andere IP identifiziert.
Ein traceroute 10.8.0.6 (die entsprechende openvpn adresse von A) hingegen führt übrigens sehr schnell zum erfolg

Als "Gegencheck" habe ich mich nun auch in A via ssh als root eingeloggt und ein traceroute angegeben, dass sehr schnell zum Ziel geführt hat:
AStation> traceroute 192.168.178.201
traceroute to 192.168.178.201 (192.168.178.201), 30 hops max, 38 byte packets
1 192.168.178.201 (192.168.178.201) 79.253 ms 82.547 ms 80.498 ms

Sehr seltsam, dass die Verbindung von A --> B mittels privater IPs sehr gut funktioniert. Aber von B--> A funktioniert es mittels privater IP's gar nicht. Nur mittels der openvpn adresse (10.8.0.x). Ich habe eben mehrfach die Einstellungen an beiden Seiten geprüft. Auch die Portweiterleitungsregeln stimmen jetzt. Ich hatte vorhin festgestellt, das bei der fritzbox im Netzwerk von A die Weiterleitungsregel falsch war (war tippfehler, verbindung hatte aber vorher bei Nutzung der openvpn IPs trotzdem funktioniert...). Diese weiterleitungsregel habe ich jetzt korrigiert (siehe unten).

Nun gut ist schon sehr spät. Ich mache Morgen weiter. Hättest du eine Idee wie ich das Problem weiter debuggen / eingrenzen kann?
Ziel wäre: Verbindung B-->A mittels lokaler IP.

Grüße,
KlausHa


P.S.
Die Weiterleitungsregeln sehen bei beiden fritzboxen bei mir so aus - sollte so OK sein:

Im Netzwerk von A:
PPTP (VPN) TCP 1723 192.168.53.201 1723
openvpn UDP 1194 192.168.53.201 1194


Im Netzwerk von B:
PPTP (VPN) TCP 1723 192.168.178.201 1723
openvpn UDP 1194 192.168.178.201 1194


(Hinweis: ja ich weiss, port 1723 weiterzuleiten ist eigentlich nicht notwendig, aber ich habe PPTP als "backup" aktiviert. Falls openvpn mal nicht funktioniert und ich von ausserhalb dringend auf meine syno zugreifen muss, aber das ist sowieso ein anderes Thema...

 

[fpo4711]

(Hinweis: ja ich weiss, port 1723 weiterzuleiten ist eigentlich nicht notwendig, aber ich habe PPTP als "backup" aktiviert. Falls openvpn mal nicht funktioniert und ich von ausserhalb dringend auf meine syno zugreifen muss, aber das ist sowieso ein anderes Thema...

Wieso, ist doch völlig korrekt. Mach ich auch so um einen Failback zu haben.

Für den Zugriff auf der Serverseite wirst Du um separate Angaben in den Configfiles nicht rum kommen. Es ist aber keine zusätzliche Installation nötig. Allerdings kann ich Dir nicht sagen ob das ein Update des VPN-Servers überstehen würde. Ich hab mir um das gelegentlich prüfen zu können den Config File Editor installiert und einen Verweis auf die openvpn.conf für den Server erstellt. Geht dann im Notfall recht zügig eine Vorlage wieder zu erneuern.

Um von der Serverseite auf die Clienten zugreifen zu können, muß dem Server bekannt gegeben werden welches Subnetz denn hinter der Einwahl eines Clienten besteht. Dazu werden Clientconfigfiles auf dem Server hinterlegt, die den Namen des Benutzers haben der sich als Client einwählt. Und der ganze Trick ist hier drin ein iroute (und man beachte das 'i' am Anfang) zu definieren.

Das Verfahren hab ich hier mal beschrieben und unten befindet sich der Link zu den Infos von OpenVPN. Ich hab das schon funktionsfähig umgesetzt und konnte dann sogar durch zwei statische Routen auf den jeweiligen Routern zwei Netze so verbinden das auf alle Geräte des anderen Netzes zugegriffen werden konnte.

Solltest Du das so lösen, kannst Du jegliches Gerät ohne Kenntnis des Tunnels ansprechen. Und einzig der Server ist entsprechend anzupassen. Client bleibt wie er ist.

Wenn Du damit Schwierigkeiten haben solltest, meld Dich einfach. Hier turnen mehrere Teilnehmer rum die das beherrschen.

Gruß Frank

 

[KlausHa]

Hallo Frank,
vielen Dank für Deine Hinweise und den Link auf das andere Posting. Wie dort beschrieben, habe ich es ausprobiert, leider funktioniert es nicht:
-traceroute 192.168.53.201 liefert das gleiche ergebnis als wenn ich die konfiguration gar nicht geändert hätte.
-Eingabe von 192.168.53.201 als Ziel im Datensicherungsmenü führt zu einer Fehlemeldung (eingabe von 10.8.0.6 als Ziel funktioniert aber nach wie vor)

Um ehrlich zu sein, bin ich mir nicht sicher in welchen Ordnern die Dateien zu erstellen /anzupassen sind.
Die openvpn.conf gibt es zum beispiel mehrfach.
Mit den speziellen linux zeilenumbrüchen sollte es kein problem geben, da ich die Dateien mit dem vi angepasst habe, lediglich die Dateien für die user habe ich unter windows erstellt und danach auf die syno kopiert, habe aber im notepad++ darauf geachtet das keine windows-zeilenumbrüche vorhanden sind. (Erst danach ist mir eingefallen, das man ja gleich den vi nehmen kann, nun war ich aber zu faul die Dateien nochmal mit dem vi zu erstellen.)

Meine Fragen:
1.) Die openvpn.conf liegt auf meinen System in verschiedenen pfaden:
einmal hier: (i) /var/packages/VPNCenter/target/etc/openvpn <-- in diesem pfad habe ich radiusplugin.cnf angepasst.
und hier: (ii) /var/packages/VPNCenter/etc/openvpn <-- in diesem pfad habe ich das ccd verzeichnis erstellt und darunter dateien fuer die user erstellt. Der Inhalt der Dateien für die user besteht nur aus einer Zeile und sieht so aus: iroute 192.168.0.0 255.255.255.0

Verwirred fuer mich ist, das die openvpn.conf mehrfach vorkommt. einmal im pfad (i) und einmal im pfad (ii).
Das sind definitiv verschiedene Dateien, keine links. Habe ich ausprobiert. Ich habe die anpassung fuer client-config-dir und client-to-client in beiden openvpn.conf's ausprobiert. Hat leider bei beiden nicht funktioniert. Ich hoffe meine Annahme ist richtig, dass die folgenden Kommandos einfach am ende der Datei openvpn.conf einzufügen sind:
client-config-dir ccd
client-to-client

Nachdem ich die openvpn.conf abgespeichert hatte, habe ich ich immer jeweils den openvpn server gestoppt und danach wieder gestartet (also häckchen raus bei openvpn server aktiveren und abspeichern; danach häckchen wieder aktivieren und abspeichern.) War die ganze Zeit über pptp mit dem openvpn server verbunden.

hier nochmal die links die es gibt im ordner: /var/packages/VPNCenter
lrwxrwxrwx 1 root root 32 Apr 26 20:39 etc -> /usr/syno/etc/packages/VPNCenter
lrwxrwxrwx 1 root root 28 Apr 26 20:39 target -> /volume1/@appstore/VPNCenter


2.) könnte es sein, dass das ccd verzeichnis im "target" verzeichnis erstellt werden muss?
Was ist der Unterschied zwischen dem target verzeichnis und dem das direkt unter /var/packages/VPNCenter/etc/ liegt? Woran kann ich erkennen welches verwendet wird in meiner konfiguration?

3.) ich war mir nicht sicher fuer welchen user die dateien im ccd verzeichnis anzulegen sind (also für den user, mit dem sich der openvpn client anmeldet, oder mit admin? ) Habe aufgrund der Unsicherheit einfach beide dateien angelegt. Beide haben den gleichen Inhalt (siehe oben).

KlausHa

 

[KlausHa]

Nachdem ich das posting fertiggeschrieben habe, habe ich festgestellt, dass ich nun plötzlich gar nicht mehr auf den meine syno bei meinen eltern komme. Weder per openvpn noch per pptp.. irgendwas ist hier mächtig schiefgelaufen - hätte ich jetzt nicht erwartet, dass auch pptp "abschmiert" bei solchen experimenten, da ich ja "nur" openvpn einstellungen geändert habe.

KlausHa

 

[fpo4711]

Hallo,

war jetzt auch gerade verwirrt über die Pfade weshalb ich das nochmal kurz geprüft habe.

openvpn conf: /var/packages/VPNCenter/etc/openvpn/openvpn.conf

ccd: /var/packages/VPNCenter/etc/openvpn/ccd

radius-conf: /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf

Ich glaube die conf unter var/packages/VPNCenter/target/etc/openvpn/openvpn.conf wird am Anfang als Vorlage genommen. Die aktuell gerade benutzte erkennt man an den zwei "push route ... " am Anfang die dafür sorgen das der Client weiß welches Netz/Tunnel auf dem Server befindet.

Mit Benutzer bzw. Filename im ccd-Verzeichnis ist der Benutzer gemeint der sich einwählt bzw. eben auch die Privilegien hat. Sollte vieleicht nicht gerade "admin" sein. Den habe ich nur genommen weil eben überall vorhanden

Um die Änderungen an der openvpn.conf auch mal zu überprüfen oder wie jetzt gerade bei Dir zu ändern, bietet sich der Config File Editor an. Hier braucht man nur in der Config einmal den Pfad angeben und kann dann jederzeit mit einem Klick das Config ändern/prüfen. Die IP's die in der openvpn.conf stehen hat die DS mal erstellt und die sollten auch stimmen denn es hat ja schon von der Clientseite funktioniert. Ist jedenfalls die Route für den Tunnel und den Server die an den Clienten gepusht wird.

Hab jetzt deine Netze gerade nicht vor Augen, aber in dem Benutzerabhängigen File unter ccd nennen wir es mal "admin" braucht nur iroute stehen. Wenn das Subnetz auf Clientenseite die 192.168.0.0/24 sein sollte würde da:

iroute 192.168.0.0 255.255.255.0

reingehören.

Muß jetzt noch eine Tüte Schlaf nehmen, kann aber gerne am Samstag wieder helfen.

Gruß Frank

Edit: Und immer daran denken, nach einer Änderung der config den OpenVPN Server neu zu starten.

 

[fpo4711]

Hab es gerade nochmal gesehen, Du hattest ja die Subnetzte genannt. Dann kommt in das ccd-file

iroute 192.168.53.0 255.255.255.0

Also die Route zum Clientnetz.

 

[KlausHa]

habe gerade gesehen, dass du mir schon geantwortet hast. Danke!!! Werde das morgen ausprobieren, wenn ich wieder frisch bin im geist.


so, konnte jetzt mich eben wieder verbinden - puhh
Habe gleich mal in diveresen logfiles nachgeschaut was passiert ist und sehe in den logfiles der fritzbox meiner eltern folgendes:

15.08.13 01:09:11 Internetverbindung wurde getrennt.
15.08.13 01:09:11 PPPoE-Fehler: Zeitüberschreitung.
15.08.13 01:08:57 Zeitüberschreitung bei der PPP-Aushandlung.
15.08.13 01:08:57 Internetverbindung wurde getrennt.

Und das ganze im Wechsel (PPoE Fehler und Internetverbindung getrennt) ca.30min lang. Im Logfile der fritzbox sehe ich momentan keinen älteren einträge dieser Art - aber es zeigt im webinterface der fritzbox auch nur die letzte Woche an.

War das nur Zufall - und es gab gerade ein Problem bei der Telekom? Oder habe ich grundlegend beim routing etwas so falsch gemacht, dass die Telekom den anschluss meiner Eltern mal kurz für 30min lahm gelegt hat? Das Problem ist nur nach ein paar minuten aufgetreten, nachdem ich die openvpn.conf zum zweiten mal angepasst hatte.

Naja bin jetzt erleichert und habe ersteinmal alle meine änderungen wieder rückgängig gemacht, bis ich herausgefunden habe was passiert ist. So und jetzt gehe ich erstmal schlafen...

 

[KlausHa]

hallo Frank,
leider funktioniert es immer noch nicht.
Habe jetzt die Dateien angepasst in den pfaden wie oben bei Dir angegeben und habe - nur um 100% sicher zu gehen die Dateien im ccd verzeichnis nochmal neu mit dem touch kommando erstellt und mit dem vi bearbeitet. Der Inhalt der Dateien im ccd verzeichnis ist wie oben von Dir empfohlen iroute 192.168.53.0 255.255.255.0
Ich habe auch _wirklich_ den openvpn server aus und wieder ein geschaltet. Und habe auch den inhalt der Anpassungen in den Dateien mehrfach nochmal geprüft. Leider funktioniert es nicht.

Ich habe mir jetzt deshalb das von Dir verlinkte howto von openvpn.net durchgelesen.
Folgendes ist mir da aufgefallen:
copy&paste:

Erstens

Next, add the following line to the main server config file (not the ccd/client2 file):

route 192.168.4.0 255.255.255.0

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.


zweitens
and the duplicate-cn flag must not be used in the OpenVPN server configuration file.


Das heisst man soll in der openvpn.conf das "route" statement so setzen, das es auf das client netz zeigt und man soll duplicate-cn entfernen.
Hast du das extra in deinem posting nicht angegeben oder vielleicht nur vergessen? ich traue mich nicht gerade, dass auszuprobieren, weil ich noch nicht so viel Erfahrung mit openvpn habe und der openvpn server bei meinen Eltern steht - möchte mich ungern wieder aussperren...


Grüsse,
KlausHa

 

[fpo4711]

Hier die Configs so wie sie funktionieren.

Auf dem Server /var/packages/VPNCenter/etc/openvpn/openvpn.conf

push "route 192.168.178.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
dev tun

management 127.0.0.1 1195

server 10.8.0.0 255.255.255.0

# fpo modified 
route 192.168.53.0 255.255.255.0
client-config-dir ccd
client-to-client

dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh1024.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 5

comp-lzo

persist-tun
persist-key

verb 3

#log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf 
client-cert-not-required 
username-as-common-name
duplicate-cn

und unter dem entsprechendem Benutzernamen im /var/packages/VPNCenter/etc/openvpn/ccd Verzeichnis

iroute 192.168.53.0 255.255.255.0

Und nach der Änderung nicht vergessen den VPN-Server neu zu starten.

Gruß Frank

 

[KlausHa]

Hallo Frank,
ich werde verrückt. Es funktioniert. Vielen Dank für Deine Hilfe

D.h. mein Problem2 aus meinem Ursprungsposting ist gelöst. Durch die Nutzung der festen, internen ip's habe ich nicht mehr das Problem, dass sich die einzutragende Ziel-ip ändern kann nach einer DSL Zwangstrennung.

Ausserdem werde ich die nächsten Tage beobachten, ob sich die openvpn verbindung jetzt wirklich immer "erholt" bzw. wiederverbindet nach einer Zwangstrennung. Siehe auch das Problem1 aus meinem Ursprungsposting.
Aber vielleicht habe ich Glück und das Wiederverbinden klappt jetzt besser, wenn man interne ip's nutzt anstatt der openvpn ip's. (Allerdings fällt mir kein fachlicher Grund ein wieso das so sein sollte - habe leider in diesem Bereich nur "Halbwissen".

Falls das Problem1 noch nicht gelöst ist, dann werde ich mich von folgenden Beitrag von Dir inspirieren lassen und solch ein ähnliches script von einem cronjob einmal am Tag anstarten lassen
http://www.synology-forum.de/showthread.html?43444

Grüße,
KlausHa

 

[fpo4711]

Hallo Klaus,

ich hab das so am Laufen und keinerlei Problem damit. Backup läuft immer sauber durch und wiederverbinden klappt auch jeweils. Habe die Backupaufträge jeweils 10 Minuten nach der Zwangstrennung starten lassen. Wenn Du Dir noch statische Routen auf den jeweiligen Routern einrichtest, kannst Du so auch auf andere Geräte innerhalb der jeweiligen Subnetze zugreifen.

Den Haken im Clienten "Wiederverbinden.." nicht vergessen. Ich glaube Sysnology versucht es dann 5 Mal im 10 Sekunden Takt. Hab das aber nei geprüft, weil keinerlei Probleme und im schlimmsten Fall eben oben genannter Vorschlag per Script. Du weißt ja es gibt keine Probleme - nur Lösungen
Na dann viel Spaß damit.

Gruß Frank

 

[KlausHa]

Hallo Frank,
heute Nacht hat das automatische Verbinden des openvpn clients leider nicht geklappt. Ich habe mir die Logfiles beider Fritzboxen angeschaut und habe herausgefunden, dass neben der Zwangstrennung um 04.00, es zwischen 1.00 und 2.00 kein Internet gab. Die Logfiles sind voll mit:
PPPoE-Fehler: Zeitüberschreitung. Diese lange Unterbrechung hat die openvpn-verbindung nicht überlebt.

Aber wie du schon sagst es gibt keine Probleme, sondern nur Lösungen ;-)
Also habe ich folgende zwei Anleitungen kombiniert:
(i) http://www.synology-forum.de/showthread.html?43444
(ii) http://www.synology-wiki.de/index.php/Cron

Hinweis, falls hier noch andere mitlesen. Das script vpn_connect.sh aus dem link (i) ist wie folgt in die Datei crontab (bzw. beim testen in die shell console ) einzutragen:
sh /volume1/homes/backupjob/vpn_connect.sh start
Nicht vergessen den cronjob dienst wie im wiki beschrieben zu stoppen und danach wieder zu starten!


Das scheint wunderbar zu funktionieren. Ich habe eben ein paar Tests gemacht und der openvpn client hat tatsächlich automatisch wiederverbunden, getriggert durch den Cronjob

Eine andere Idee wäre es, den "wiederverbindungstimer" vom openvpn-client heraufzusetzen. Also: anstatt es der openvpn client "nur" ~5min probiert sich wiederzuverbinden, könnte man vielleicht dieses Wert auf 90min erhöhen. Aber ich weiss nicht ob das überhaupt einfach möglich ist über eine Konfigurationsdatei von openvpn. Auf jeden Fall wäre diese Variante natürlich generischer. Denn der Cronjob arbeitet ja nur "statisch" - habe ihn auf zwei feste Uhrzeiten programmiert um das entsprechende Script zu starten.

Also Frank nocheinmal wirklich vielen Dank für Deine Hilfe und Deine zahlreichen Beiträge in diesem Forum.
Dadurch sind jetzt meine beiden Probleme aus meinem ersten Posting in diesem Thread tatsächlich gelöst!

KlausHa

 

[fpo4711]

Auch mir geht das runter, wenn es denn mal einer der sich bemüht das umsetzen kann. Denn gerade die Info aus dem ersten Thread war nicht einfach zu erarbeiten. Tja, für den Wiederholungszähler beim Wiederaufbau müßte man sicherlich etwas weiter in der Internas der Synology-Lösung vordringen. Wäre auch schön wenn man das etwas manueller beeinflußen könnte. Mal sehen vielleicht ....

Aber mal ehrlich 1-stündiger Auswahl für Wiederherstellung der DSL-Verbindung, das ist schon extrem. Damit hätte ich jedenfalls nicht gerechnet.

Gruß Frank