oracle7

@Anthotho Bonjour, Peut-être que cela relève d'un problème de fichier .htaccess dans le reverse proxy pour PhotoStation. Donc sans garantie, essaies toujours cela : Coté NAS : Reverse proxy : créer une règle --> https://photo.ndd.tld:443 => http://localhost:80 Pour pouvoir accéder directement à photo station en https il faut aussi activer le websocket dans la redirection du reverse proxy : sur l'onglet « En-tête personnalisé », cliquer sur « Créer » et sélectionner « Websocket » Pour s'affranchir du "/photo", cela va se passer au niveau du .htaccess RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] RewriteCond %{HTTP_HOST} ^photo.ndd.tld$ RewriteRule ^$ https://photo.ndd.tld/photo [L,R=301] Serveur DNS Local : ajouter un enregistrement de type CNAME photo.ndd.tld => ns.ndd.tld (pour la résolution locale) Coté OVH (zone DNS) : Attention seulement si tu n'as pas mis en place de wilcard pour ton domaine (i.e. *.ndd;tld 0 CNAME ndd.tld.). · ajouter un enregistrement de type CNAME photo.ndd.tld => ndd.tld Au final il suffit de taper ndd.tld/photo pour accéder à Photo Station en HTTPS. Par contre avec DSPhoto il ne faut pas rajouter /photo car l'application l'ajoute automatiquement dans l'url de connexion avec Photo Station, ni rajouter le port 5001 car l’application utilise le port standard HTTPS 443 (ou http 80). Depuis l’extérieur, il faut taper : pour atteindre Photo Station : https://photo.ndd.tld/photo pour DSphoto : photo.ndd.tld --> là il ne faut pas rajouter /photo car l'application l'ajoute automatiquement dans l'url de connexion avec Photo Station, ni rajouter le port 5001 car l’application utilise le port standard HTTPS 443 (ou http 80). Cordialement oracle7😉

@Dimebag Darrell Bonjour, De ce que j'ai pu voir en survolant le lien, et si tu as déjà un monitoring de NAS en place, tu devrais n'avoir qu'à : copier coller la partie qui va bien du fichier telegraf.conf dans le tien, ajouter l'@IP de ton agent sur ubiquiti, et importer le dashbord dans grafana. Rien de bien compliquer me semble-t-il, non ? Cordialement oracle7😉

@Dimebag Darrell Bonjour, A partir du moment où ton équipement Ubiquiti est accessible en SNMP et que tu disposes des MIBs correspondantes, alors OUI c'est possible. Je l'ai fais pour un autre type de matériel (caméras HIK). Il existe quelque chose ici à toi de voir si cela te convient ? Cordialement oracle7😉

@JisséL Bienvenue à toi sur ce forum, tu verras c'est une mine d'informations. J'invite à regarder et suivre ces deux TUTOs pour bien démarrer. TUTO : Débuter avec un NAS Synology TUTO : Sécuriser les accès à son NAS Cordialement oracle7😉

@Maximeva Bienvenue à toi sur ce forum, tu as déjà dû voir que c'est une mine d'informations. J'invite à regarder et suivre ces deux TUTOs pour bien démarrer. TUTO : Débuter avec un NAS Synology TUTO : Sécuriser les accès à son NAS Cordialement oracle7😉

@Anthotho Bonjour, Parfait, tu avances ! 👍😀 Il te faut simplement ajouter un enregistrement de type CNAME avec un wilcard qui pointe sur ton domaine dans la zone DNZ OVH, càd au final quelque chose comme cela : *.ndd.tld. 0 CNAME ndd.tld. (Voir le point 3 d'une de mes réponses précédentes lorsqu'on a repris la configuration du DynHost). N'oublies pas que les mises à jour de domaine chez OVH prennent jusqu'à 24h pour se répliquer sur tous les serveurs DNS du monde. Donc, ne t'étonnes pas si cela ne semble pas marcher immédiatement. Tu peux suivre cette diffusion en entrant ton domaine sur ce site https://www.whatsmydns.net Attention tu ne verras rien pour le type CNAME, c'est normal. Essaies pour voir, les autres types dans le popup. Cordialement oracle7😉

