.Shad.

Tu as beaucoup de données ? Tu n'as pas plus vite fait d'enregistrer tout sur un disque externe, et faire une installation from scratch en brefs avec tes deux disques en SHR ? Tu peux toujours exporter la config de DSM avant de reset et la réimporter apres.

Bienvenue 🙂

Ca c'est ce qu'on met dans /etc/fstab pour faire un automount au démarrage du rpi. Tu dois plutôt tester ça : sudo mount -t cifs -o vers=3.0,credentials=/home/pi/.smbcred //192.168.1.12/documents /mnt/nas/documents Justement ne pas mettre vers=1.0, pour voir si ça marche en SMB3 avec un Linux.

Pas d'infos plus précises dans /var/log/messages ? Sur aucun des 3 NAS ?

Est-ce que tu peux essayer un montage SMB depuis une distrib Linux ?

Et il y a certains paramètres pour lesquels on est obligé de passer par SSH, genre par exemple définir les comptes habilités à se connecter à la partie Admin du serveur ? ou définir un serveur SMTP pour l'envoi de mails ? Après ce n'est pas foncièrement différent, et ça consomme beaucoup moins de mémoire, par contre attention, certaines fonctionnalités ne sont pas implémentées : https://github.com/dani-garcia/bitwarden_rs/issues/246

Oui ça devrait marcher, s'il a bien associé nas.ndd.net chez son registrar à son IP, dynamique ou statique. Mais avec la redirection HTTP -> HTTPS (voir son dernier post), ça tente de l'amener sur le port 5001, qui lui n'est pas redirigé, à mon avis ça coince par là. S'il décoche cette option, je pense que ça marchera, tout autre problème mis de côté. Mais il faut qu'il abandonne l'idée d'utiliser https://nas.ndd.net pour accéder au NAS tant qu'il n'a pas mis en place un proxy inversé. @PiwiLAbruti : Je pense qu'il était question d'accéder à son NAS depuis l'extérieur dans cette question, non ? Dans ce cas-là c'est juste sa zone DNS qui doit être bien réglée. Sauf s'il est héberge aussi sa partie publique, mais ce n'est pas clair dans ses propos.

Si on garde précieusement le code de récupération, c'est intéressant en effet ! Car si ton portable tombe en rade ou qu'il faille le reset usine, t'es bien embêté 😛

Le moyen le plus sûr de protéger les données comme l'a dit @maxou56 est d'avoir une porte 5 points de verrouillage, d'une bonne épaisseur, et avec un système de sécurité qui prévient en cas de tentative d'intrusion. C'est ton pare-feu et le paramétrage de DSM qui est cette porte. L'autre implication, et elle n'est pas minime, c'est que ce tutoriel ouvre l'ensemble des ports au réseau local. Parce qu'on part du postulat que le réseau est sûr. Mais un exemple simple, si tu montes les dossiers partagés de ton NAS via SMB avec des utilisateurs ayant des droits en écriture sur le NAS ou si tu utilises Drive en bi-directionnel, le pare-feu ne fera pas son office parce qu'il a "confiance" en ton PC, ton Mac, ton iPhone, etc... Et quand on voit comment certaines personnes cliquent sur les PJ de n'importe quel mail, ou ne sont pas prudents lorsqu'ils naviguent sur le web, je me dis que les moyens de contamination restent conséquents chez beaucoup.

Très intéressant. 😮

