Mic13710

Je n'ai pas dit qu'il ne fallait pas faire de réservation d'IP, c'est même fortement recommandé. Mais la réservation ne doit se faire que pour le réseau local. Or, il me semble que vous tentez de faire une réservation sur le réseau local d'un équipement distant ce qui bien évidemment ne peut pas fonctionner. Pour ce qui est des plages DHCP, lorsque vous lancez une requête et que vous êtes connecté en VPN sur un autre réseau, la recherche va d'abord se faire sur le réseau local. Si l'adresse existe, le routeur vous connecte au périphérique qui répond à la demande et la recherche s'arrête. Ce n'est que lorsque la recherche n’aboutit pas en local qu'elle va s'étendre au réseau distant. Si vous avez par exemple une adresse locale 192.168.1.10 et que vous avez la même adresse pour un périphérique distant, vous ne pourrez jamais atteindre ce dernier parce que son adresse existe aussi en local. C'est pourquoi il faut que vos réseaux, local et distant, ne soient pas sur la même plage pour pouvoir joindre tous les appareils connectés aux deux réseaux.

@Flo51 ce que vous dites là est inquiétant. Dois-je comprendre que vous n'avez pas de sauvegardes régulières de vos données et que vous comptez sur la fragilité d'un RAID0 pour les stocker ? Après, hyperbackup ou sauvegarde traditionnelle, peu importe, c'est à vous de choisir la méthode qui vous convient le mieux. Il vous faut de toute manière repartir de zéro.

Non. Si le premier disque constituant le SHR fait 6To, vous ne pouvez pas y rajouter des disques de capacité inférieure. Seulement des 6To ou plus. Et non pour le RAID0 de la deuxième question : le SHR est un RAID hybride qui combine basic, RAID1 et RAID5. En règle générale, le RAID0 ou le JBOD doivent être construit avec l'ensemble des disques. Ils ne peuvent pas évoluer par la suite.

@dom2 sous DSM7 : portail de connexion, onglet Avancé, bouton Proxy inversé

Je suis d'accord. Néanmoins, je suis dubitatif devant les résultats car quand je vois seulement 50h d'utilisation, ça me laisse perplexe. Ce disque est-il neuf ?

C'est là amha que se situe l'erreur. La réservation étant faite sur le réseau local pour une adresse sur le réseau distant, il est impossible de pouvoir se connecter. Une règle de base essentiel en matière de VPN c'est d'avoir des plages DHCP différentes pour chaque réseau pour éviter d'avoir des adresses distantes qui ne peuvent pas être résolues parce que déjà existantes sur le réseau local. Éviter les trop courus 192.168.0.x, 192.168.1.x mais prendre plutôt des plages du genre 192.168.w.x ou w peut prendre ce qu'on veut entre 2 et 254. Il faut bien entendu que w soit différent entre le réseau local et le distant.

Ah je vois, adepte du SM ! quand on aime... 😉

Toi tu cherches les ennuis. Pourquoi te faire tant de mal ? C'est de l'auto flagellation ! Au fait, est-ce que le ER-X sait gérer l'IPV6 ?

OK, merci pour le retour. Je vais considérer l'histoire du certificat unique pour les deux domaines de mon frère. Par contre, je vais garder l'API commune qui est moins compliquée à gérer. De mon côté, j'ai un ndd chez ovh et un autre chez gandi. Pas d'autre choix dans ce cas de faire un certificat par registar car le script de demande n'est pas le même (dns_ovh et dns_gandi_livedns), mais là aussi je les crée sous une seule instance docker. Le account.conf contient alors les deux API : SAVED_OVH_AK='xxxxxxxxxxxxx' SAVED_OVH_AS='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' SAVED_OVH_CK='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' GANDI_LIVEDNS_KEY='xxxxxxxxxxxxxxxxxxxxxxxxxxx'

Oui, un pour le .net et un autre pour le .com avec la même API. C'est vrai que le problème se pose avec le certificat par défaut qui est celui qui a été renouvelé en dernier. Ce n'est pas non plus très gênant car toutes les entrées de mon reverse proxy sont bien couvertes avec leur certificat respectif. Et je corrige manuellement le certificat par défaut quand je vais faire un tour dans DSM. Ca m’intéresse. C'est possible ça ? Comment fais-tu lorsque tu crées le certificat ? un truc du genre : docker exec Acme sh -c "acme.sh --issue --keylength 4096 -d 'mydomain.com' -d '*.mydomain.com' -d 'mydomain.net' -d '*.mydomain.net' --dns dns_ovh" Ca peut passer comme ça ? Si tu n'as qu'une instance, comment fais-tu la différence entre une API et une autre ? Les clés sont normalement localisées dans le account.conf de l'instance : SAVED_OVH_AK='xxxxxxxxxxxxxxxxxxxx' SAVED_OVH_AS='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' SAVED_OVH_CK='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

Absolument. Et pour les API, tu peux avoir une API chez OVH qui couvre le compte. Pratique lorsque tu as plusieurs ndd hébergés sur le même compte. Mon frère par exemple a deux domaines chez OVH, un en .com et un autre en .net. Avec une API commune, je n'ai qu'une instance Docker pour gérer les deux certificats puisque le account.conf est identique pour les deux.