@Mic13710Bonjour, Ok je me suis mal exprimé. Merci d'avoir relevé la chose. Comme pour moi il est évident qu'il faut créer un certificat pour un domaine avec son wilcard pour éviter (entre autres) dans DSM d'être limité au niveau de la zone "Autre nom de l'objet" en citant tous les "sous-domaines" dont on a besoin. En effet, à mon sens on atteint très vite pour la chaine ainsi constituée, la limite des 255 caractères imposée par Synology. De plus, la création d'un wilcard évite avantageusement d'avoir à compléter la zone DNS chez le fournisseur de domaine à chaque fois qu'on a besoin de gérer un nouveau "sous-domaine". J'ai donc voulu dire qu'avec une demande de certificat dans DSM ce n'était pas possible de déclarer un wilcard pour un domaine tiers et que l'on ne pouvait le faire qu'avec un domaine en xxx.synology.me. C'est tout. Donc @Anthotho désolé si mon assertion incomplète (ma pensée a été plus rapide que ma main à l'écrire), a pu te perturber. @Anthotho Chez OVH comme tu as une @IP externe dynamique et que par conséquent tu as défini un DynDNS alors dans la zone DNS il faut supprimer l'enregistrement de type A qui fait pointer ton domaine sur ton @IPexterne (vu qu'il semble exister à la vue ta copie d'écran précédente) car cet enregistrement vient en conflit si je puis dire, avec la définition de DynDNS par ailleurs. Cordialement oracle7😉

@Anthotho Bonjour, Sauf erreur de ma part, je crains bien que oui. Du moment que tu sais te connecter en SSH au NAS et que tu suis les indications pour les commandes à exécuter, cela devrait le faire, tu n'est pas plus bête qu'un autre ... Il te faut toutefois être très attentif à ce que tu tapes et bien faire attention aux C/C qui peuvent être problématiques dans leur résultats surtout si tu captures des caractères invisibles (blancs, fin de lignes, etc ..) qui perturbent le système ensuite. Donc soit rigoureux et attentif et tout ira bien. Enfin, ne passes à une étape suivante que lorsque tu as bien compris ce que tu faisais lors de l'étape courante. Cordialement oracle7😉

@axb Bonjour, Réseau/Paramètres de DSM : Décocher "Rediriger automatiquement les connexions HTTP vers HTTPS sur le bureau DSM" sinon cela casse le processus de reverse proxy. Cordialement oracle7😉

@Anthotho Bonjour, Ton pare-feu et ton reverse proxy me semblent corrects. Juste dans le pare-feu, ton réseau local est bien en 192.168.0.0 et pas 192.168.1.0 par hasard ? A ce propos je ne penses pas que tu ais à gérer plus de 65534 machines/@IP sur ton sous réseau local alors pour sécuriser un peu plus, réduis son masque à 255.255.255.0 au lieu de 255.255.0.0 cela te fera 254 machines donc @IP possibles ce qui est déjà pas mal, non ? Sinon, je t'invites à suivre mon TUTO pour le certificat LE car là sauf erreur de ma part tu sembles vouloir utiliser/passer par DSM qui est plutôt fait pour les domaines en xxx.synology.me. Pour un domaine personnalisé comme le tien il faut faire autrement. Pour être complet dans le conseil, si tu maîtrises l'application "docker" sur le NAS, tu as aussi ce TUTO. Cordialement oracle7😉

@PiwiLAbruti Bonjour, Rassures-toi, je ne confond pas. Sinon, que préconiserais-tu comme limitation pour les ports 465, 587 et 993 dans le sens entrant : Limiter géographiquement en source à la France, cela serait-il suffisant pour toi ? Limiter sur @IPsources mais alors je ne vois pas très bien sur les quelles ou même sur quelle plage ? Cordialement oracle7😉

@Anthotho Bonjour, C'est souvent une action nécessaire et radicale (bonne initiative de ta part ! 🤗) car à force de configurer des choses dans tous les sens (et pas que des bonnes) on fini par empilé tout un tas de problèmes qui se masquent plus ou moins les uns les autres que cela fini par devenir inextricable. Bonne continuation pour la suite. Cordialement oracle7😉

@PiwiLAbruti Bonjour, Oui, c'est effectivement le cas, j'ai redirigé naturellement les ports 25, 465, 587 et 993 vers mon NAS dans mon routeur. C'est bien expliqué aux §6.2.1 et §6.2.2 du TUTO même si effectivement je n'ai pour une fois pas donné/précisé la raison sous-jacente de ces transferts de ports. Peut-être parce que trop évident ? Évident en tous cas vis à vis de pouvoir atteindre le NAS (franchir mes barrages de sécurité en place) pour qu'il puisse recevoir simplement des infos de cet ordre. Cordialement oracle7😉