Je vais, comme @Jeff777 essayer de te résumer ce à quoi doit ressembler ton architecture pour que ce que tu veux faire fonctionne. il y aura de la redite sûrement, mais je n'ai pas le courage de parcourir les 3 dernières pages avec des infos dans tous les sens. Tu souhaites atteindre l'interface de ton NAS, que tu sois en local ou à l'extérieur, depuis https://nas.ndd.net, juste ? https://nas.ndd.net c'est équivalent à https://nas.ndd.net:443, donc ça veut dire qu'il faut utiliser un proxy inversé, sauf erreur de ma part, je ne vois nulle part que tu en as mis un en place, donc déjà ça ne peut pas marcher. Pour la partie LAN : PC 1 souhaite accéder à https://nas.ndd.net | PC 1 interroge le(s) serveur(s) DNS que le serveur DHCP lui renseigne, si tu veux une résolution locale, il doit pousser uniquement l'IP de ton NAS | Ta zone locale ndd.net dispose des entrées précisées plus avant par @Jeff777 (une entrée NS, A et CNAME). Attention aux vues, si tu les as configurées (voir ce tutoriel). | Le serveur local fait autorité pour ta requête, il transmet donc la requête à IP_PRIVEE_DU_NAS:443. Si tu n'as pas mis de proxy inversé en place, il n'y aura aucune raison que cette requête soit redirigée vers IP_PRIVEE_DU_NAS:5000 ou IP_PRIVEE_DU_NAS:5001, c'est le port 443 qui va être sollicité. | Une fois le proxy inversé en place, deux choses vont activer le mécanisme du proxy inversé, le nom de domaine demandé (nas.ndd.net) et le port (443). C'est ce qu'on appelle un frontend, c'est ce qui fait face, l'association de ces deux critères va, lorsque tu auras créé l'entrée appropriée, lui permettre de dire que ça correspond au backend (service en arrière-plan) officiant sur IP_PRIVEEE_DU_NAS:5000 (ou localhost:5000 vu que le proxy inversé et DSM sont sur la même machine) en http ou IP_PRIVEE_DU_NAS:5001 (localhost:5001) en https (on recommande d'utiliser le port HTTP lorsqu'on passe par un proxy inversé). ATTENTION : SI tu utilises le port HTTP, la redirection HTTP -> HTTPS doit être désactivée dans le paramétrage du NAS (voir tutoriel sur la sécurisation, c'est précisé noir sur blanc) | Ta requête aboutira sur la page de login de DSM A aucun moment on ne passe par le routeur dans cette chaîne, il intervient juste en amont dans l'adresse DNS qu'il aura poussée par son serveur DHCP. Les conditions à remplir : - Les ports 443, 5000 sont ouverts vers l'environnement local (voir tutoriel sur la sécurisation du NAS) - Tu disposes d'un certificat pour le domaine ndd.net (voir tutoriel sur la sécurisation du NAS) - Le certificat est associé pour chaque service exposé par ton proxy inversé ________________________________ Bien maintenant la partie WAN : Mobile 1 souhaite accéder à https://nas.ndd.net | Il interroge ses DNS, ceux de Google ou de ton FAI ou qu'importe | La réponse n'étant pas trouvée sur ces serveurs, la requête part aux serveurs racines, et va descendre la chaîne (root -> .net -> .ndd.net). Ok c'est là que ta zone DNS chez ton registrar entre en jeu. Si tu es IP statique, tu as les mêmes enregistrements que dans ta zone locale, avec ton IP publique statique à la place de IP_PRIVEE_DU_NAS. Si tu es en dynamique, alors tu dois créer un Dynhost, moi je partirais sur dynhost.ndd.net (différent de toute entrée de proxy inversé que tu pourras créer) qui va faire le lien entre ton IP dynamique et ta zone DNS, tu n'auras pas d'enregistrement de type A, mais un alias CNAME entre nas.ndd.net et dynhost.ndd.net | Donc là tu interroges l'IP associée à ton Dynhost, donc https://nas.ndd.net correspond à IP_PUBLIQUE:443, c'est ton routeur qui va recevoir ça. Tu veux que ton proxy inversé reçoive la requête, il faut donc qu'il redirige le port 443 vers l'IP prviée de ton NAS, ainsi le proxy inversé va être le frontend. | A partir de ce moment-là, on retombe dans le cas de figure de la résolution locale, le proxy inversé va voir une requête avec un domaine (nas.ndd.net) et un port (443). Il va ensuite rediriger vers le backend correspondant. Les conditions à remplir sont similaires à celles pour la partie LAN, avec en outre : - dynhost.ndd.net qui doit faire partie des alias repris par le certificat - Le port 443 correctement redirigé vers le NAS depuis ton routeur ________________________________ En dernier lieu, je ne comprends pas ton acharnement à ne pas essayer de comprendre ce que tu fais, appliquer c'est bien, mais ce forum n'est pas un SAV, si tu n'as pas le temps ou/ni l'envie de comprendre ce qui y est proposé, peut-être devrais-tu te contenter de QuickConnect ou d'un accès à ton NAS en précisant les ports. La mise en place d'un serveur DNS local (et encore plus d'un publique) avec un nom de domaine valable suivant plusieurs vues est l'aboutissement d'au moins 3 ou 4 tutoriels références de ce forum, ça demande clairement que les notions abordées dans les autres tutoriels soient assimilées (et encore une fois, Fenrir le précise noir sur blanc d'emblée dans son tutoriel)

