PiwiLAbruti

postinst, pas postint. Aucune idée, si ce n'est une éventuellement erreur dans le nom du script comme vu ci-dessus (postinst) Vérifie dans la documentation officielle (http://ukdl.synology.com/download/Document/DeveloperGuide/DSM_Developer_Guide.pdf), mais je je ne crois pas qu'il y ait besoin de créer de lien symbolique pour l'interface web. start-stop-status ne s'est jamais logé pas dans /usr/local/etc/rc.d. Ce script est utilisé depuis le Centre de paquets pour démarrer ou arrêter le paquet sélectionné. Pour chaque paquet, /var/packages contient des liens symboliques vers /volume{x}/@appstore. Regarde dans un des dossiers de paquet (ls -l /var/packages/paquet). De manière hénérale, je te conseille d'utiliser la page GitHub dédiée pour exposer tes problèmes : https://github.com/SynoCommunity/spksrc/issues

Si au lieu de décrire ce qui ne marche pas tu expliquais ce que tu veux faire (et comment), on y verrait plus clair. Fais déjà ce test par toi-même pour voir l'erreur éventuellement renvoyée par le serveur FTP. Le compte anonyme n'existe pas sur un NAS Synology. Essaye avec le compte guest (vérifie avant que ce compte est bien activé).

Non, ce n'est pas une limite technique ni vraiment de la sécurité. Utiliser un port externe différent du port interne permet de moins exposer le NAS sur internet et donc de limiter les scans et les tentatives d'intrusions qui s'en suivent.

