.Shad.

@macpowered @KahioQue donne un nslookup wordpress.ndd.fr depuis un PC Linux ou Windows en local ? Est-ce que ça pointe bien sur le NAS ? @macpowered Sur DSM, si tu utilises Nginx pour une entrée de proxy inversé, il faut que le certificat soit valide et accessible, même si ce n'est pas un domaine Synology il y a des solutions, un exemple parmi d'autres : Ou encore un import manuel (mais à répéter tous les 3 mois) Ca ne règlera pas ton problème actuel, mais ça évitera de te taper un avertissement comme quoi ton accès n'est pas sécurisé.

Est-ce que : tu as bien fait une translation de port entre ton NAS et ton conteneur ? 48152 du NAS -> 80 du conteneur. dans ton proxy inversé tu as bien, par exemple : https://wordpress.ndd.fr -> http://localhost:48152 ? associer ton entrée de proxy inversé à un certificat adéquat dans Panneau de configuration -> Sécurité -> Certificats -> Configurer créer un CNAME wordpress.ndd.fr vers l'enregistrement qui pointe sur l'IP publique de ton NAS chez ton hébergeur de zone DNS. créer une règle de NAT entre ta box et ton NAS En vérifiant toutes ces règles, si ton conteneur est fonctionnel, ça devrait marcher.

Est-ce que tu as transféré le port (sur lequel Wordpress est exposé sur le NAS) depuis ta box vers le NAS ? Quand tu dis impossible d'accéder à la page, de quelle erreur s'agit-il exactement ? Appuie sur F12 dans ton explorateur pour voir le numéro d'erreur dans la console. Tu joins ton NAS depuis l'extérieur avec un DDNS ou un enregistrement A ? Pas de proxy inversé on est d'accord ? Il faut à tout prix éviter de suivre les tutos de ce site, c'est d'une qualité affligeante, par exemple dans le tutoriel en question il crée des volumes docker dans sa stack, qu'il n'utilise pas. Ça n'a aucun sens.

Bienvenue parmi nous, au plaisir de te croiser au détour d'un sujet. 😉

Pardon, je me suis mal exprimé. Je veux dire que le domaine racine pointe vers l'IP par défaut qu'OVH ajoute dans ma zone DNS par défaut. Vu que mon IP n'est pas fixe, faire pointer le domaine racine vers une IP qui va changer n'a pas beaucoup de sens et peut être dangereux. Donc tous mes FQDN (proxy inversé entre autres) pointent via des CNAME vers le dynhost qui, lui, reste à jour. Je n'utilise pas d'enregistrement wildcard pour mon domaine perso, car j'ai un deuxième dynhost pour le même domaine qui pointe vers une autre IP dynamique. Du coup j'ajoute les domaines dont j'ai besoin qui pointent vers l'un ou l'autre des dynhost. Même si je t'avoue que depuis que j'ai changé d'adresse, je suis sur une nouvelle infra réseau de mon FAI, où les IP ne bougent jamais sauf gros problème réseau, ce qui est très rare, en deux ans j'ai changé une seule fois d'IP car justement ils faisaient des travaux importants au niveau de l'infra réseau. Donc dans l'absolu je pourrais créer deux enregistrements A avec les deux IP, et le domaine racine pointant sur mon serveur le plus utilisé par défaut. En revanche, pour mon VPS, vu qu'un domaine lui est entièrement dédié, je fais ce que tu dis.

@aozorashinyuu I didn't expect anytone to use this script one day besides @Jeff777 😄 I'll try to incorporate the changes you mentionned as soon as I can, thanks for your input. 🙂

Quelle est l'adresse de ton dynhost ? Moi par exemple c'est dynhost.xxxx.ovh, de fait je n'ai aucun enregistrement de type CNAME ou A dans ma zone DNS. Si c'était un doublon, c'est normal que maintenant ça marche. Par défaut, si ton IP publique n'est pas fixe, tu peux laisser l'adresse IP renseignée par OVH dans la zone DNS, elle pointe vers un petit hébergement d'OVH, histoire de pointer vers quelque chose. Mais dans ce cas-là tu ne t'en serviras pas, car tous tes enregistrements CNAME pointeront vers ton ou tes dynhost.

Salut, déjà faire ce que le message préconise, aller voir sur OVH si ton dynhost est renseigné dans ta zone DNS : Vérifier que les informations dans Gérer les accès sont identiques à celles dans le NAS. Et normalement tu devrais voir l'IP de ton enregistrement dynhost être celle publique de ton NAS.

Bienvenue parmi nous !

Ben, je sais pas, essaie, c'est pas moi qui ait un Asustor 😆 Fais comme tu le sens 🙂