Pour une utilisation desktop, un adblock, ublock, etc... sera beaucoup plus efficace que Pi-hole, car il redéfinit l'agencement de la page pour cacher les emplacements de pub, Pi-hole en est totalement incapable. Là où Pi-hole brille, c'est sur mobile, où on n'a pas d'outils aussi performants, voire pas d'outil du tout : objets connectés, Smart/Android TV, etc... Pour les objets connectés, ça permet de vérifier notamment qu'il n'y a pas de fuite de données vers des sites suspects 🙂

Salut, on aime bien que le premier post soit réservé à la présentation, même pour une question avant achat 🙂 Pour ta question, il n'y a pas besoin d'avoir des modèles aussi puissants pour l'utilisation que tu prévois, un modèle J conviendra parfaitement. Pour le nombre de baies, et bien ça c'est à toi de le définir suivant l'évolution à court, moyen, long terme ? Se poser aussi la question de la sauvegarde de ces données.

Bienvenue ! Normalement les tutoriels présents sur ce forum sont assez complets pour l'utilisation que vous prévoyez. Quand on ne connaît pas le mieux c'est de demander surtout 😛

En gros bind9 c'est la référence des serveurs DNS en ligne de commande, il y a pléthores de tutoriels sur le net pour le configurer. Quand tu n'as pas deux NAS c'est pratique 😛 Pi-hole c'est un bloqueur de pub par DNS, qui fonctionnent sur les noms de domaine et les expressions régulières. Et ça s'héberge facilement via Docker ou VM sur ton NAS 🙂

Il te faut dé-commenter dans le fichier de configuration ovpn la ligne : redirect-gateway def1

Salut, J'ai loué le plus petit VPS OVH pour m'en faire une sandbox, j'ai testé Wireguard dans un premier temps par curiosité parce qu'on m'en a parlé. C'est original en cela que ça diffère assez radicalement d'OpenVPN (Wireguard fait du p2p, il n'y a pas vraiment de serveur ni de client). Ça, c'était pour la petite histoire, ma question est la suivante, je viens de découvrir dans ce tutoriel qu'il y a un pare-feu accessible sur OVH directement. Question, est-ce que c'est juste une GUI pour ufw pré-installé sur mon VPS ou un pare-feu en amont ? Car ufw c'est bien gentil, mais j'avais installé OpenVPN, avec sa GUI sur le port 943, et j'avais beau ne pas l'avoir autorisé dans ufw, j'y accédais sans problème, donc si le pare-feu OVH marche mieux je suis preneur !

En fait le problème c'est que parfois le PC risque d'utiliser le DNS de FDN, et dans ce cas-là sa résolution locale échouera, pour peu que le DNS principal mette un peu de temps à répondre ou qu'une autre requête lui arrive simultanément. Dans ce genre de situation, on préfère mettre un 2ème serveur DNS esclave du premier, ainsi tu assures la redondance et le même fonctionnement quelque soit le DNS choisi (ça peut être un serveur dns bind9 dans une marchine virtuelle ou un conteneur d'ailleurs, pas nécessairement une machine physique, la machine physique étant quand même préférable en cas de défaillance du NAS). Avant de rapatrier sur pfSense, j'avais 2 serveurs DNS, un sur le NAS et un (bind9) sur raspberry (esclave de celui du NAS), et chacun redirigeait vers sa propre instance de Pi-hole, qui redirigeait ensuite vers les DNS de FDN.

@Jeff777 Je crois qu'il n'a pas envie de te répondre 😛

Tu tapes IP calculator sur Google, tu rentres ton IP range et tu verras les IP que tu peux utiliser.

Bonjour, Bienvenue 🙂

Je crois que je vais rester en 6.2.2 jusqu'à fin 2020 si DSM 7 n'est pas sorti pour trouver une solution alternative à Google Cloud Print (je suis preneur si quelqu'un utilise une solution alternative).

Ça m'embête vraiment cette décision de google d'arrêter Google Cloud Print, ça me rend bien service avec mon imprimante sans prise réseau... Et Synology anticipe en plus 😞 Une idée de ce qu'ils veulent dire par là ?

Bonjour, quel modèle de NAS ?

Si tu souhaites héberger ta partie publique oui 😛 sinon c'est ton registrar qui s'en charge avec ses propres serveurs DNS.