.Shad.

J'ai un Pixel 4a mais sur lequel j'ai gardé la stock rom. J'en suis extrêmement satisfait pour le prix, il me manque juste la reconnaissance faciale par rapport à mon One Plus, mais les photos sont justes incroyables pour quelq'un pas du tout versé dans ce domaine comme moi. Comme tu le dis, avec une rom custom tu pourras faire le ménage. 😉 Concernant le Fair Phone, ben comme tu dis c'est une question de conviction avant tout. Moi ce qu'il me fallait c'était un appareil faisant rapidement la mise au point, et à ce prix-là, y a aucune concurrence possible.

Bienvenue ! 🙂

Attention IPv6 c'est plus compliqué, la notion d'adresse privée/publique n'a pas lieu d'être, on parle d'IP de lien local ou d'IP routable. Une adresse IPv6 routable (ou globale), càd qui n'est pas de la forme fe80::, fd00:: ou ::1, fonctionne aussi bien en privé qu'en publique. Les adresses ont une "portée", une IP globale est utilisable partout. Une adresse de lien local uniquement en privé. Ca ne veut pas dire qu'en privé il faut utiliser l'IP de lien local. Car le routeur utilise le NDP (Neighbour Discovery Protocol), il connaît ses proches voisins et leur permet de discuter entre eux. Je ne m'étendrai pas plus car même si j'ai beaucoup lu sur l'IPv6, c'est vaste et suffisamment différent conceptuellement de l'IPv4 telle qu'elle existe (limitée par son nombre d'adresses). Mais pour résumer non, si tu vois l'IPv6 globale de ton NAS dans tes logs, ça ne veut pas dire que tu passes par l'extérieur.

@MilesTEG1 Le loopback (ou hairpinning NAT) c'est lorsque une requête arrive sur l'interface interne d'un routeur (192.168.1.1 par exemple) et qu'elle revient par son interface WAN, donc IP publique. Dans ce cas le périphérique cible de la requête initiale verra comme IP source l'IP interne du périphérique émetteur (192.168.1.2 par exemple). Alors qu'en réalité la requête est partie vers un serveur DNS upstream, et qu'elle est revenue jusqu'à chez toi par le WAN. Le loopback sans règle NAT ne fonctionne pas. Si pas de loopback, et sous réserve que les règles NAT soient bien présentes, ça fonctionnera aussi. Mais la cible verra la requête arriver de ton IP publique. Et pas de périphérique local.

Clés privées ? SSH ?

Ben je sais pas, dans cette impression d'écran : La première ligne dans ta zone c'est bien : nas.ndd.tld NS ns.nas.ndd.tld non ? Si je suis ta logique de faire de nas.ndd.tld ta racine. Ca c'est la configuration du DDNS, ça permet à l'internet de savoir vers quelle IP dynamique pointe nas.ndd.tld Depuis internet, en IPv4, il y a dans l'ultra-majorité des cas une box en tête de chaque réseau domestique. Mais en local, tu fais directement pointer sur le NAS. Il n'y a aucun lien entre l'enregistrement A et le fait que ton serveur DHCP ne distribue pas l'IP du NAS comme DNS aux périphériques de ton réseau local. Un serveur DHCP distribue une IP, pas un nom de domaine. Pour moi tu dois reprendre le tutoriel sur le DNS, voir éventuellement te renseigner via Google sur la forme d'une zone minimale, car le tutoriel a certains défauts, notamment pour l'intégration d'un proxy inversé. Et bah si c'est fonctionnel, fais-toi des favoris avec https en entête. 😄

Je parle de sa zone DNS publique, celle chez son prestataire où se trouve son dynhost. Pourtant sur cette impression d'écran : Ca ressemble plus à nas.ndd.tld que ndd.tld 😉 Et moi je te parle du principe : si coucou.ndd.tld (hypothétique) est son dynhost, il n'est pas obligé d'utiliser coucou.ndd.tld dans tous ses autres sous-domaines (toto.coucou.ndd.tld, toto2.coucou.ndd.tld, ...) si le certificat a été émis pour ndd.tld. Donc je le répète : est faux. Il n'y a pas de polémique, c'est factuel.

Tu es bien en 4G ? donc pas en local, connecté par exemple au Wifi de ton smartphone en mode point d'accès sans fil ? Non ça n'a rien de difficile, ça revient à ce que j'avais supposé au niveau du dynhost. Bon par contre tu ne dis que maintenant que tu as une zone DNS locale, ou j'ai loupé quelque chose dans tes messages précédents... D'ailleurs il te manque un enregistrement A dans ta zone DNS : nas.ndd.tld A IP_locale_du_NAS Et comment tu veux résoudre localement tes accès au proxy inversé si par exemple tu n'as pas d'entrée fichiers.nas.ndd.tld par exemple qui pointe en CNAME vers nas.ndd.tld ? Mais pour moi ton serveur DNS n'est même pas pris en compte, la preuve : Quand tu demandes au NAS quel serveur DNS il utilise, il te dit qu'il utilise ta box. Tu dois dire au serveur DHCP de celle-ci d'envoyer l'IP du NAS comme serveur DNS primaire à ses clients DHCP. Il y a un gros ménage à faire avant de vouloir faire fonctionner correctement ton proxy inversé, notamment au niveau de ta zone DNS et la diffusion de celle-ci par le serveur DHCP de ton réseau local.

Ok je pense voir le problème, tu as condamné une porte, tu as mis une porte blindée à côté, mais tu continues de toquer à la porte condamnée. Disons au hasard que ton nom de domaine acheté c'est pascalg57.fr, histoire que ce soit plus clair que mon.ndd. Quelque part dans ta zone DNS tu as un visiblement un dynhost nas.pascalg57.fr qui pointe vers ton IP dynamique. @oracle7 a tort quand il dit que si ton ddns c'est nas.pascalg57.fr, tes alias doivent être de la forme coucou.nas.pascalg57.fr, ce que tu utilises pour le dynhost est un sous-domaine comme les autres, c'est juste que les sous-domaines que tu utiliseras pour ton proxy inversé feront l'objet d'un CNAME dans ta zone DNS vers le sous-domaine utilisé pour ton dynhost. Donc tes entrées de proxy inversées peuvent être de la forme fichiers.pascalg57.fr, dsm.pascalg57.fr, etc... Et tu auras dans ta zone DNS : fichiers.pascalg57.fr CNAME nas.pascalg57.fr dsm.pascalg57.fr CNAME nas.pascalg57.fr En l'état, tu as visiblement demandé un certificat pour nas.pascalg57.fr (le dynhost) et fichiers.nas.pascalg57.fr, très bien on va faire avec. Dans le portail des applications tu as attribué le port personnalisé 45002 pour File Station. Et tu as créé une entrée de proxy inversé qui dit que lorsque tu fais une requête sur fichiers.nas.pascalg57.fr sur le port 443 (ce qui se traduit dans ton navigateur par https://fichiers.nas.pascalg57.fr) sur le proxy inversé (et c'est le cas depuis l'extérieur, vu que ton port 443 sur la box est redirigé vers le NAS), il redirige ça vers localhost (le NAS) sur le port 45002 (autrement dit http://localhost:45002). Donc déjà, je t'invite à faire ce test via la 4G, par un navigateur tu tapes : https://fichiers.nas.pascalg57.fr (en adaptant le nom de domaine évidemment). Je pense que ça marchera sous réserve que le port 443 est bien translaté. De même si tu tapes http://fichiers.nas.pascalg57.fr, la redirection HTTP -> HTTPS devrait opérer. Maintenant en local, que tu aies du loopback ou pas sur ta box, dans tous les cas ça doit marcher, sauf que sans loopback tu passeras par internet pour aller voir ton NAS, avec du loopback tu causeras avec en restant dans ton réseau local. Dans ton cas, si tu tapes http://nas.pascalg57.fr:45002, c'est normal que ça ne fonctionne pas. Tu n'as pas de zone DNS locale, donc ta box demande à Internet à quoi est sensé mener nas.pascalg57.fr, ça lui renvoie ton IP publique. Et ta box refuse toute demande sur ce port. Donc : Baskets ? tu passes pas. Si tu tapes http://IP_du_NAS:45002 tu n'auras aucun problème.

Ben faut pas faire la moue, c'est plutôt une bonne nouvelle, ça veut dire que tu n'as pas translaté le port 5000 de ton routeur vers ton NAS, ce qui est normal si tu comptes passer par le proxy inversé. Ca c'est très bien aussi, ça veut dire que ton port 80 est, lui, bien translaté, et que la redirection HTTP -> HTTPS est fonctionnelle. Le routeur reçoit une demande sur le port 80 (HTTP) via l'IP publique, il translate au NAS, Apache écoute le port 80, et upgrade le protocole HTTP vers HTTPS via le .htaccess Donc Webstation fonctionne et tes redirections également. A priori ton proxy inversé fonctionne correctement (on s'entend bien que mon.ndd correspond à une entrée de ton proxy inversé ?) Dernier écueil possible, la résolution DNS à l'intérieur de ton réseau local. Que donne : nslookup mon.ndd Et depuis le NAS en SSH : cat /etc/resolv.conf Idéalement, si tu peux aussi mettre une impression d'écran de l'entrée du proxy inversé correspondant à mon.ndd comme l'a demandé @MilesTEG1, ça permettra de s'assurer que tout est bon de ce côté-là.

Ce qui va te protéger des ransomwares ce sont les bonnes pratiques plus qu'autre chose. On fait attention à ce qu'on stocke, et surtout, on met en place des montages SMB a minima. On ne se connecte pas en SMB avec l'utilisateur admin sur son NAS, on utilise un maximum d'utilisateurs en lecture seule. Si on a besoin d'écrire sur le NAS depuis SMB, on le fait avec un utilisateur aux droits a minima (cela demande de réfléchir à la structure de ses dossiers partagés, des groupes d'utilisateurs, etc...). Si tu ne te sers pas de SMB, que tu as sécurisé ton NAS suivant les prescriptions du forum et que tu fais attention à ce que tu télécharges, le risque de ransomware est quasi nul. Si malgré tout ça doit arriver, la sauvegarde est effectivement le moyen le plus efficace de s'en prémunir. Tu as possibilité de compresser tes sauvegardes (réglage par défaut je crois), mais tu ne vas pas gagner 50% hein. 😉 Idéalement prévois un espace de stockage équivalent à celui de ton NAS principal. Ca me semble très optimiste, déjà avoir son serveur mail personnel avec une IP dynamique et un port 25 fermé (j'ai cru comprendre que seul Free permettait de le débloquer, par défaut les FAI (du monde entier quasiment en fait) le bloque) me semble relativement incertain. Si c'est un NAS de sauvegarde, une baie, éventuellement deux baies si l'espace de stockage initial est important, parfois deux disques de moindre capacité coûtent moins chers qu'un gros disque. Pour moi aucun intérêt au RAID, on parle de sauvegarde, d'espace de stockage mort. Un NAS une baie d'ancienne génération (je dirais à partir de la série 14) se trouve pour rien quasiment d'occasion. Et tu prévois un disque dur externe pour une sauvegarde locale chez toi, que tu caches bien si tu souhaites te protéger des risques d'un cambriolage. HyperBackup chiffre par TLS les échanges via le port 6690. Je n'ai jamais fait, mais je pense que ça se fait au niveau des dossiers partagés à leur création. Optimale je ne sais pas, mais ça me semble être une bonne idée. Attention qu'à mon avis Snapshot Replication fonctionne uniquement si tu utilises le système de fichiers BTRFS. Ce qu'il te faut c'est un certificat valide sur le NAS distant, qu'il soit issu de Let's Encrypt ou auto-signé. De préférence Let's Encrypt. Pourquoi ne pas utiliser le domaine gratuit Synology pour le NAS distant ? Tu as déjà bien anticipé la chose, j'insisterais sur le fait d'avoir une sauvegarde locale tout de même, sur un disque externe.

Quelle est ta demande déjà ? Ce n'est pas clair. Si tu veux parcourir les homes des différents utilisateurs depuis un ordinateur, il suffit de faire un montage SMB avec un utilisateur du groupe administrateurs, ce sont les seuls habilités à le faire. En revanche je le déconseille fortement. Il vaut mieux ne monter que les home d'utilisateurs spécifiques avec les credentials de ces utilisateurs. Si tu montes homes en tant qu'admin, si tu crées un fichier dans le home de utilisateur_1, le fichier appartiendra à ton utilisateur admin. Le home est fait pour que les fichiers qui s'y trouvent soient la propriété de l'utilisateur en question.

Bienvenue parmi nous !

Welcome !!

Tu as ajouté l'argument -t à ta commande, dixit la doc : https://docs.docker.com/engine/reference/commandline/exec/ Or, tu es en cron, donc il n'y a pas de terminal, pour moi il faut enlever cet argument.

Tu es sûr que tu avais réglé la durée de validité de ton API sur illimité ? parce qu'il a l'air de ne plus avoir accès à la zone par l'API.

Je pense que justement c'est le principe de ne pas les faire. J'ai quand même une cinquantaine de conteneurs répartis sur trois machines, et vu que 98% des màj ne posent aucun problème... 😄 On verra, c'est pour tester dans un premier temps.

Pas sûr de comprendre. Tu veux dire en TLS avec un certificat auto-signé ? parce qu'OpenVPN sans certificat à ma connaissance ça n'existe pas. Il y a un tutoriel fonctionnel sur ce forum pour la mise en place d'un serveur VPN : Bienvenue sinon !

D'où il a plusieurs fois InfluxDB ? Je ne vois qu'une image moi, la 1.8

Aucune idée A partir du moment où l'image a été modifiée par ton intervention pour mettre en place le fix de @bruno78, l'image n'est plus identique à celle de GitHub, donc oui effectivement soit @bruno78 met en place une image publique, ou privée avec des credentials d'accès, soit Watchtower ne s'occupe plus de mettre à jour cette image. Pourquoi pas ? Je suis en train de tester Diun qui ne fait que surveiller les mises à jour, un peu comme le mode "monitor-only" de Watchtower, je verrai s'il y a fonctionnalités supplémentaires intéressantes, la vérification se fera dans la nuit de vendredi à samedi. EDIT : Grillé par @bruno78 😄

S'il a juste ça ndd doit mener au NAS, c'est obligatoire, et en précisant le port, il doit arriver sur ce qu'héberge le NAS sur ce port.

@Jeff777 avec ce qu'il a défini pour l'instant il n'est pas obligé de déclarer un domaine supplémentaire, son domaine racine pointe vers l'IP du NAS donc il peut déjà théoriquement accéder à DSM. Et il a déjà mis en place un proxy inversé, mais faut déjà voir si sa zone fonctionne correctement (ça a l'air d'être le cas).

Ok ça c'est bon, c'est bien le NAS qui répond. Donc essaie de faire comme a dit @Jeff777 va sur http://xxx.synology.me:5000 (ou autre port de DSM personnalisé) ça devrait t'amener sur DSM. Et tu peux vérifier que tu es bien en local en faisant un nslookup sur xxx.synology.me, ça renverra l'IP privée de ton NAS et pas ton IP publique. Ensuite il faudrait une impression d'écran de ton onglet proxy inversé et une pour ton entrée pour DSM en particulier.

On va déjà voir si le serveur DHCP envoie correctement l'adresse du NAS en tant que serveur DNS, si tu es sous Linux tu peux taper : cat /etc/resolv.conf Sinon dans Windows, on peut faire un bête nslookup : nslookup www.google.fr

Salut, pour t'aider il nous faudrait des impressions d'écran de ta zone DNS et ton serveur DHCP. Tu peux cacher tes IP publiques et ton ndd, mais pas les IP privées. Et que cherches-tu à atteindre qui t'amène sur ta box ?