PiwiLAbruti

Bien sûr ! (et heureusement)

Je viens de migrer du paquet Mail Server sur un DS213j vers MailPlus Server sur un DS718+ avec succès en suivant simplement la procédure officielle. Il ne faut pas oublier d'activer les comptes ayant accès à MailPlus Server dans Compte > Utilisateur car ils sont tous désactivés par défaut. Dans mon cas, s'agissant également d'un changement de NAS, il m'a aussi fallu modifier les redirections de ports correspondantes et la zone DNS locale. Le nombre de comptes est maintenant "limité" à 5 mais je n'en utilisais que deux auparavant, donc ça n'a pas d'incidence sur mon utilisation. Je vais tester tranquillement les fonctionnalités supplémentaires.

La première chose à vérifier est le câblage. Connecte le PC depuis lequel sont faits les tests en filaire (pas de Wi-Fi), Lorsque le NAS est accessible, vérifie la vitesse négociée (100Mbps ou 1Gbps). Remplace le câble du NAS par un autre. Fais déjà ces premiers test, ça donnera peut-être une piste.

Ni RDP, ni RDS ne te permettront d’accéder à ton NAS à distance. Je te laisse le soin de te renseigner sur ces protocoles si tu veux en savoir plus. À quels services de ton NAS souhaites-tu accéder à distance ? (le VPN n’est pas nécessairement la meilleure solution)

Le redémarrage des services nginx et du paquet WebStation n’est pas suffisant pour la prise en compte ?

Une méthode simple sera celle qui sera entièrement automatisée (et ce n'est pas près d'arriver). Pour ma part, j'ai juste suivi les instructions officielles pour la création manuelle des certificats avec la méthode DNS. Il ne me reste qu'à l'automatiser au mieux en sachant que je préfère que la création de l'enregistrement TXT reste manuelle. acme.sh propose même la création automatique de l'enregistrement TXT chez pas mal de registrar. Mais il faut valider des étapes manuellement pour utiliser l'API OVH, ce qui fait que j'ai instantanément abandonné l'idée d'utiliser cette solution. Je verrais pour faire un tutoriel lorsque j'aurais tout validé, si j'en ai le courage.

Je ne comprends pas pourquoi Synology s’obstine à faire compliqué pour les certificats. J’utilise acme.sh avec la méthode de validation par DNS (pas d’histoire de ports à ouvrir aux quatre vents, juste un simple enregistrements TXT à ajouter) pour créer mes certificats wildcard. Il ne me reste plus qu’à automatiser le renouvellement.

Comme tu sembles vouloir comparer deux protocoles qui n’ont rien à voir, on va simplifier : Quel est ton besoin ?

Avant d’investir inutilement, as-tu au moins validé le fonctionnement des tes accès en définissant le serveur DNS manuellement sur quelques clients ?

010101010101010001000110001011010011100000100000011011110111001000100000011011100110111101110100001000000101010101010100010001100010110100111000001011000010000001110100011010000110000101110100001000000110100101110011001000000111010001101000011001010010000001110001011101010110010101110011011101000110100101101111011011100010000011110000100111111001100010000100

010100100110100101100101011011100010000001101110001001110110010101111000011010010111001101110100011001010010000001101111011001100110011001101001011000110110100101100101011011000110110001100101011011010110010101101110011101000010000001110000011011110111010101110010001000000110110001100101001000000110011001101111011011100110001101110100011010010110111101101110011011100110010101101101011001010110111001110100001000000111000101110101011001010010000001110100011101010010000001110011011011110111010101101000011000010110100101110100011001010111001100101110001000000100110001100101001000000111000001101100011101010111001100100000011001010110011001100110011010010110001101100001011000110110010100100000011100110110010101110010011000010110100101110100001000000110010001100101001000000111000001101111011100110110010101110010001000000110110001100001001000000111000101110101011001010111001101110100011010010110111101101110001000000110010001101001011100100110010101100011011101000110010101101101011001010110111001110100001000001110000000100000010100110111100101101110011011110110110001101111011001110111100100101110

Oui et non, il y a au moins une autre condition à remplir pour que ça fonctionne : L'adresse IP du NAS doit être renseignée comme seul serveur DNS au niveau du client, soit manuellement, soit via DHCP si le serveur DHCP du routeur/box le permet. Sans quoi la résolution de nas.ndd renverra l'adresse IP publique (si paramétrée dans la zone publique).

Et d'après moi c'est compatible en 6.2.2, je viens de d'installer le paquet avec succès et il est bien démarré et opérationnel. La partie DLZ du paquet DNS Server va concerner les paquets Synology Directory Server et LDAP Server pour mettre à jour les enregistrements DNS des machines appartenant au domaine. On peut le voir dans le fichier /var/packages/DNSServer/target/etc/dlz.conf : [adserver] dlz_enable="0" hostname="" realm_upper="" dns_keytab_name="" realm="" dlz_mount_from_path="" dlz_conf_name="" hostname_upper="" dlz_condition_conf_name=""

