PiwiLAbruti

Dans le lien que j'ai donné, il n'y a aucune allusion à un container. Il s'agit de plaquer l'image de HAOS directement sur le disque d'une machine x86. Ubuntu n'est utilisé que pour le live boot sur un support externe pour réaliser la copie de l'image HAOS.

Je ne serais pas aussi catégorique @Lelolo. La dernière photo de l'annonce montre que HAOS est installé nativement sur ce PC : https://www.home-assistant.io/installation/generic-x86-64/ Le service tag de ce PC étant visible sur l'une des photos, il est possible d'en obtenir les caractéristiques d'orgine (à confirmer avec le vendeur) : https://www.dell.com/support/product-details/fr-fr/servicetag/0-L2daTDBNbU8xdHczZXl5WkZzcmc4Zz090/overview Le lien Caractéristiques du produit sur la droite donne tous les détails matériels de ce Dell Optiplex 3020 (dont le support a expiré en juillet 2019 😅) : CPU Intel Core i3 4130 RAM 4Go DDR3 1600 HDD 3,5" Seagate 500Go 7200tr/min Pour des raisons d'encombrement, de consommation d'énergie, de stockage fragile et bruyant (disque mécanique âgé), et de performances, je conseillerais plutôt un mini-PC à base d'Intel N100 (même si c'est 3x plus cher).

Aucune idée. Vu la faible incrémentation du numéro de version avec la version précédente (1.4.3-1609 > 1.4.3-1610), je doute qu'il s'agisse d'une évolution majeure. Au passage, seuls les NAS à architecture x86_64 (Intel/AMD) sont concernés. Cette version n'a pas été publiée pour les autres architectures. https://archive.synology.com/download/Package/FileStation/1.4.3-1610

Effectivement, avec le nom DDNS choisi comme zone DNS ça ne pose pas de problème. Pour les résolutions locales, il faudra faire pointer le nom vers l'adresse IPv6 locale du NAS (fe80::/10) qui est invariable (EUI-64) quelque soit les changements réseau, contrairement à IPv4.

Je n'ai jamais essayé, mais ça doit être possible. Attention cependant aux effets de bord si plusieurs domaines *.synology.me sont utilisés sur d'autres équipements distants. La zone synology.me de DNS Server remplacera tous les domaines enfants, ce qui n'est pas forcément souhaitable.

Il faut conserver les deux préfixes car l'un est local et l'autre global.

Ça ne répond pas à ma question, et je n'utilise pas OpenVPN. Quelqu'un d'autre aura certainement la réponse à ta question.

Pourquoi ne pas tester avec une alimentation de rechange ?

Quelle est la configuration du pare-feu du NAS ?

Le ping n'a aucune importance, il prouve uniquement que l'hôte distant répond aux requêtes ICMP (te voilà bien avancé !). Pour utiliser Hyper Backup Vault, il n'y a pas besoin de pouvoir pinguer l'hôte distant, ni de passer par un VPN (à moins de ne pas disposer d'adresse IP fixe). Tu devrais plutôt ouvrir les ports tcp/5001 et tcp/6281 sur le routeur derrière lequel se situe le DS213, mais uniquement pour l'adresse IP publique derrière laquelle se situe le DS725+ (si elle est fixe).

C'est-à-dire ? À quelle étape est-ce que ça coince ? (Je n'utilise pas de VPN pour les sauvegardes, seulement les ports nécessaires ouverts pour la source uniquement)

Tu peux aussi inclure IPv6 dans les règles de pare-feu (au moins fe80::/10). Je ne vois pas de contre-indication à définir des accès extérieurs vers ce NAS tant que le périmètre est bien défini. J'ai également un DS213j (distant) qui fait office de destination de sauvegarde (Hyper Backup Vault), replication DNS et LDAP, … Il n'est ouvert qu'aux adresses IPv4 et aux préfixes IPv6 nécessaires.

Oui, et c'est expliqué dans l'aide officielle : https://kb.synology.com/fr-fr/DSM/help/MailClient/mailplus_mail?version=7 Effectuer une recherche > Pour utiliser les opérateurs de recherche

