.Shad.

Il faut effectivement voir dans les fichiers de config si effectivement ce port 6690 serait appelé par une variable, en ce cas ce serait facile. Si c'est hardcodé, ça semble compromis. En tout cas rien dans DSM ne permet de modifier ce port. De la redirection de port en sortant je m'en sers pour mes équipements IoT, pour que je sois sûr que ceux auxquels j'autorise un accès vers le net utilisent les DNS de mon choix. Mais ça necessite a minima un routeur semi-pro voir pro, ou un périphérique intermédiaire (Un Rpi pourrait servir d'intermédiaire entre le PC et le routeur de l'entreprise, au cas où on ne pourrait pas rediriger le port d'origine sur le client).

Alors à moins que je ne me trompe, il doit aussi utiliser un logiciel de redirection de port au niveau de son client également non ? genre Multi Port Forwarder | Verigio

Top manière de faire : installer apache via Docker à la version 2.2 : httpd Tags | Docker Hub Moins top manière de faire : désinstaller Apache 2.4, installer le paquet 2.2 suivant l'architecture de ton NAS : Synology Archive Download Site - Index of /download/Package/Apache2.2/2.2.34-0121 Par contre pour un DS923+ je ne sais pas quelle architecture est la bonne, @maxou56 ou @PiwiLAbruti pourront peut-être t'éclairer davantage.

Première option : demander au service informatique s'ils peuvent débloquer ce port en trafic sortant. Ca ne te coûte pas grand chose d'essayer, tu leur donnes la doc pour les aider à prendre leur décision. Deuxième option : installer VPN Server sur ton NAS, t'y connecter et transférer les données. ATTENTION : il faut que le tunnel VPN passe par un port autorisé en trafic sortant, donc passer par exemple sur 443/UDP (peu de chances que ton employeur bloque ce port). Ensuite tu auras juste à entrer l'IP VPN (ou le nom d'hôte) du NAS pour synchroniser tes données. Troisième option : utiliser une clé 4G, ça t'affranchit de passer par la connexion de ton employeur, mais ce n'est pas la solution la moins onéreuse.

Il faut créer une autre règle : https://mail.monsite.fr -> http://localhost:PORT_ROUNDCUBE

Ok là c'est bizarre, est-ce que par hasard tu as installé Nginx Proxy Manager ? car c'est soit lui, soit Nginx de DSM, mais pas les deux. Tu peux aussi tenter de réduire le niveau de chiffrement TLS voir si ça a un effet sur la connexion par Safari : Tu peux également essayer de te connecter en navigation privée, car ça pourrait être un problème de cache qui ne se vide pas, d'autant plus que dans le tutoriel l'auteur coche HSTS, qui a ses avantages mais aussi ses inconvénients, comme le forçage HTTPS. Enfin dernière chose, ton nslookup prouve que tu ne joins pas localement ton NAS, sinon ça te renverrait une IP privée, donc si tu n'as pas de serveur DNS local, tu sais d'ores et déjà que ta box ne fait pas de loopback (ou qu'il n'est pas activé) et que donc pour causer à ton NAS, tu passes par internet.

@mangousta On insistera visiblement jamais assez sur l'importance critique d'avoir des sauvegardes des données ayant de la valeur. Le changement de modèle de NAS aurait été presqu'une formalité.

@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.

En effet, il faudrait vraiment que tu aies un Windows obsolète (XP ?) pour devoir utiliser SMBv1. Tu peux vérifier quel protocole est utilisé pour te connecter en SMB sur ton NAS depuis Powershell (en admin) avec la commande : Get-SmbConnection Ca te donnera le dialecte utilisé pour tes montages réseau :

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/