Mic13710

Euh.... Ca c'est la zone privée du côté du serveur DNS du NAS. Je parle moi de la zone publique, celle enregistrée chez ovh. Une remarque, en regardant votre zone privée, je ne vois pas d'enregistrement de type ns. Vous devriez avoir un ndd.ovh ns ns.ndd.ovh. A moins qu'il soit en bas de page, il faudrait l'ajouter.

Non plus. En fait, le serveur VPN établi un tunnel avec son client. Si votre serveur est le NAS de Madrid, alors il n'est pas possible de joindre les équipements de Paris car VPN Serveur sur le NAS ne permet pas l'accès du client vers son réseau local. Par contre, le client lui peut accéder au réseau privé du serveur à la condition bien entendu que ce soit autorisé dans ses paramètres. Pour pouvoir accéder au réseau local du client, il faut passer par un serveur VPN qui permet ce type de connexion, mais il n'est pas disponible sur les NAS Synology, uniquement sur leurs routeurs. Il s'agit du serveur VPN plus. Ceci étant, je m’aperçois que j'ai fait une erreur entre serveur et client dans mon explication plus haut. J'ai corrigé.

Toutes les freebox ont effectivement un dhcp par défaut en 192.168.0.0/24. Mais rien n'empêche (et je le conseille vivement) de changer cette plage pour justement éviter le genre de problème que vous rencontrez. En effet, si deux équipements ont la même adresse sur chacun des réseaux, il sera impossible de joindre l'équipement distant car l'adresse pourra être résolue localement. En changeant la plage, ce problème n'existe plus (ou alors il faudrait être peu chanceux pour se retrouver avec des plages identiques). Ainsi, au lieu d'utiliser la plage par défaut, vous pouvez très bien utiliser par exemple la plage 192.168.140.0/24. ou tout autre valeur entre 2 et 254. C'est très simple à faire sur une Freebox. Attention toutefois de bien vérifier avant de modifier le réglage que tous les équipements du réseau sont tous en DHCP (surtout le NAS) et non pas avec une IP en dur sinon ces équipements seront inaccessibles après le changement !

Quel que soit le protocole. Le VPN ne fait qu'établir un tunnel entre deux machines.

Pour que l'adresse dsm.leg*****.ovh soit résolue, il faut qu'elle existe dans la zone soit par un enregistrement A ou un CNAME. Apparemment, vu le retour, cet enregistrement n'existe pas, d'où le résultat. Vérifiez votre zone qui devrait comporter soit un enregistrement en dur du ndd dsm.leg.... ou un wildcard *.leg....

Non. La seule adresse en 10.2.0.x est attribuée au client par son serveur. C'est ensuite le serveur qui établi une passerelle vers son réseau local en 192.168.x.x qui permet d'accéder aux équipements du réseau local. Même s'ils sont accessibles via le VPN du NAS ces équipements ne sont pas sur le réseau VPN et n'ont donc pas d'adresse attribuées pas le serveur VPN.

Il y a t'il une raison particulière pour utiliser le serveur DHCP du NAS plutôt que celui du routeur ? Et dans ce cas, est-ce que celui du routeur est bien désactivé ? Il n'était pas question au départ du serveur VPN du NAS ? Si je comprends bien celui-là c'est celui du NAS. Vous avez donc 2 VPN activés sur le même réseau (routeur et NAS) ? Avez-vous essayé avec l'IP privée du NAS (192.168.x.x:5000) ou du serveur VPN (10.x.x.x:5000) ?

Je ne comprends pas bien votre problème de port. Comme le fait remarquer pluton212+, il faudrait commencer par demander une ip full stack à free. Ensuite, passer par la configuration du routeur via le NAS n'est vraiment pas une bonne idée. Si vous devez faire des redirections, c'est au niveau du routeur et seulement là qu'il faut les faire. En reprenant votre message précédent, si vous voulez utiliser un port exotique, il faut l'indiquer dans les paramètres d'openVPN. Or vous avez indiqué le 1194. Du coup le NAS ne peut pas se connecter si vous essayez de le joindre avec un autre port.

Que vient faire le port 40641 dans cette histoire alors que le port spécifié dans le NAS est le 1194 ? Remplacez le par le 1194 et ça devrait fonctionner.

@Boukille il existe une section présentation sur ce forum dans laquelle on apprécie que les nouveaux membres viennent faire la leur. Il n'est pas trop tard. Casser le SHR sans perdre les données peut se faire en ligne de commande. Attention, ce n'est pas sans risque et comme pour toute opération sur l'organisation des disques il faudra mettre vos sauvegardes à jour avant de procéder. Voir ce tuto.

De ce que je comprends, le disque est neuf et non formaté Ca sent le disque HS. Pour moi c'est retour au fournisseur. @tamtam59 il existe une section Présentation sur ce forum et on apprécie que les nouveaux membres aillent y faire la leur. Certains y sont sensibles.

