PiwiLAbruti

Ça poserait problème car des ports accessibles de partout sont facilement détectables afin de pouvoir y lancer des tentatives d'intrusion. Vivons heureux, vivons cachés 😇

Bonjour @A-d-r-i, Non. Oui, ça fait un port de moins exposé sur internet. De plus, le trafic n'est pas chiffré sur ce port (contrairement à HTTPS). Ça peut poser un très gros problème si tu n'as pas appliqué ce tutoriel. Dans l'idéal tu pourrais utiliser le proxy inversé, ainsi tu n'aurais que le port tcp/443 à ouvrir (et à sécuriser dans le pare-feu du NAS). Ça te permettrait d'utiliser des URL plus conviviales (sans port) du type : file.my.synology.me, photo.my.synology.me, ...

Si le but est d'empêcher du brute-force sur des ports sensibles (comme SSH sur le port tcp/22), il convient plutôt de ne pas exposer les ports par défaut et surtout de limiter leur exposition sur internet afin d'en réduire drastiquement la surface de détection (ce que je fais, résultat: zéro scan et/ou tentative de connexion depuis des années). De mon point de vue, et en plus d'être déconseillé depuis quelques années maintenant, le port-knocking est l'une des pires solutions à adopter quand on souhaite améliorer la sécurité (on devrait plutôt dire augmenter la complexité en réalité). C'est peu fiable et dans certains cas ça peut même bloquer totalement l'accès à distance à un serveur si aucun autre moyen de connexion n'a été prévu (donc il ne resterait que l'accès physique pour débloquer la situation). Si vous ne pouvez pas le mettre en place vous même (compilation de knockd et iptables-persistent, ou manuellement avec l'activation d'une règle de pare-feu associée à une séquence de connexion détectée dans les logs), seul Synology pourrait y faire quelque chose (ce dont je doute fort) : https://www.synology.com/fr-fr/form/inquiry/feature

Oui. Tu peux désactiver (et non supprimer) les paquets PHP et Apache dans le Centre de paquets et vérifier que tout les services web que tu utilises fonctionnent normalement sans. S'il y a le moindre problème, tu pourras toujours les réactiver. Laisse les paquet Apache et PHP désactivés pendant un certain temps, tu pourras le supprimer ultérieurement lorsque tu seras certain que tout fonctionne bien avec nginx.

Oui, avec Hyper Backup : https://www.synology.com/fr-fr/dsm/packages/HyperBackup

Un enregistrement wildcard *.domain.tld est une sorte enregistrement par défaut si le nom demandé n'est pas déjà défini, il est donc possible de faire pointer other.domain.tld vers une autre adresse IP.

Je fais bêtement ce que tu as prévu de faire, et je vérifie la résolution avec un nslookup pour confirmer : Qu'est-ce qui te fait peur dans le fait d'essayer ?

Je n'utilise pas d'enregistrement wildcard *.domain.tld, mais je pense que ce que tu veux faire fonctionne. De toute façon, tu n'as qu'à essayer.

Peu importe les tests, DSM indique deux disques défectueux. Si le groupe de stockage est de type RAID5 ou SHR1 la reconstruction n'est pas possible, la tolérance étant limitée à la panne d'un seul disque.

D'après ta capture d'écran, il y a deux disques défectueux. J'espère que tes sauvegardes sont à jour.

J'ai été contraint de le faire récemment car sans cet en-tête, le reverse proxy vers la Freebox ne fonctionnait plus. Si ça ne fonctionne pas, il doit y voir un autre problème de configuration. Ça n'a pas de sens, c'est comme dire que Synology serait discret sur un protocole quelconque (DNS, HTTP, SMTP, MAP, ...). Comme ces protocoles, les en-têtes HTTP sont normalisées dans une RFC. Quelques explications : https://developer.mozilla.org/fr/docs/Web/HTTP/Headers

Les outils de développement du navigateur sont d'une précieuse utilité 😇 C'est à modifier uniquement pour la box. Les autres services ne sont pas concernés. Il en est de même depuis FreeboxOS 4.7.2 (Host: mafreebox.freebox.fr).

Le post vers lequel pointe le lien que j'ai donné indique comment résoudre le problème de reverse proxy vers la Livebox. Il n'est pas question de DNS Server.

Pas besoin du VPN, c'est tellement restreint au niveau IP que ça ne craint aucune intrusion (ou alors quelqu'un qui m'en veut vraiment 😄). L'avantage est aussi que j'utilise la même URL en interne qu'en externe.

Pour avoir un accès externe filtré par un profil d'accès du reverse proxy.

En rajoutant l'en-tête Host ?

As-tu appliqué ceci : https://www.nas-forum.com/forum/topic/59108-tuto-reverse-proxy/?do=findComment&comment=1319480963 ?

Il faut tout laisser en auto (pas de PPPoE, l'adresse IPv4 est assignée automatiquement). Dans [Configuration d'IPv6], il faut sélectionner Relais IPv6 (IPv4 est encapsulé dans IPv6).

Il n'y a pas que la distance à prendre en compte, il y a aussi les obstacles (constitution, épaisseur), et autres appareils et/ou câblages pouvant perturber le signal en chemin.

Bien vu @Thierry94, une adresse IP fixée sur un appareil ne doit pas appartenir à la plage DHCP distribuée sur le réseau (à moins de configurer un bail DHCP).

Il est normal que ça fonctionne chez @MilesTEG1 car le réseau local du RT2600ac est NATé vers le réseau local de la Pop, cette dernière ne voit donc que l'adresse IP configurée en DMZ. Le fonctionnement devrait être identique chez @Jeff777, reste à voir où ça coince.

Est-ce que les déconnexions persistent lorsque la caméra est plus proche du point d'accès Wi-Fi ? (c'est peut-être un problème de qualité de signal entre l'AP Wi-Fi et la caméra)

Je n'ai jamais essayé sur un NAS Synology. Sinon tu peux demander à SynoCommunity de mettre à jour leur paquet Roundcube obsolète (1.1.4 de 2016), ou même générer ton propre paquet avec leurs outils. J'en pense que je n'ai pas compris ta remarque (je fais des buffer overflow en fin de journée 😅). Ma Freebox est en mode routeur et j'utilise le reverse proxy du NAS pour y accéder de l'extérieur (à impérativement sécuriser avec un profil de contrôle d'accès), rien d'impossible donc.

Dans l'interface de gestion LWS, tu as bien créé un DynHost, et configuré un login et un mot de passe associés ? En fait, je me demande si LWS propose ce service car il n'y y a rien qui y fait référence sur leur site. Chez OVH c'est plutôt explicite : https://docs.ovh.com/fr/domains/utilisation-dynhost/