Mic13710

Vous êtes sûr qu'on parle de la même chose ? Wireguard est encore à la version 1 et la dernière mouture est toute récente puisqu'il s'agit de la v1.0.20250531 soit du 31/05/2025. Quant au client Windows v0.5.3 Alors là, je suis perdu. Docker sur un 214 ? Impossible. Salut @Lelolo je crois que vous avez un language de sourds avec @cubitus_syno c.a.d. d'avoir Wireguard sur la Livebox, pas sur un routeur séparé comme nous avons toi et moi. A ma connaissance, il n'y a guère que les Freebox qui embarquent un serveur et un client Wireguard.

Je ne connais pas d'interface web wireguard. Sauf erreur, la seule interface est le client officiel Wireguard. Et à moins que j'ai raté un truc, il n'y a pas à ma connaissance de sécurisation de la connexion Wiregard par mot de passe. Donc, je ne comprends pas bien la phrase ci-dessus. Pour ma part, j'utilise wireguard mais le serveur est installé sur mon routeur, pas sur le NAS. Si ce dernier peut faire office de serveur VPN (sans wireguard malheureusement), ce n'est pas le meilleur endroit pour cela. Si le NAS tombe en panne par exemple, adieu le VPN et la connexion au LAN. A mon avis, il est préférable de dédier cette tâche à votre routeur, et si ce n'est pas possible, un Rasp fera très bien le taf, sera mieux adapté à cette fonction et surtout bien plus facile à mettre en oeuvre que Docker. Donnez moi l'adresse de la poubelle 😉

Il faudrait commencer par nous dire ce que vous avez fait. Sans explication cette phrase ne veut pas dire grand chose.

En ext4 ??? Votre NAS est en BTRFS en natif et bon nombre d'applications nécessitent ce format pour fonctionner sur votre NAS. Alors pourquoi ce choix de l'EXT4 ?

La liste n'est plus mise à jour car il s'agit d'un ancien modèle. Et les disques ne sont plus commercialisés pour bon nombre d'entre eux. Les deskstar sont des Hitachi. Ce sont en général de très bons disques mais depuis leur rachat par WD, j'aurais tendance à penser que les gammes s'harmonisent.... Les anciens NAS sont assez tolérants sur les disques, beaucoup plus en tout cas que les derniers modèles. Je ne peux que vous suggérer de vous tourner vers des disques qui sont compatibles avec des NAS séries J ou standards plus récents que le votre. Et surtout, ne prendre que des disques en techno CMR (pas de SMR !).

Pour que ça fonctionne avec un nom de domaine au travers de wireguard ou de n'importe quel autre VPN, il faut qu'il y ait une résolution locale de l'URL et un reverse proxy pour diriger la requête vers le service demandé, ici votre application docker. Sans cela, c'est l'adresse que vous utilisez localement qu'il faut prendre. Vérifiez aussi que Wireguard autorise toutes les IP à traverser le VPN (allowedIPs = 0.0.0.0/0). Il faut que le parefeu du NAS autorise les IPs de Wireguard (10.x.x.x/xx). Mais pas en https je présume, que ce soit localement ou à distance sauf à faire une exception. Ce qui signifie que le certificat n'est pas sollicité et/ou qu'il ne couvre pas le ndd. Pour cela, il faut mettre une règle dans le reverse proxy qui dirige https://xxxx.myds.me port 51821 vers localhost et le port de votre application docker. Ce serait d'ailleurs plus simple d'utiliser le port 443 dans le reverse proxy avec un nom de domaine dédié, par exemple : https://votreapplication/xxx.myds.me port 443 vers localhost et le port de votre application. Je vous conseille d'aller faire un tour dans la section des tutoriels et de regarder le tuto sur le serveur DNS et celui sur le reverse proxy.

Je ne suis pas sûr de bien comprendre ce que vient faire un xxxx.fr dans un certificat qui n'est pas le sien. Un redirection c'est dans la zone du xxxx.fr que ça se fait, pas dans la zone de destination. Bref. Est-ce que vous arrivez à joindre https://xxxx.myds.me:51821/login lorsque wireguard est désactivé ?

