CoolRaoul

La solution est ici

J'ai rencontré le meme probleme Dans la log (/var/log.messages) j'avais ces erreurs lors de chaque connexion VPN Entrante: pptpd[24621]: CTRL: Client <IP> control connection started pptpd[24621]: CTRL: Starting call (launching pppd, opening GRE) pppd[24622]: /usr/local/synovpn/lib/pppd/2.4.5/radius.so: cannot open shared object file: No such file or directory pppd[24622]: Couldn't load plugin /usr/local/synovpn/lib/pppd/2.4.5/radius.so pptpd[24621]: GRE: read(fd=9,buffer=1bd25,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs pptpd[24621]: CTRL: PTY read or GRE write failed (pty,gre)=(9,10) pptpd[24621]: CTRL: Reaping child PPP[24622] pptpd[24621]: CTRL: Client <IP> control connection finished Je m'en suis sorti en desinstallant et reinstallant le package VPN

Bon apparement c'est pas encore tout a fait au point. Il y a des bugs dans les scripts de démarrage de syslog et j'ai aussi le sentiment que l'interopérabilité entre le package "syslog server" d'une part, le /sbin/syslogd de base et le syslog-ng intégré à DSM de l'autre n'est pas encore complètement "fluide" exemple: FSERV> /usr/syno/etc/rc.d/S22syslogng.sh start Syslog-ng server start... sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand Trouvé la source du bug dans "/usr/syno/syslogclient/scripts/runscript.sh" if [ -n "${fac}" ]; then if [ -z ${SYSLOGNG_FAC_FILTER_STRING} ]; then SYSLOGNG_FAC_FILTER_STRING="program(${fac})" else SYSLOGNG_FAC_FILTER_STRING="${SYSLOGNG_FAC_FILTER_STRING} or program(${fac})" fi fi Il aurait fallu des quotes autour de "${SYSLOGNG_FAC_FILTER_STRING}", comme ceci: if [ -z "${SYSLOGNG_FAC_FILTER_STRING}" ]; then[/code] J'ai ouvert un dossier de support chez Synology, on verra bien

Peut-être en CPL ?

Le protocole Cloudstation ne s'appuie pas sur du http, par conséquent derrière un proxy faut abandonner tout espoir. Non ce n'est pas possible.

Dans les réseaux d'entreprise, en général *tous* les ports sont fermés a l'exception du , du 443 et parfois du 22. Comme ces derniers sont déjà utilisés par des services standards, je ne vois pas trop ce qu'il serait possible de faire pour satisfaire ta demande

Conditions a remplir: Le port 6690 du Syno doit être accessible de l'extérieur (via règles dans la box) Ne pas oublier de l'autoriser dans le firewall si celui-ci est activé: Le Synology doit être accessible de l'extérieur avec un nom permanent (type dydns) à moins que vous disposiez d'une IP fixe. et ensuite on se connecte à cloud station en donnant son adresse à la place de l'ID:

Dans ce cas vaudrait peut-être mieux t'abstenir, tu risque de faire des dégats en faisant des choses sans comprendre. "cache_dir" n'est pas une commande. Que cherches-tu a faire en tapant ça? Pour vérifier que le répertoire est créé il faut taper, par exemple: ls -ld /opt/var/cache/davfs2[/CODE] Peux-tu nous dire comment tu t'y es pris pour modifier le fichier '/opt/etc/davfs2/davfs2.conf'

Simplement cliquer sur le nom et commencer à taper:

D'après les retours dans ce forum et celui de Synology (ainsi que ma propre expérience, mais je n'ai pas testé toutes les configurations possibles) il semble bien que la réponse soit positive.

Qui aurait une idée sur (ou déja rencontré) ce problème? Lorsque je me connecte à l'interface d'admin http Syno à partir de mon taff (ou je passe par un proxy), lorsque certains applications DSM sont actives (interface syslog par exemple) Chrome se met par moment à consommer du cpu en permance (un core pour lui tout seul). J'ai essayé en désactivant toutes les extensions sans plus de résultat. Pas de problème par contre avec d'autres navigateurs (IE, Opera ou Firefox) Je n'ai rencontré ce problème qu'avec DSM jusqu'ici

A l'occasion de la sortie de DSM 4.0 je me permet un petit "up" sur ce sujet Il n'est désormais plus necessaire d'editer "/usr/syno/etc/synosyslog" en se connectant en ssh (ou telnet) sur le syno Cela se fait directement dans l'interface d'admin. dans le panneau de configuration sélectionner ce qui nous donne: Dans le champ "serveur" mettre l'IP du serveur syslog (dans l'exemple ci dessus on redirige sur le package syslog installé en local) L'onglet "filtre de journal" permet de choisir quelles catégories d’évènements sont propagées.

Ah, Ok la *fonction* En tout cas, je confirme qu'elle se cache bien, elle cache même son nom!

5000 Megas, autrement dit 5 Gigas Bigre! Mais bof, qu'est-ce que 5 gigas de nos jours...

Quelle fonction?

sauf si on a mis le syno en DMZ sur la box. ou si on a redirigé certains ports de la box vers le syno et que l'on veux filtrer les chinois par exemple...

ménonménon: pour les paquets entrants, c'est l’adresse *cible* qui est nattée, l'IP source est inchangée (un simple tcpdump te convaincra) et donc ma solution fonctionne.

Euh, la config firewall dans l'interface web du syno n'est rien de plus qu'un GUI de modification des iptables tu sais?

Autre solution plus simple, avec une seule règle à ajouter. (Déjà vue ici me semble-t-il est et confirmée dans le forum syno) Ajouter en fin de liste une règle de type "refuser" mais au lieu de cocher "tous" dans la rubrique "ports", aller dans "sélectionner" et tout cocher seulement à cet endroit. et mettre "autoriser acces" dans "si aucune règle ..."

Une solution de contournement à ce problème a été proposée dans le forum synology : (ref: http://forum.synolog...tart=15#p183555) Mettre ceci dans /etc/rc.local: iptables -D INPUT -i eth0 -j DROP iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i eth0 -j DROP

Et que dit l'aide en ligne de la V4.0 sur ce point?

Je pensais plutôt qu'il faut surtout tenir compte de l'ordre des règles (de haut en bas). La première qui "matche" est appliquée. Si c'est un "accept" le flux est autorisé même si il y a un "deny" un peu plus bas. D'ailleurs c'est confirmé par l'aide en ligne:

Ce que je peux te proposer c'est ajouter deux règles dans le firewall en début de liste. Une première qui laisse passer tous les flux pour le réseau local, toujours active Une suivante qui bloque tout, activable a la demande Comme ceci: Suffit de cocher la case entourée de rouge pour bloquer tous les flux externes. A toi de configurer correctement l'ip et le masque de la 1ère règle afin que cela corresponde au plan d’adressage de ton lan.

La gestion du Synology se fait avec un navigateur en http Par conséquent, que le navigateur utilisé tourne sous Windows, Linux, MacOs ou n'importe quoi d'autre ne changera pas grand chose