PiwiLAbruti

Un test simple : http://canyouseeme.org/

Soit le pare-feu du NAS est activé, soit la redirection sur le routeur est erronée.

Quel est le message affiché par le navigateur ?

Cette adresse IP est bien l'adresse publique (a.b.c.d) et non celle locale (192.168.x.y) ? Il faut aussi rediriger les ports tcp/80 (déconseillé) et/ou tcp/443 (recommandé) vers l'adresse IP locale du NAS dans ton routeur.

Est-ce que le pare-feu est actif sur le NAS ?

Je pense savoir d'où vient le souci en voyant la capture d'écran des enregistrements DNS. Visiblement tu as dû connecter plusieurs interfaces de ton NAS au réseau, ce qui fait qu'il a plusieurs adresses IP appartenant au même subnet. L'AD n'aime pas avoir un hôte avec plusieurs adresses. Je te recommande donc de ne connecter qu'une seule interface RJ45 de ton NAS au réseau et de retenter la liaison au domaine.

Avec tout ça, vous avez oublié de résoudre le problème de débit local. Je suppose que tu utilises le Wi-Fi sur ton Mac ? Essaye avec un câble déjà, ça devrait aller beaucoup plus vite.

Si tu parviens à faire fonctionner Observium, n'hésite pas à faire un retour ici ou même un tuto. Si tu veux en faire un paquet facilement redistribuable, utilise spksrc qui te permettra de le publier sur SynoCommunity.

Est-ce que la commande fonctionne sans être planifiée ? wget -m -nH ftpes://identifiantFTP:motdepasseFTP@IPlocaleFreebox:PortFTP/Disque dur/Téléchargements/EnCours/ Est-ce que la Freebox support ftpes ? (à ma connaissance, non)

As-tu suivi les instructions de Synology concernant la cross-compilation ? http://global.download.synology.com/download/Document/DeveloperGuide/DSM_Developer_Guide.pdf Cela peut d'ailleurs être fait plus simplement avec spksrc : https://github.com/SynoCommunity/spksrc

Je parie que tu as cherché sur ton Mac, alors que ce chemin se situe sur le NAS.

SynoCommunity, comme son nom l'indique, est communautaire. C'est-à-dire que ceux qui assurent les mises à jour le font à titre bénévol. De ce fait, il n'existe aucun planning de mises à jour et il n'y en aura jamais. Si quelqu'un a vraiment besoin d'un paquet, il est possible de faire un don afin de manifester son intérêt.

Mais non, il suffit d'extraire le contenu du .dlm (c'est une bête archive .tar.gz), modifier le host et reconstituer l'archive comme je l'ai fait pour le module CPasBien. On peut même faire encore plus simple en modifiant directement le fichier correspondant dans /var/packages/DownloadStation/etc/download/userplugins/t411/.

Remonte ton problème à Synology en leur précisant le processus incriminé.

Aucun problème en HTTPS (tcp/9901) sous DSM 4.3 et Surveillance Station 6.1.2983.

Renseigne-toi sur Cloud Station : https://www.synology.com/fr-fr/dsm/5.2/cloud_services

Et en mettant un switch derrière le routeur, tu pourrais brancher plusieurs équipements en filaire ?

Comme ça fonctionne en locam, c'est soit un problème de redirection au niveau de la box (mauvaise adresse IP ou mauvais port) ou un pare-feu qui bloquerait les requêtes entrantes (sur la box ou le NAS).

Donc il est très probable qu'un ventilateur défectueux empêche le NAS de démarrer. Le mieux serait de le remplacer.

Regarde dans le moniteur de ressources le processus qui consomme le plus de CPU, ça pourrait te donner une idée de ce qui sature l'activité de ton disque.

Étant donné que tu débutes avec les NAS et la sécurité des réseaux, ce n'est pas très important.

Est-ce que le ventilateur tourne au démarrage ?

Le seul moyen de masquer un port dans une URL HTTP est d'utiliser les ports standards (tcp/80 ou tcp/443). Sinon il reste la solution du reverse proxy.

Quelque soit le port extérieur que tu choisisses, il sera toujours visible.

Je ne sais pas si le A1G dans la référence DWA-131 (A1G) donnée par Synology correspondrait à l'identification du chipset. À comparer avec ce qui est indiqué sur la clé.