C'est bien possible, car j'ai eu des grosses coupures à cette période (alors que ça n'arrive jamais), et il y a eu ensuite des pertes conséquentes de débit que la venue d'un technicien a résolu. Depuis, plus de changement de préfixe.

Moi j'utilise le dépôt APT car c'est sur des Debian que je l'utilise. Mais si tu as pip et virtualenv c'est là que ça se passe : https://borgbackup.readthedocs.io/en/stable/installation.html#pip-installation

Oui, tout est ici : https://borgbackup.readthedocs.io/en/stable/

En Belgique j'ai eu le cas chez Proximus, mais il a changé au bout de 8 mois, donc ce n'est pas handicapant non plus. En France je ne sais pas, possible qu'il ne change jamais. 🙂

Avec pip tu auras la dernière version. Et pour ce genre de chose je trouve ça mieux en natif, la conservation des permissions et l'appartenance des fichiers sont plus aisées. Et ça s'exécute dans les environnements virtuels python, donc on est sur la même philosophie que Docker, à savoir l'isolation.

Si tu as python3 en ligne de commande sur ADM, tu peux utiliser borg backup, très bonne solution en CLI. Fiable et sécurisé.

IPv6 en local ça marche plutôt bien, j'ai quand même eu l'occasion de me rendre compte que beaucoup d'applications ne s'exposent pas forcément aux IPv6 mais seulement aux IPv4, ce qui a certaines conséquences fâcheuses sur la transmission d'IP source (X-Forward et X-Real-IP sur Nginx par exemple). Du coup je garde toujours l'IPv6 sur mes périphériques, ils utilisent cette même connectivité en priorité pour la navigation externe, en interne pour accéder à mes services je reste sur de l'IPv4. Comme l'a dit @PiwiLAbruti, c'est de plus en plus banalisé, cela dit il faut noter certaines variations d'un FAI à l'autre et certains comportements propres à l'IPv6 : Chez certains le préfixe ne varie pas, ce qui est plus commode pour les enregistrements dans une zone DNS. Chez d'autres il varie comme varie une IPv4 dynamique, et ce n'est pas parce que votre IPv4 est fixe que votre préfixe le sera également. Normalement, un périphérique a une adresse IPv6 fixe, elle est basée sur le préfixe du FAI et le mode d'adressage (SLAAC ou DHCPv6). Ils ont également des IPv6 temporaires, utilisés pour ne pas naviguer avec son IPv6 fixe, celle-ci est renouvelée au bout d'un certain temps. En IPv6, on a ce qu'on appelle le Router Advertisement (RA) qui n'existe pas en IPv4, il peut fonctionner indépendamment, en conjonction, ou en soumission au serveur DHCPv6. Android ne permet pas d'utiliser IPv6 si on utilise un adressage stateful (donc DHCPv6), il faut obligatoirement un adressage SLAAC (basé sur l'adresse MAC du périphérique) Dernière notion importante, et qui peut poser des problèmes de connectivité si mal appréhender, c'est le trafic ICMP. En IPv4 on peut s'en passer, car ce sont les routeurs qui gère la fragmentation des paquets. En IPv6, pour des raisons écologiques entre autres, ce sont les machines source et de destination qui s'en chargent. Et pour se faire, il faut jouer sur deux paramètres : l'ouverture au trafic ICMP (ping) et le réglage de la MTU. Ca peut faire peur, mais ça demande surtout un peu de pratique et pas mal de lecture, pour ma part je ne me sens pas capable d'écrire un tutoriel à ce sujet, car je n'écris de tutoriel que sur ce que je considère maîtriser suffisamment, et ici ce n'est clairement pas le cas. Pédagogiquement, je n'ai jamais trouvé un tutoriel reprenant tous les points fondamentaux, il faut prendre par-ci par-là ce qui nous semble utile. Il m'arrive fréquemment de rouvrir ce livre, qui ne rentre pas énormément dans les détails mais qui a l'avantage d'être plutôt bien pensé et de donner des bases solides, notamment sur l'IPv6 : https://www.amazon.fr/Réseaux-informatiques-fondamentales-Architectures-Virtualisation/dp/2409035175/

Tu as un besoin plus explicite que ça ?

Pihole (et Adguard j'imagine) n'a pas besoin d'avoir une IPv6 pour traiter les requêtes DNS faites par un périphérique causant IPv6. Il se contente de passer les plats, donc si le ou les upstream DNS servers renseignés savent traiter l'IPv6, c'est bon. Ton deuxième NAS n'est accessible en IPv6 que pour certains ports depuis l'extérieur, mais là on parle bien d'un fonctionnement local non ? en local il ne se comporte pas différemment de ton autre NAS.

Pihole sur le NAS en redondance ? Je toune avec 2 pihole depuis plusieurs années, du coup je peux reboot un périphérique ou l'autre sans problème.

Vous vous égarez là. Quel besoin de modifier a mano (changement qui ne sera pas persistant au passage) le fichier hosts quand tu as le conditional forwarding qui sert justement à récupérer les noms d'hôte des périphériques de ton réseau à la place de leurs IP ? Paragraphe 5-C-2

Bienvenue 🙂

Regarde dans le tuto de monitoring, je propose une stack avec les différents compose.

A ma connaissance non. Mais si tes montages de volumes sont correctement faits, c'est l'affaire de 2 minutes de recréer un conteneur dans une stack sans perte de données.

Clairement il y avait peu de chance que ça donne quelque chose je suis d'accord avec toi, mais j'ai trouvé plusieurs retours en ce sens sur les forums officiels Synology, ça ne coûtait pas grand chose de tester.