Marqué le sujet comme [Résolu], c'est bien. Expliquer comment tu as résolu le problème, c'est mieux. C'est une limitation de Cloudflare : https://developers.cloudflare.com/workers/platform/limits/#request-and-response-limits Request and response limitsRequest body size limits depend on your Cloudflare account plan, not your Workers plan. Requests exceeding these limits return a 413 Request entity too large error. Cloudflare Plan Maximum request body size Free 100MB Pro 100MB Business 200MB Enterprise 500 MB (by default)

Le problème peut aussi venir d'un problème d'alimentation qui ne parvient pas à fournir le pic de courant nécessaire au démarrage avec 4 disques. Essaye de démarrer sur 3 disques dont le disque douteux. Si ça démarre, c'est que l'alimentation pourrait avoir le problème ci-dessus.

Si tu souhaites utiliser des serveurs DNS en clair, il n'est plus possible d'utiliser ceux de FDN qui sont réservés à leurs adhérents. N'importe quel autre service DNS accessible en clair (udp/53) fonctionnera.

Les serveurs FDN ne sont plus accessibles en clair, c'est décrit dans renforcement des protections des serveurs DNS récursifs ouverts de FDN sur le lien que tu as donné. Les serveurs ne répondent que sur DoT ou DoH pour les personnes externes au réseau FDN.

Il est aussi possible d'utiliser un seul dossier partagé contenant tous les dossiers avec les bons droits à sa racine.

Ce n'est pas le groupe qu'il faut étendre, mais le volume. Une capture d'écran du volume serait bénéfique.

Je m'attendais plus à une capture d'écran du volume où tu trouveras une option pour étendre ce volume avec l'espace disponible sur le groupe de stockage.

Un groupe de stockage est un ensemble de disques, rien de plus. Comme tu as déjà mis tous les disques dans un même groupe, il est normal d'avoir les messages indiqués sur les captures d'écran. Le volume 1 affiche un avertissement. Pourrais-tu donner plus de détails à ce sujet ?

Une capture d'écran de la fenêtre vers laquelle pointe le lien Détail serait bienvenue.

Sans WireGuard (qui est une bonne solution), voici une méthodologie pour restreindre l'accès à un opérateur mobile (Bouygues Telecom dans l'exemple ci-dessous) : Relever les adresses IPv4 et IPv6 d'un appareil mobile (Wi-Fi désactivé) depuis une site comme https://ip.lafibre.info, Récupérer les réseaux correspondants depuis un annuaire BGP comme bgp.tools ou bgp.he.net (pour Bouygues Telecom : https://bgp.tools/as/5410#prefixes), Créer une règle d'autorisation dans le pare-feu du NAS pour chaque réseau identifié. Afin mieux identifier ces réseaux, on peut temporairement ouvrir les accès à la France entière et identifier les adresses IP mobiles dans les logs de connexion du NAS. Contrairement à IPv6, il y aura probablement plusieurs réseaux IPv4 à renseigner. On peut encore aller plus loin pour restreindre aux plages réellement utilisées, mais ça ferait plutôt l'objet d'un tutoriel.

Tu peux créer une règle dans le pare-feu par pays pour autoriser toutes les adresses IP Françaises. Les adresses IPv4 et IPv6 de ton mobile y sont incluses. Si tu veux restreindre à ton opérateur uniquement, il faut autoriser uniquement les réseaux IP de ce dernier. Quel est ton opérateur mobile ?

Je suppose que tu as compris que le préfixe IPv6 2a01:e0a:3:a350::/64 de ta Freebox n'est pas autorisé dans le pare-feu du NAS, ce qui explique le message d'avertissement de DSM. Comme tu n'accèdes pas au NAS avec une adresse IP autorisée dans les règles de pare-feu, tu n'auras plus d'accès au NAS si ces règles sont appliquées. Pour les connexions locales au NAS, je déconseille d'utiliser un domaine *.synology.me car tu rends l'accès local à ton NAS dépendant du service DDNS de Synology alors qu'il n'y aucune raison pour que cet accès soit dépendant d'internet. Utilise plutôt l'adresse IP locale du NAS (https://92.168.1.*:35001 en IPv4, ou https://[fe80::*]:35001 en IPv6) qui fonctionnera quelque soit l'état de la connexion internet. Si toutefois tu souhaites continuer d'utiliser le domaine *.synology.me, il faut alors autoriser le préfixe 2a01:e0a:3:a350::/64 dans les règles de pare-feu du NAS.