PiwiLAbruti

C'est pourtant clair comme message (d'ailleurs ça bosse dur à la SNCF 😅) : Le domaine quickconnect.to est explicitement bloqué par le serveur proxy que tu utilises (web-lyon5.sncf.fr). Il n'est pas du tout certain que ça fonctionne avec un autre nom de domaine.

Configure les règles dans le pare-feu du NAS. Si jamais tu changes de FAI, tu n’auras que le port tcp/80 à rediriger.

Pour ne pas laisser le port tcp/80 ouvert aux quatre vents, tu peux n’autoriser que les adresses des serveurs Let’s Encrypt à y accéder. Les deux adresses sont dans mon post précédent, il suffit de créer les règles nécessaires dans le pare-feu.

Il faut autoriser l’accès au port tcp/80 pour que le certificat fonctionne.

Bienvenu @Oduig ! Comment ça Nantes est en Bretagne ? 😅

Il n’y a que le support Synology qui pourra te répondre.

Ce que tu as fait fonctionne mais s’applique à toutes les interfaces, ce qui peut avoir des effets indésirables sur certaines interfaces. C’est au choix. Je crois que ce que tu as fait est recommandé par @Fenrir dans son tuto sur la sécurité.

Il y a un long sujet qui traite du souci que tu rencontres : Pour résumer, il s'agit d'un problème de processeur. Contacte le support Synology (ou ton revendeur s'il est capable de prendre en charge ce défaut) pour que ton NAS soit réparé ou qu'il soit remplacé.

Sur la capture d'écran de @folo, il s'agit des règles appliquées à l'interface LAN (sélectionnée en haut à droite). Je déconseille de définir des règles dans la rubrique "Toutes les interfaces" du pare-feu, dans laquelle il n'est pas possible de sélectionner une action par défaut (ce qui est normal puisque les règles de l'interface concernée sont appliquées si aucune règle n'est applicable dans la rubrique générale).

La réponse est indiquée dans le premier message de ce sujet :

Non, il ne manque rien puisque le comportement par défaut est de tout bloquer (regarde en bas de sa première capture d'écran).

Pas forcément, ça dépend du prix auquel est vendu la licence de DSM. J’ai une confiance totale en Synology pour annoncer un tarif en faveur de leur matériel. 😅

Dans tous les cas il vaut mieux adapter le Wi-Fi à la maison que le contraire. 😄 Pour la liaison CPL, les boitiers des marques devolo et TP-Link ressortent souvent en tête des comparatifs. Il faudra bien configurer le MR2200ac (si tu prends ce modèle) en mode point d'accès Wi-Fi, et désactiver le Mesh (ça devrait être implicite en mode AP).

Le DS107 utilise une architecture ppc824x qui n’est plus maintenue par Synology. Il est possible d’y installer des versions ultérieures de DSM si des modèles sortis après supportent la même architecture. Dans le cas du DS107, le DS109j est le dernier modèle à partager la même architecture. Donc l’upgrade du DS107 est limitée à la dernière version de DSM supportée par le DS109j, soit DSM 4.2-3259.

Il faut bien comprendre que pour fonctionner correctement, le mesh a besoin de communiquer en sans-fil avec d'autres bornes (sans même parler des SSID servis aux clients). Si le MR2200 capte mal le RT2600ac, le problème reste le même qu'auparavant. Le mesh ne diminuera pas l'épaisseur des murs, ou plus généralement ne supprimera pas les obstacles aux communications sans-fil. @Alexvista : La solution qui me semble la plus efficace est de tirer un câble RJ45 de ton RT2600ac au rez-de-chaussée vers le 1er étage et d'y connecter un point d'accès Wi-Fi quelconque (pas forcément Synology).

Mon message qui précède répond déjà à cette question.

synonet semble être un synonyme de ether-wake, donc il ne serait pas possible de définir une adresse de destination.

Si tu ne veux pas taper une ligne de commande, comment souhaiterais-tu procéder ? Il est par exemple possible d'utiliser l'application WakeOnLAN d'Aquila Tech. pour envoyer le paquet. Par contre, il faut un équipement capable de relayer (broadcast) ce paquet sur le réseau local. Pour ma part, j'avais mis en place un script PHP qui s'occupait de diffuser un paquet WOL sur plusieurs VLAN. Je ne sais pas quelles sont tes compétences en réseau et développement, mais dans tous les cas je ne connais aucune solution clé en main actuellement (hormis la Freebox qui sait le faire).

Dans l’explication que tu donnes, je ne vois ce qui la différence entre la façon dont tu procédais avant et ce que tu veux faire maintenant.

Il y a une procédure pour tester la carte-mère du NAS : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/Why_am_I_unable_to_install_my_Synology_NAS_and_why_is_my_power_LED_is_flashing_constantly

Dans la configuration actuelle (SHR), dès qu'une donnée est écrite sur ton volume (qui regroupe tes deux disques), cette dernière est écrite simultanément au même endroit sur les deux disques. Il en est de même pour la suppression. Donc on ne peut pas parler de sauvegarde puisqu'il t'est impossible de restaurer un fichier dans un état antérieur. Dans tous les cas, c'est une mauvaise idée de sauvegarder sur un disque interne au NAS car cela la rend très vulnérable (CryptoLocker, compromission, risques physiques, ...). Le plus simple est d'utiliser un disque USB externe avec une tâche de sauvegarde HyperBackup avec une politique de rétention adaptée. Bien évidemment, il ne faut connecter ce disque au NAS que lors des sauvegardes, sinon on n'élimine pas les quelques risques présentés ci-dessus. Tout être humain normalement constitué fait confiance à l'assistant qui lui est proposé. Le problème n'est pas l'utilisateur, mais la façon dont Synology présente les options dans son assistant.

Au lieu de tester toutes les possibilités de configuration d'un SPF, il serait peut-être temps de comprendre à quoi ça sert et pourquoi on lui donne tel ou tel paramètre... 🙄 L'enregistrement SPF sert à vérifier que l'adresse du serveur d'expédition est bien autorisée à envoyer des messages pour ton domaine, et à appliquer une action pour les messages non-conformes. Presque tout est expliqué sur la page Wikipedia que je te conseille de lire dans son intégralité et dans l'ordre. Quelque détails sur ton SPF "v=spf1 a mx ip4:monipfixe include:mx.ovh.com ~all" : "a" veut dire que toutes les adresses IP des enregistrements de type A de ton domaine sont autorisées. "mx" veut dire la même chose que "a" mais avec les enregistrements de type MX. Si "a" et/ou "mx" pointent déjà vers ton adresse IP publique, il est inutile de déclarer un "ip4" vers ton adresse IP publique (redondance). "include:mx.ovh.com" ajoute l'entrée SPF d'OVH à ton SPF (voir détails ci-dessous). En as-tu réellement besoin ? Conserve "~all" le temps de faire tes tests. Dans un premier temps, ton SPF devrait ressembler à "v=spf1 mx ~all" si l'enregistrement MX de ton domaine pointe bien vers ton adresse IP publique. Si d'autres serveurs autorisés pour l'expédition de messages sont nécessaires, tu peux les ajouter. Attends la propagation. En gros, teste le lendemain de la modification. Si tu es pressé, tu peux . Fais tes tests en vérifiant la validation du SPF dans les en-têtes des messages reçus par les destinataires. Si tout se passe bien, tu pourras basculer vers "v=spf1 mx -all" ou continuer de faire joujou avec les autres paramètres facultatifs (toujours avec "~all"). Détails du SPF d'OVH : >nslookup -type=TXT mx.ovh.com mx.ovh.com text = "v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all"

Il vaut mieux limiter la surface d'exposition en utilisant uniquement les adresses nécessaires plutôt qu'un pays entier : outbound1.letsencrypt.org 66.133.109.36 outbound2.letsencrypt.org 64.78.149.164

As-tu contacté le support Synology pour leur faire part du problème ?

Ma question est surtout de savoir s'il y a des sauvegardes effectuées régulièrement. Ça me paraît évident quand on manipule des données importantes et/ou sensibles, mais ça ne l'est pas pour tout le monde.