Si tu peux. Mais dans le cas de SSH (et d'autres services comme le DSM sur tcp/5000), tu exposes ton NAS aux scans automatiques sur ces ports et aux tentatives d'intrusions. C'est d'ailleurs ce qui a servi de porte d'entrée au dernier ransomware qui cryptait les données des NAS Synology. Si tu as une sauvegarde de ton NAS, ça n'a pas trop d'importance. Sinon tu risques éventuellement une perte irréversible de tes données comme certains l'ont récemment subie.

Ça veut dire par exemple rediriger le port tcp/55022 externe vers le port tcp/22 du NAS. Ainsi SSH est accessible sur le port tcp/55022 depuis l'extérieur du réseau.

Non, pas forcément. Si tu avais regardé les messages qui précèdent le mien, tu aurais vu qu'il s'agissait d'utiliser un port différent pour un service donné.

L'accès au SSH de ton NAS depuis l'adresse VPN ne passe pas par le NAT de ta box, comme pour tous les autres services du NAS d'ailleurs. Autrement dit, SSH est directement accessible sur le port 22. Il faut aussi bien avoir conscience que le pare-feu du NAS est inopérant dans cette situation. Sur le VPN, ton NAS est autant accessible qu'en réseau local, sans aucune sécurité.

Le double NAT, j'en connais qui laissent des gens sécher dans leur grenier pour avoir osé une telle infamie...

De mon point de vue, la solution la plus propre est d'utiliser le routeur comme un switch en ne branchant rien sur la prise internet. Attention à n'avoir qu'un seul serveur DHCP actif (celui de la box ou du routeur mais pas les deux). Cette solution ne nécessite pas d'activer une DMZ, ni d'acheter un point d'accès.

Qu'elle est l'utilité du routeur derrière la box ?

Un exemple concert est l'iDRAC de chez DELL : http://accessories.us.dell.com/sna/productdetail.aspx?c=us&l=en&s=bsd&cs=04&sku=331-6956 Pour en revenir au sujet, je vois mal Synology ajouter ce type de module sur un DS213j juste pour du démarrage à distance...

Ça me semble quand même bizarre car j'arrive très bien à le faire fonctionner sous Windows 7. Je vais vérifier les paramètres de la base de registre, des fois qu'il y aurait eu d'autres modifications à faire.

La seule différence serait alors un pare-feu au niveau du client.

Ça ne risque pas de fonctionner avec IPKG pour une architecture 88f628x, et je ne crois pas que IPKG soit compatible avec l'architecture du DS214se (armada370).

Dans la très grande majorité des cas, il faut utiliser TCP. Si un port doit être configuré en UDP, ça sera précisé (https://www.synology.com/fr-fr/support/faq/299).

Très exactement Ce n'est pas de la sécurité mais ça permet de limiter la détection par des scans réseau (un truc du style nmap -Pn -sS -p 5000 a.b.c.x-y). De ce que j'en ai vu, les victimes de SynoLocker avaient au moins le port tcp/5000 ouvert. Maintenant comme il s'agissait d'une vulnérabilité du DSM, le changement de port ne comble pas la faille mais ça évite qu'elle soit trop exposée. À ton niveau tu peux considérer que si aucun port n'est ouvert, les attaques depuis l'extérieur sont quasi-impossible (mais on n'est pas à l'abri d'une faille du routeur, ce qui reste tout de même assez rare). À partir du moment où tu ouvres un service sur internet (DSM via port tcp/5001, FTP via port tcp/21, ...), il faut avoir confiance dans la robustesse du service en question.

Oui, il faut juste que tu choisisses un nombre supérieur à 1024. La liste des ports déjà utilisés est affichée dans les règles NAT de ta box/routeur.

L'erreur 809 correspond à un problème d'accès aux ports. Vérifiez que les ports udp/1701, udp/500, et udp/4500 sont bien configurés sur le routeur du serveur et qu'ils ne sont pas bloqués dans le pare-feu du client et du serveur.

À moins que d'autres machines soient connectées en permanence à l'EDS14, le changement de configuration réseau à peu d'importance.

Sur chaque disque il y a une partition de 4 Go où est installé le DSM. Ce dernier est synchronisé entre tous les disques quelque soit la cartographie choisie (SHR, RAID, JBOD, basic, ...). On peut considérer ça comme une bande RAID 1 de 4Go similaire à ce que fait Synology avec SHR pour l'optimisation de l'espace disque. Maintenant c'est totalement transparent pour l'utilisateur.

Je te conseillerais d'utiliser spksrc pour faire ton paquet. Tu auras à ta disposition tous les outils pour cross-compiler mkvmerge (et autres) pour toutes les architectures des NAS Synology. De plus, tu bénéficiera de la diffusion de ton paquet sur SynoCommunity.

Ça fait plaisir de voir de nouveaux utilisateurs être capable de juger par eux-même de l'utilité du RAID ou non et d'en comprendre les contraintes. C'est une fausse bonne idée. Il a été prouvé récemment que non à cause d'une faille que Synology a pourtant corrigée en décembre 2013 par une mise à jour du DSM (toutes versions concernées). Les NAS qui n'étaient pas à jour on subit un cryptage irréversible des données de tous les disques présents dans le NAS ou branchés au NAS. Pour ceux qui sauvegardaient leur données sur un autre disque interne du NAS, ces dernières ont également été impactées par le cryptage. Non seulement les données ont été perdues, mais les sauvegardes également. Pour plus d'informations sur ce fléau, je te renvoie vers le site de Synology : https://www.synology.com/fr-fr/company/news/article/472 Donc la plus simple des solutions est de sauvegarder sur un disque USB externe qui ne doit être branché au NAS que le temps de la sauvegarde. Ainsi, peu importe ce qui se passe sur le NAS, les données sauvegardées sont bien au chaud sur un disque séparé au fond d'un tiroir.

Ou mieux, restreindre l'accès à ce port en créant une règle de pare-feu qui n'autorise que l'adresse IP de la machine distante à accéder à ces ports (tcp/22 et tcp/873). Le VPN est aussi une solution mais l'encapsulation risque de dégrader les performances sur des connexions à petit débit (c'est relatif au volume à transférer évidemment).

Moi pas savoir lire Môais donc c'est vraiment pour de l'appoint car je vois mal ce type de produit stocker 3 mois de vidéo HD généré par 5 caméras... Bref, rien à voir avec ce que Sym a décrit de son utilisation.