@PiwiLAbruti, heureusement, ton déterrage échappe au top 10 😆 J'avais un peu laissé tombé et j'en ai surement laissé passer, mais rassures-toi, il y en aura... comme je le disais plus haut, les forumeurs ont des ressources insoupçonnées. La seule limite est le plus ancien dernier message. On s'en approche.

S'il s'agit d'une ip précise, vous pouvez ajouter une règle avec l'option refuser. Il faut au minimum qu'elle soit placée avant les règles d'autorisation des ip externes. Vous pouvez la mettre carrément en tête de liste pour être sûr.

C'est une question de gestion raid. Le RAID et le SHR sont construits différemment et il n'est pas possible de passer de l'un vers l'autre. Le choix qui est fait au départ (SHR par défaut, ou RAID classique) est irréversible. Sans rentrer dans les détails, le SHR est un RAID classique (mdadm) sur lequel a été greffé une gestionnaire multiraid (lvm2). Et dans votre configuration actuelle en 4, 4, 4, 6, le SHR ne vous procurerait aucune augmentation de votre stockage. Il faudrait pour cela remplacer un des 4To par un 6To pour pouvoir utiliser les 2To inutilisés.

@Dr.Genova avant de décréter la mort du NAS et envisager son remplacement, il faudrait vous assurer que le problème ne vient pas tout simplement de l'alimentation. Ensuite, vous pouvez tenter la réparation avec une résistance de 330 ou 470ohm comme indiqué dans le lien en haut du fil.

@Aerlas je plussoie la proposition de maxou56. Le NAS va couiner un peu à cause du groupe dégradé. Il faut espérer qu'aucun disque ne tombera pas en panne pendant la sauvegarde. Mais ce sera aussi le cas si vous positionnez le disque dans le 413. C'est un peu la fuite en avant votre organisation de disques. Il vous fallait un 12To pour l'associer au 12To existant. Vous y rajoutez un 14To, ce qui fera 2To inutilisés. Pour suivre la logique, je pari que le prochain disque sera un 16To ... 😉 Les connaisseurs du SHR apprécieront le beau mélange hybride de RAIDs

@Kramlech je pense que dans son explication @angel060 a voulu parler du répertoire Homes.

Par curiosité, peux-tu me dire pourquoi ? Je suis sous DSM7, mon portail web est toujours en Nginx, le reverse proxy fonctionne bien et je n'ai pas noté de dysfonctionnement.

Je ne sais pas ce que vaut le Wifi 6 du point de vue portée. Est-ce que le AX55 supporte aussi le 5Mhz et le 2.4Mhz ? Ceci pourrait en partie expliquer le manque de performance à distance, mais pas que. Ma seule expérience avec du TP-link n'a pas du tout été convaincante, ou plutôt si, j'ai été convaincu que c'était de la daube. Depuis que je suis passé chez Ubiquiti/Unifi, ça roule et mon réseau se fait tout simplement oublier.

Peut-être que cela vous donnera une piste https://www.nas-forum.com/forum/topic/55281-soucis-sur-les-atom-c2000-panne-programmée-des-modèles-rs2416-rs2416rp-rs815rs815rp-ds2415-ds1815-ds1515-ds415/#comment-1319318374

Il faut activer l'accueil utilisateur dans Utilisateur/Avancé

un NAS contre un NAS, c'est équitable comme échange .... 🤣 Moi j'échange contre un 710+ avec ses accessoires et son emballage d'origine

C'est en effet contradictoire. En regardant la liste totale, il y a même des NAS à tiroirs en série 12 (plus anciens donc) qui sont donnés comme étant compatibles. Comme c'est Synology qui le dit, le mieux serait de leur poser la question.

Bonjour, soyez le bienvenu dans la communauté. Est-ce le côté rebelle qui vous fait écrire en gras ? ça pique un peu les yeux ! Ce serait en effet dommage d'utiliser un 920+ que pour de la sauvegarde 😉

Absolument, à condition bien entendu que le versionning soit activé. Il m'est d'ailleurs très souvent arrivé d'aller récupérer dans Drive un fichier supprimé. Mais, même avec le versionning, Drive n'est pas une sauvegarde au sens strict du mot puisque les dossiers serveur/clients sont synchronisés. Il faut impérativement le doubler d'une vraie sauvegarde périodique. Et je peux confirmer par du vécu que c'est important. Il m'est en effet arrivé d'aller puiser dans les sauvegardes des fichiers Drive qui ont été écrasés. Si par exemple quelqu'un supprime un fichier mais se ravise et crée un autre fichier portant le même nom, la version encore présente dans Drive sera irrémédiablement supprimée. Pas d'autre choix dès lors que d'aller puiser dans la sauvegarde.