@Anthotho Bonjour, Le message est pourtant clair, tu as bien saisi ton ndd.ovh pour le nom d'hôte ? Peut-être qu'un coup de ménage est aussi à faire sur ton compte synology. https://account.synology.com/fr-fr/overview pour s'assurer qu'il n'a pas en mémoire autre chose. Dans ce cas sur ton compte Synolmogy pour ton NAS qui doit être référencé normalement (sinon il te faut l'ajouter), déconnectes le DDNS enregistré voire supprimes le (menu 2 points verticaux à droite). Attention tu peux aussi en avoir un pour un DDNS sur un domaine en xxxx.synology.me. Dans ce cas ne supprimes pas ce dernier. Puis relance le test de connexion depuis DSM. A ce niveau, vérifies que l'@IP externe renseigné&e est bien la même que celle déclarée pour le DynDNS chez OVH. EDIT : je viens de voir ta réponse. Du coup, dans DSM supprimes carrément le DDNS sur OVH et recrées le. Cordialement oracle7😉

@Anthotho Bonjour, Bah, voilà tu y es arrivé ... 🤗 C'est pas mieux comme cela ? Dans l'écran "Modifier une entrée de la zone DNS" tu saisis : Pour "Sous-domaine" : tu saisis simplement une " * " (le ". " sera automatiquement mis à la fin, ce qui donne --> " *.ndd.ovh. " Pour "TTL" : tu laisses "Par défaut" cela le mettra automatiquement la valeur " 0 " Pour "Cible" : tu saisis " TonDomaine.ovh. " (avec le " . " à la fin !) Pourquoi une " * " pour le sous-domaine : " * " se dit "wilcard" et cela remplace n'importe quel nom de sous-domaine. Donc cela t'évite d'avoir à créer une ligne de type CNAME pour chacun de tous les sous-domaines que tu utilises. 1 ligne au lieu de XXX, c'est quand même plus simple et plus léger qu'une longue liste, non ? Cordialement oracle7😉

@.Shad. @PiwiLAbruti Bonjour, J'ai retrouvé un échange qui corrobore l'info sur le pseudo blocage du port 25 par Orange : voir ici la réponse de "PHILDUR" expert reconnu du monde Orange s'il en est. Il me semble bien avoir lu par ailleurs (donc sous réserves) que dans le cas de la Livebox, le port 25 était même bloqué "en dur" dans le firmware de celle-ci. Mais comme il n'y a pas de blocages au niveau " des équipements réseaux" le NAT de ce port est peut-être bien un moyen de contournement possible. Cordialement oracle7😉

@Anthotho Bonjour, Ne t'intièques pas , on va reprendre : Si tu ne supprimes pas le DynHost précédemment créé, il est normal que tu ne puisses en créer un nouveau sur ton domaine. Donc, supprimes le. Ensuite tu recrées ton DynHost (voir le TUTO ici). Dans le premier écran (Create a DynHost username) de l'étape 1, tu saisis notamment un "subdomain" (tu n'as pas le choix le champ est obligatoire) sachant qu'il n'a rien à voir avec celui de l'étape 2 (c'est juste une même appelation de champs). Dans le second écran (Create a DynHost) de l'étape 2, pour le champ "subdomain" (qui est non obligatoire) tu ne saisis rien (ou bien essaies simplement en saisissant une " * "). Normalement, tu devrais retomber sur quelque chose qui ressemble à l'image ci-dessus. avec ton domaine "ndd.tld" qui pointe vers ton @IPexterne (celle de ta box). Ensuite dans ta zone DNS, tu crées un enregistrement de type CNAME tel que : " *.ndd.tld. 0 CNAME ndd.tld. " (ne pas oublier les " . " à la fin des ndd.tld. Cela te permettra de créer/utiliser autant de "sous-domaines" que tu auras besoins au niveau du NAS. Maintenant sur le NAS Dans Accès externe / DDNS tu dois avoir quelque chose du genre : où "suffixe" = ce que tu as mis dans l'écran du point 2.1 ci-dessus. Puis fais un test de connexion : ton @IPexterne devrait s'afficher et avec le Statut "Normal" en vert si tout est OK. Et là tout sera clair coté DDNS. Cordialement oracle7😉

@Anthotho Bonjour, Non, en plus le champ n'est pas obligatoire ! Si tu laisses vide ce champ, alors ton DynHOST sera tout simplement du type "MonDomaine.tld" qui pointera sur ton @IPexterne. Donc, à l'usage tes sous-domaines seront du type "sousDomaine.MonDomaine.tld".--> par ex : "fichier.ndd.tld", "monNAS.ndd.tld". Au final tu auras bien la correspondance entre ton domaine "MonDomaine.tld" et ton @IPexterne. Par contre si tu renseignes un "sous-domaine" ton DynHost sera du type "sousDomaine.MonDomaine.tld" (ce qui ne sera pas du tout la même racine) avec la conséquence que lorsque tu voudras utiliser des "sous-domaines" ils seront alors forcément du type "sousDomaine.sousDomaine.MonDomaine.tld". Ce qui est bien plus long à saisir à l'usage. --> Soit par exemple : "fichier.sousndd.ndd.tld", "monNAS.sousndd.ndd.tld". Au final, tu n'auras pas la correspondance entre ton domaine "MonDomaine.tld" et ton @IPexterne car ce sera le domaine "sousDomaine.MonDomaine.tld" qui seul pointera sur ton @IPexterne. Tu me suis ? Cordialement oracle7😉

@CyberFr Bonjour, Désolé, ce n'est pas aussi exclusif, j'ai une @IP dynamique avec un DDNS du type something.fr et aucun soucis. Cordialement oracle7😉

@TuringFan Bonjour, Un wilcard te permet justement d'utiliser n'importe quel domaine de niveau juste inférieur à ton domaine "principal". Je serais tenté de mettre le même certificat sur les deux NAS. Cordialement oracle7😉

@pascalg57 Bonjour, Donc si ton DDNS est "nas.ndd.tld" alors n'oublies pas que pour le reverse proxy, tu atteindras par ex FileStation en mettant en place une redirection du type : https://fichier.nas.ndd.tld:443 --> http://localhost:7000. Bien évidemment Tu taperas donc comme URL "fichier.nas.ndd.tld" en local, et/ou pour DSFile : "fichier.nas.ndd.tld:443". Cordialement oracle7😉

@.Shad. Bonjour, Ton lien est très explicite, cela marche parce que l'on passe tout simplement par un serveur SMTP authentifié sur les ports sécurisés 465 ou 587, c'est tout. Maintenant je ne suis pas le seul, au vu des retours de ceux qui ont mis en œuvre avec succès le présent TUTO. Cordialement oracle7😉

@.Shad. Bonjour, Oui j'ai un enregistrement du type : mondomaine.tld. 3600 MX 10 mondomaine.tld. A l'émission, le serveur MPS au lieu d'être un émetteur SMTP "pur", MPS s'adresse directement (comme on le fait avec un client mail ordinaire) au SMTP du FAI (qui va faire le boulot à sa place de contrôle/diffusion et de discussion avec les autres relais SMTP). C'est ce que j'ai compris du moins au travers de mes lectures sur la toile, qu'on me reprenne bien volontiers si je suis en erreur. Ensuite au retour en réception donc, le mail prend exactement le chemin inverse à celui utilisé lorsque on envoie un mail. Ni plus ni moins. (quelque part tel que comme sur le schéma du §4.2.5 dans le tuto qui résume le processus de contrôle DMARC). Cela dit, je pense que @PiwiLAbruti serait plus à même que moi pour te détailler le processus exact des échanges entre relais SMTP et le cheminement d'un mail. Je n'ai pas compris que le pseudo blocage d'Orange se fasse dans le sens réception mais qu'il n'intervient uniquement dans le sens émission d'un mail puisqu'il ignore les connexion sur le port 25 qui ne viennent pas de son réseau. Cordialement oracle7😉

@pascalg57 Bonjour, Excuse moi mai j'ai du mal avec ta notation "DDNS". Appelons STP un chat un chat et que recouvre "DDNS" dans ton texte : comme dans le tuto "ddns.ndd.tld" ou autre chose ? Dans le tuto pour la partie reverse proxy, quand je dis "https://aliasApplication.ddns.ndd.tld:443 " pour "aliasApplication" je ne parle pas de l'alias défini dans l'onglet "Application" pour l'application mais simplement d'un nom "facile" à retenir du style pour FileStation : "fichier", "mesfiles", "toto" ou "tartempion", etc ... Donc le nom que tu veux et qui te permette de savoir que c'est FileStation que tu veux atteindre en saisissant par ex "tartempion.ndd.tld" comme URL dans ton navigateur. Donc si le point 5.4 de "NAS partie DSM" est OK tu peux supprimer la redirection NAT du port 5000 dans la box. Pour l'accès avec le phone dans l'URL de connexion pour toutes les applications DSxxxx il faut impérativement préciser le port 443 sinon cela ne marche pas effectivement. Cordialement oracle7😉

@Mic13710 Bonjour, Oups !!! tu fais bien, désolé, dans le feu de l'action j'ai continuer à lui répondre ici. J'aurais dû l'inviter à créer un post spécifique. Cordialement oracle7😉