Un certificat n'a aucun rapport avec les ports. Il ne s'applique qu'à un nom de domaine et ses éventuelles déclinaisons (nom en dur ou wildcard). Et comme je viens de l'écrire, un certificat ne concerne qu'un seul nom de domaine, vous avez une incohérence dans le votre puisque dans la liste de votre certificat xxxx.me, se trouve des domaines xxxx.fr qui ne peuvent être couverts par ce certificat. Vous devez créer un certificat pour votre ou vos xxxx.fr.

C'est impossible. La réallocation des secteurs est une gestion interne du disque. Par contre, s'il y a des erreurs sur les données, elles seront bien évidemment reconduites sur le groupe. Je note au passage que le nouveau disque n'est pas dans la liste des compatibles avec votre modèle de NAS. https://www.synology.com/fr-fr/compatibility?search_by=drives&model=DS415play&category=hdds_no_ssd_trim&filter_brand=Western Digital&filter_size=4TB Cela peut poser des problèmes de fonctionnement dans un groupe (c'est assez rare). Ce n'est pas du tout ce qui peut justifier les secteurs défectueux. Et même si vos disques étaient très fortement sollicités, ça ne pourrait pas engendrer des pertes aussi rapides et récurrentes. Vu les défaillances à répétition, il faudrait se poser la question sur la qualité de l'environnement du NAS. Est-ce qu'il est soumis à des vibrations, des chocs, des variations brutales de températures ou des températures excessives ?

Drôle de question. Si vous voulez atteindre le NAS en FTP, il faut bien indiquer l'adresse du NAS pour diriger le port 21 mais pas que (il faut aussi les ports passifs) et pour pouvoir rediriger vers la bonne adresse, il faut que l'IP du NAS soit réservée dans le routeur. Par contre, niveau sécurité, le FTP c'est pas le top. Je vous conseillerais plutôt le SFTP.

Ce qui veut dire ? Il vaudrait mieux pouvoir y accéder pour effectuer les réglages nécessaires au bon fonctionnement du NAS depuis internet. Sinon, il reste Quickconnect, mais là.... c'est une autre histoire.

Est-ce que j'ai dit " à la place de" ? Quand j'écris "en toute fin de fichier", c'est exactement ce que ça veut dire : en toute fin de fichier

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.

Si vous avez tout mis en vrac à la fin du fichier, normal que ça ne fonctionne pas. data-ciphers-fallback AES-256-CBC vient à la place de : cipher AES-256-CBC auth-nocache est à placer avant <ca> et, #verify-x509-name '<votre e-mail>' name #ligne ci-dessus générée par le fichier de configuration #remplacée par verify-x509-name '<Le nom du certificat qui couvre le vpn>' name est à placer en toute fin du fichier

N'est ce pas ce que j'ai dit ? Vous devez avoir en fin de fichier : </tls-auth> Et bien c'est là. Pour le reste, avez-vous suivi les pistes de recherches proposées dans le Tuto ?

Rien de choquant à priori. 3 petites choses à corriger : # instruction cipher supprimée et remplacée par data-ciphers-fallback AES-256-CBC # pour supprimer le warning à l'ouverture de la connexion # cipher AES-256-CBC data-ciphers-fallback AES-256-CBC et : auth-user-pass # la ligne suivante a été rajoutée pour supprimer l'alerte sur le client # this configuration may cache passwords in memory auth-nocache <ca> et en fin de fichier : </tls-auth> #verify-x509-name '<votre e-mail>' name #ligne ci-dessus générée par le fichier de configuration #remplacée par verify-x509-name 'certificat.vpn' name Mais ce sont des modifs mineures qui ne devraient pas changer fondamentalement les choses. L'IP 10.5.0.1 n'est elle pas bloquée dans le module sécurité ? Il faudrait rajouter la plage du VPN dans les IP autorisées pour éviter les blocages. A quoi sert le port 32400 ? Est-ce que le certificat a bien été associé au serveur VPN avant l'activation et la création de la partie Open VPN ?