Pas sûr que notre ami comprenne bien tout ça 😉. Pour être un peu plus clair, il n'y a pas un seul et unique disque bootable. Chaque disque comporte 3 partitions, une pour le système, une pour le swap et une pour les données. DSM est installé sur la partition système de tous les disques du NAS et fonctionne en RAID1. La partition swap de tous les disques fonctionne elle aussi en RAID1. C'est sur la partition des données que sont construit le ou les groupe(s) qui contiennent les volumes. Chaque groupe peut être en basic, RAID ou SHR. Chaque volume peut être en EXT4 ou en BTRFS (pour les NAS compatibles uniquement).

Ma box est en mode routeur et DMZ parce que le mode bridge de la freebox était instable (perte de connexion)

@Einsteinium Je ne me rappelle plus en avoir parlé, mais oui, j'ai un certificat par site parce que j'ai estimé que c'était plus simple de déployer le script sur chaque NAS plutôt que de faire un certificat commun. Sur un site j'ai un certificat pour ndd, serv1.ndd et *.serv1.ndd, sur l'autre pour ndd, serv2.ndd et *.serv2.ndd J'aurais pu effectivement ne faire qu'un seul certificat couvrant ndd, *.ndd, *.serv1.ndd et *.serv2.ndd et l'importer sur chaque site, mais ça m'aurait obligé à faire des manips d'importation alors que là, les sites sont indépendants et les renouvellements sont automatiques.

@CyberFril y a les barrettes officielles vendues à prix d'or sous la marque Synology (fabriquées par des boites comme Kington ou Crucial) et celles qui fonctionnent tout aussi bien chez les dit fabricants à des prix nettement plus abordables. Ensuite, les limitations données par Synology sont très éloignées de celles dont les processeurs sont capables de gérer. Par exemple, mon 713+ n'a pas d'extension donnée par Syno au delà des 1Go de la barrette installée de base. Et pourtant, j'ai 4Go de chez Kingston (à 27€ chez zonzon) et le NAS fonctionne très bien. Mon 718+ est donné par Synology comme étant extensible jusqu'à 6Go. Le mien est à 8Go et peut aller au delà si besoin. Regarde le sujet que j'ai mis en lien ci-dessus et tu verras que Synology n'a pas le monopole de la RAM.

Pourquoi tu me poses la question ? T'as qu'à ouvrir le tien et tu sauras 😄

Ouaf @Jeff777 tu imagines bien que j'y avais pensé ! Mais pourquoi pas, après tout des piles qui tombent en panne prématurément ça existe. Pour info, toutes les piles ne sont pas des CR2032. Par exemple, ce sont des CR1620 sur le 713+ 😉.

Quand tu l'auras testé, bon ou pas bon, tu pourras faire un retour sur ce fil 😉

Si vous étiez en synchro manuelle, d'une part l'horloge interne n'est pas très précise et dérive dans le temps, et d'autre part, il se peut que le passage à l'heure d'hiver ne se soit pas fait, ce qui a provoqué un décalage d'une heure. Je n'utilise plus depuis très longtemps les horloges internes, aussi je ne sais plus si elles embarquent ou non le changement d'heure selon le fuseau horaire.

Jamais eu le moindre problème après les maj de mes bornes, ni non plus sur mon routeur ER-X. Et très franchement, depuis que j'ai installé ces bornes, le Wifi se fait oublier.

Très certainement un problème d'horloge. Le 2FA étant basé sur le temps, il faut absolument que l'horloge du NAS soit synchronisée sur un serveur NTP internet.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Le RAID est seulement un moyen de stockage. Si vos données sont effacées, corrompues ou victimes d'un cryptolocker, elles le seront sur les deux disques. De même, si une cause extérieure affecte votre NAS (vol, incendie, innondation, choc mécanique), toutes ou partie de vos données sont perdues. Ainsi le RAID ne vous dispense pas de prévoir une sauvegarde périodique de vos données, au moins les plus importantes. Et pour votre question concernant mes NAS, oui, j'utilise mon 214 pour des sauvegardes en local (chez moi) et le 713 pour une sauvegarde distante.

On n'est pas obligé de remplir toutes les baies dispos. Donc oui, vous pouvez très bien démarrer avec un seul disque. La suite de votre message est plus confuse. Oui vous pouvez rajouter un autre disque dans la baie restante mais ça ne se passe pas comme vous le décrivez. Soit vous associez le nouveau disque au groupe existant et à ce moment là vous créez un RAID1 ou un SHR avec protection des données ce qui se traduit par un miroir des données sur les deux disques, soit vous créez un autre groupe qui comportera un (ou plusieurs) autre(s) volume(s) et qui rajoutera 8To de capacité de stockage sans protection des données. EN AUCUN CAS le RAID constitue une sauvegarde. C'est seulement de la continuité de service en cas de panne d'un disque. Et autre erreur : une sauvegarde n'est pas une synchro. Une sauvegarde est déconnectée de la source une fois qu'elle est terminée.

Il y a là une grosse confusion entre sauvegarde et continuité de service. Le RAID n'est pas une sauvegarde. C'est seulement un moyen de stockage qui permet la continuité de service en cas de perte d'un disque. Ce que vous souhaitez faire est tout à fait réalisable techniquement (bien que ça ne puisse pas être considéré comme une vrai sauvegarde), mais ne peut en aucun cas être comparé à un pseudo RAID comme vous tentez de le faire. La sauvegarde et le RAID sont deux choses bien distinctes, sans rapport l'une avec l'autre.