DLZ permet de stocker une zone DNS dans une base de données. Les avantages : réduction du temps de démarrage du service, diminution de l'empreinte mémoire, prise en compte instantanée des modifications apportées à la zone DNS (pas de redémarrage du service). L'inconvénient est qu'une base de données supportera beaucoup moins bien la montée en charge (QPS : nombre de requêtes par seconde.) What is DLZ? DLZ (Dynamically Loadable Zones) is a patch for BIND version 9 that simplifies BIND administration and reduces memory usage and startup time. DLZ allows you to store your zone data in a database. Unlike using scripts, the changes in your database are immediately reflected in BIND's response to DNS queries, so there is no need to reload or restart BIND. You see, BIND "dynamically loads" the "zone" data it needs to answer a query from the database. Sources : http://bind-dlz.sourceforge.net/ http://bind-dlz.sourceforge.net/perf_tests.html PS : La mise à jour automatique du paquet DNS Server en version 2.2.1-5023 est proposée sous DSM 6.2.2. Reste à savoir si la paquet reste fonctionnel sans passer en 6.2.3, il est vrai que c'est contradictoire avec les notes de version.

Ce n’est justement pas bon pour ton IP locale. Si tu veux que les résolutions locales se fassent par le serveur DNS du NAS, il faut que l’adresse IP ce dernier soit configurée comme serveur DNS dans les paramètres de la carte réseau de ton PC. Ton PC utilise par défaut 212.224.255.152 pour les résolutions DNS au lieu du NAS. C’est affiché dans les résultats que tu as donnés un peu plus haut. Tout est très clairement expliqué dans le tutoriel concernant DNS Server. Recopier ce qui est affiché sur les captures d'écran ne sert à rien. Il faut prendre le temps de tout lire pour comprendre, sans quoi tu vas perdre beaucoup de temps et tu n’arriveras pas au résultat souhaité.

Bien, maintenant tu sais d'où vient le problème.

En local, il faut paramétrer le NAS comme serveur DNS sur les clients, soit manuellement, soit automatiquement via DHCP (si possible). Les commandes suivantes doivent retourner le même résultat (192.168.x.y est l'adresse IP locale du NAS) : > nslookup nas.ndd.net > nslookup nas.ndd.net 192.168.x.y Pour tester une résolution externe depuis le réseau local, il suffit d'utiliser la même commande avec l'adresse IP d'un serveur DNS public : > nslookup nas.ndd.net 80.67.169.12 Si les résolutions sont bonnes, le problème viendrait soit des règles NAT, soit du reverse proxy.

Pour commencer, je te recommande vivement d'appliquer les conseils de ce tutoriel : Qu'as-tu modifié dans la configuration de nginx ? Peux-tu poster la/les configuration(s) en question ?

Si tu veux que nas.ndd.net pointe vers 192.168.x.y en local, ça n'a rien à voir avec la zone DNS configurée chez OVH (qui est la partie publique). Il faudrait suivre la partie de ce tutoriel concernant la zone DNS locale : Par contre ça implique pas mal de changements sur ton réseau (distribution du serveur DNS local par DHCP, ou configuration manuelle, ...). De mon point de vue, je n'a pas assez de précisions sur ton besoin exact pour pouvoir t'aider plus.

En fait ça ne simplifie pas les accès, c’est même plutôt tout le contraire. L’avantage du NAT en IPv4 est justement que l’ont sait exactement ce qui est ouvert sur internet, mais ça a tout de même des limitations par rapport à IPv6 (un seul équipement derrière chaque port, ...). En IPv6 chaque équipement du réseau doit disposer d’un pare-feu pour bloquer le trafic entrant indésirable. C’est d’ailleurs ce qui pose problème d’entrée de jeu avec les objets connectés mal sécurisés qui deviennent alors des points d’entrée sur tout le réseau local. Dans l’ideal, il faut un pare-feu en amont des équipements locaux sur lequel on peut définir des règles de filtrage (ce qui rejoint la complexité qui tu voyais en IPv4). Mais ce n’est pas toujours possible, le cas le plus lamentable étant celui de la Freebox sur laquelle il n’est pas possible de définir des règles de filtrage en IPv6, il y a juste un gros switch on/off du filtrage des connexions entrantes. Donc attention, il y a beaucoup de choses à considérer avant de passer à IPv6. Ce n’est pas insurmontable mais il faut bien comprendre les enjeux de sécurité que ça implique sans quoi votre réseau local peut rapidement est compromis.

Tu peux sauvegarder et restaurer le paquet Mail Server avec HyperBackup. Je ne sais pas si cette sauvegarde inclut les données mail des utilisateurs stockées dans le dossier .MailDir de leurs /home respectifs est également sauvegardée. C’est pourquoi il vaut mieux également sauvegarder le dossier /homes. Le passage à MailPlus Server dépend du nombre de comptes car au delà d’un certain nombre (2 ou 5, je ne sais plus), il faut acheter des licenses supplémentaires.

La méthodologie est la même en IPv6 que ce qui est expliqué en IPv4 en remplaçant les IPv4 privées par les adresses locales IPv6. Qu’attends-tu d’IPv6 par rapport à IPv4 ?

Donc si j’ai bien tout suivi, tu voudrais pouvoir te connecter en local à ton NAS avec ton nom de domaine au lieu de l’adresse 192.168.x.y ?

Ça n’est pas une question d’être aventureux ou non, c’est juste que le contenu de la mise à jour est inintéressant pour 99,99% des particuliers (et encore, j’ai dû oublier une demie-douzaine de 9). @beepbeep5372 : Il suffit d’aller les lire dans la partie Assistance du site officiel : https://www.synology.com/fr-fr/releaseNote/DS218+

Vu les modifications apportées, il n’y a aucune urgence à appliquer l’update 6. Il vaut mieux attendre patiemment son arrivée via les mises à jour automatiques.