magicIdea

Alors, dans mon cas de figure, le certificat (fichier ca.crt) a été recréé automatique. Le volume du fichier a doublé. Il fait maintenant environ 2 kb au lieu de 1 kb auparavant. Je pense que le niveau de cryptage par défaut a été élevé (1024 à 2048 ?). Niveau NAS, pas de problème. Le serveur openvpn fonctionne parfaitement. Il faut juste réinstaller le certificat sur tous les clients (iPhone, Pc, etc). Après la mise a jour des clients, tout fonctionne à nouveau correctement.

Update installé. Ok. Juste un problème avec openvpn, le certificat n'est plus reconnu, lorsque le client tente de créer le tunnel. Je vais voir.

si les fichiers sont copiés, que le partage avec la même clé est monté sur la machine de destination, c'est probablement une problème de permission je confirme que ca fontionne très bien, la récupération se fait sur la machine de destination, ou sur une nouvelle machine pour simplifier la copie/gestion de fichiers en mode console, je conseille l'utilisation de GNU Midnight Commander, qui permet aussi de facilement adapter les permissions (CHMOD)

http://openclassrooms.com/courses/reprenez-le-controle-a-l-aide-de-linux

Dans la partition système, à la racine. On ne voit pas la partition système depuis la console d'administration. Il faut y accéder via telnet ou ssh, service qui doit être activé par la console d'administration. Techniquement, le NAS fonctionne sur une distribution Linux. Les commandes sont donc les mêmes que pour toute machine Linux (accès, modification, exploitation). Si vous ne connaissez pas bien Linux, je vous conseille de vous documenter avant de vous lancer.

Nom du répertoire: etc/ssh/ Nom du fichier: ssh_config

etc/ssh/ssh_config

Rsync ne va que dans un sens. L'avantage de rsync, c'est qu'il va seulement envoyer ce qui a changé. Autrement, il est possible d'utiliser FTP pour pousser les données sur un service Web, automatisé via un script. Autre possibilité, rattacher au NAS un disque dur externe et utiliser le logiciel de backup fourni. Désavantage : les données ne sont pas externalisées en cas l'incendie ou autre.

Non. C'est bien dans le fichier ssh_config qu'il faut intégrer ces deux lignes. Si le fichier n'existe pas, il faut le créer et y insérer ces lignes. Attention : quant on fait un rsync distant, il y a deux machines impliquées (ça peut être deux NAS par exemple). La machine serveur, qui va être à l'écoute de la requête et la machine cliente, qui pilote l'opération et lance la requête rsync (le backup Synology utilise aussi rsync). Le fichier à rajouter, s'il n'existe pas, doit l'être sur la machine cliente. Sur la machine serveur, pas besoin de rajouter l'information. C'est le client qui est en charge de maintenir la connexion aussi longtemps qu'il en a besoin, pour éviter justement un time out au niveau du serveur. Pour info, j'avais également rencontré des problèmes de time out avec, souvent, de gros fichiers. Rajouter ces paramètres a totalement résolu ma problématique et le transfert, selon les nuits, fait pratiquement 1 To (oui, ca prend quelques heures). Ca tourne parfaitement depuis plus d'une année, que ce soit sous DSM 4.3.x ou 5.0.x

Installé sur deux machines. Pas de problème.

Une commande rsync lancée par un cron job.

Je confirme que ça marche très bien. Je conseille l'utilisation de cette fonction. J'ai des centaines de GO dans des partages crytés, aucun problème.

Rsync fonctionne très bien, même pour des centaines de GO. Pourquoi ne pas l'utiliser ? Pour le premier run, pour gagner du temps, placer les deux machines sur le même LAN, avec les deux cartes configurées en GHz. Puis déplacer la machine cible sur l'emplacement final. Rsync fonctionnant en incrémental ensuite.

C'est probablement un problème de timeout. Pour maintenir la stabilite de la connexion SSH over SSL, il faut rajouter dans le fichier etc/ssh/ssh_config les entrées suivantes: ServerAliveInterval=30 ServerAliveCountMax=50

Pas besoin de duplifier sur le NAS. En choisissant dossier crypté dans DSM, les fichiers du partage sont cryptés automatiquement. Lorsque le partage est monté lors du démarrage du NAS (automatique par défaut), le NAS donne accès à une version décryptée. Ce n'est pas une copie, c'est une vue sur le répertorie crypté, décrypté à la volée. Avec les outils de backup Synology, la version décryptée à la volée est lue et sauvegardée sur l'autre NAS en version non cryptée. Ca a deux défauts : - sur le NAS cible, les fichiers sont en clair - pendant le transfert, ce sont des fichiers non crypés qui passe sur internet, même si la liaison est sécurisé en soit Le fait d'envoyer les fichiers cryptés (via une commande rsync over SSH) augmente nettement la sécurité de cette opération sur internet et permet de retrouver les fichiers synchronisés de façon cryptée sur le NAS cible. Ainsi, sur le NAS cible, si le partage n'est pas monté automatiquement, les fichiers ne sont pas lisibles par des tiers, même s'ils devaient, pour une raison ou une autre, avoir accès aux fichiers.

Oui. Il faut d'abord crypter le partage sur le NAS source. Puis utiliser la commande rsync, en tant qu'utilisateur root sur le NAS source, pour pousser le contenu / les modifications sur le NAS cible. En fait, avec rsync, si on choisit de transférer le répertoire contenant la version cryptée des fichiers, les fichiers ne sont jamais ouverts. Ils sont transférés tels quel, donc en mode cryptés. Donc pas de problème lors du transfert, même en passant par une liaison internet, non sécurisée. Et sur le NAS cible, les fichiers ne sont pas lisibles. Pour les lire, il faut monter un partage et saisir la clé de décryptage (le mot de passe).

J'ai aussi constaté ceci. D'un côté, c'est logique, puisque Time Backup ne peut pas accéder au contenu du fichier et vérifier s'il a changé. Mais en principe, quant il y a modification d'un fichier chiffré, il y a forcément déchiffrement à la volée pour la lecture, modification, puis chiffrement à la volée pour le stockage. Peut-être que Time Backup n'arrive pas à faire le lien entre l'ancien fichier, chiffré, avant modification, et le nouveau fichier, chiffré, après la modification. Reste que la fonction de backup sauvegarde parfaitement les fichiers cryptés (dans l'état, c'est-à-dire cryptés). Et avec l'option incrémental, la fonction doit bien voir s'il y a eu changement au niveau du fichier. Alors si quelqu'un a la solution ?