Est-ce que la plage d'IP privée 10.0.0.0/255.0.0.0 est autorisée dans le parefeu , ou au minimum la plage de votre VPN, pour vous 10.5.0.0/24 ou encore plus restrictif 10.5.0.1 à 10.5.0.6 ? Si oui, essayez en désactivant temporairement le parefeu. Il faudrait aussi donner une copie du fichier de conf en masquant les données personnelles.

Si vous ne donnez pas accès au LAN, vous ne pouvez pas accéder au NAS par son IP LAN et votre serveur DNS local ne peut pas non plus être utilisé puisqu'il n'est pas accessible. Le seul accès disponible est via l'IP du VPN soit 10.5.0.1:5000

Si ça concerne le tuto DNS serveur, vous poursuivez la discussion sur le tuto. Sinon, vous ouvrez un nouveau sujet dans la section qui concerne le serveur DNS.

@Wilfred Merci de ne pas citer l'intégralité des messages auxquels vous répondez. Ca n'apporte rien et surcharge inutilement le fil de discussion. Uniquement l'IP de votre serveur DNS, donc celui du NAS. Vous ne renseignez pas un autre serveur si vous n'en avez pas. C'est le serveur DNS qui se chargera de rediriger les requêtes externes.

Il faut indiquer le ou les serveurs DNS dans le fichier de configuration : # dhcp-option DNS: To set primary domain name server address. # Repeat this option to set secondary DNS server addresses. dhcp-option DNS <IP DNS serveur 1> dhcp-option DNS <IP DNS serveur 2>

@Lelolo tu m'étonnes ! La liste de la série 14 et à moins qu'elle soit incomplète :

@arsenelupin44 c'est votre phrase qui laissait penser que le ext4 ne permettait pas d'utiliser Drive alors que ce n'est pas le cas. Sinon, on est d'accord sur la différence de fonctionnement entre EXT4 et BTRFS.

Il faudrait tout de même préciser si vous compter garder les disque du 214 ou si vous envisagez d'en mettre des neufs (ce n'est pas dit dans votre message) Non. Vous pouvez très bien importer des données sauvegardées plus classiquement. Simplement, hyperbackup permet de migrer aussi les applications et leurs paramétrages ce qui simplifie la reconstruction. Le BTRFS est le système de fichier par défaut sur le 723. C'est aussi indispensable pour utiliser certaines applications comme snapshot replication par exemple ou bien Active Backup for Business et bien d'autres. Le système de fichier concerne la gestion des fichiers sur le disque, pas les données elles mêmes. Je ne pense pas non. Le besoin de double capacité c'est lorsque vous faites une restauration via hyperbackup puisque vous importez le fichier de sauvegarde et vous le restaurez sur le NAS. Mais on peut aisément contourner le problème en faisant de petits fichiers hyperbackup (un pas dossier partagé par exemple) plutôt qu'un seul sur la totalité. Tout à fait, et c'est même très bien d'avoir 2 sauvegardes distinctes de vos données car il peut arriver qu'une restauration ne fonctionne pas et il est plus rassurant de pouvoir compter sur une autre source. Ce qui est encore mieux c'est de séparer physiquement les deux supports, le tout sous le même toit n'étant pas recommandé. A titre perso, j'ai deux sauvegardes, une locale et une distante. Les deux sont décalées avec une le mercredi et une autre le dimanche. En cas de problème chez moi (incendie, inondation ou autre, je peux compter sur la deuxième sauvegarde pour retrouver mes données. Puisque la sauvegarde est cruciale pour vous (et vous avez entièrement raison d'y attacher de l'importance), le 214 pourrait vous servir de second support de sauvegarde 😉

Bonjour @arsenelupin44, soyez le bienvenu sur le forum. Je ne comprends pas bien ce que vous voulez dire. Drive fonctionne en ext4 et btrfs. C'est seulement la gestion du dossier caché qui impose d'avoir de l'espace de stockage. Mais bon, là n'est pas le propos. 😉