oracle7

@glattering Bonjour, C'est une très bonne stratégie sécuritaire. Personnellement, comme j'ai une @IP publique dynamique, je n'ai pas d'autre choix que de passer par un "vpn.ndd.tld" qui pointe sur cette @IP publique. Je n'ai aucun problème de connexion avec OpenVPN, cela marche très bien et puis Fenrir dans son tuto n'émet qu'une recommandation à ce sujet sans l'interdire toutefois. Par ailleurs, saches que le port 1194 est le port par défaut DÉDIÉ au protocole OpenVPN. Le remplacer par le port 443 ne t'apportera pas plus de sécurité et sauf erreur de ma part, pourrait être susceptible de générer des dysfonctionnements aléatoires dans le fonctionnement d'OPenVPN. OpenVPN n'a d'ailleurs pas été prévu pour fonctionner avec ce port sinon cela se saurait ! Si tu crains pour la sécurité de la connexion, tu n'as qu'à modifier le niveau de chiffrement des clés employées dans le fichier .opvn de configuration pour l'augmenter sachant que celui-ci utilisé par défaut est déjà largement suffisant. Cela dit, on a le droit de devenir paranoïaque si besoin en est .... 😜 C'est toi qui vois 😏 PS : Il est préférable de ne pas poser la même question dans des posts différents (voir dans VPN Serveur). Merci. Cordialement oracle7😉

@Juan luis Bonjour, Merci pour l'appréciation. Pour répondre à ta question : tout simplement parce que le serveur DHCP de la LiveBox est nécessaire pour que le décodeur TV d'Orange puisse fonctionner. Ce serveur ne perturbe en rien le serveur DHCP du routeur car ils interviennent chacun sur un sous-réseau différent. Le routeur est en @IP fixe car il est le point d'entrée de mon réseau local et c'est aussi une obligation pour pouvoir l'intégrer à la DMZ de la LiveBox. Cordialement oracle7😉

Bonjour, Objectif de ce tutoriel : S’affranchir des problèmes de gestion de réseaux inhérents à la LiveBox 4 Fibre et du fait que l’on ne peut pas passer celle-ci en mode « bridge », en installant un routeur Synology RT2600ac dans la DMZ (DeMilitarized Zone) de cette LiveBox. Cette installation en DMZ va donc nous permettre de rediriger directement tous les flux de données entrants issus d’Internet vers le routeur qui lui, va assurer tout le travail de sécurisation des accès et de gestion du/des sous-réseaux locaux bien mieux que ne le fait la LiveBox. En effet, cette dernière possède un serveur DHCP très capricieux à l’usage, qui d’une part au-delà d’une quinzaine de périphériques se « mélange les pédales » ce qui rend la LiveBox instable (avec des reboot fréquents nécessaires) et d’autre part qui nécessite aussi le reboot de la Livebox à chaque changement de paramétrage du DHCP pour voir une correcte prise en compte de ces derniers. Tout cela sans parler du fait très important, qu’il est impossible de modifier les serveurs DNS de la LiveBox (Orange a bloqué cette possibilité il y a maintenant quelques années). D’où l’idée de s’affranchir le plus possible de la LiveBox, même si elle reste quasiment incontournable pour la majorité des utilisateurs, en transférant ses activités sur un routeur digne de ce nom et de surcroît paramétrable à souhait. Par ailleurs, avec cette configuration, l’ensemble des périphériques des sous-réseaux seront gérés par le serveur DHCP du routeur, la LiveBox quant à elle, ne servant alors plus que de modem pour à la fois la liaison vers Internet, le téléphone fixe sur IP et le décodeur TV d’Orange (i.e. si on dispose de ces deux derniers). J’attire tout de même votre attention sur le fait que mettre la LiveBox en DMZ, signifie qu’elle sera « transparente » à tous les flux de données avec donc toutes les conséquences inhérentes sur la sécurité que cela recouvre. Mais heureusement, on aura le routeur derrière pour veiller aux grains et nous protéger. Ci-après le schéma de principe de la configuration qui va être décrite dans le présent tutoriel : Une fois cette configuration en place et fonctionnelle, il sera alors temps pour vous de sécuriser le routeur ainsi que le/les NAS du réseau local et ensuite d’ajouter selon vos besoins, par exemple, un serveur DNS avec vos propres DNS, un serveur VPN, un Reverse Proxy, un certificat Let’sEncrypt, etc… Pour réaliser tout cela, sachez qu’il y a sur le présent forum tous les tutoriels nécessaires pour vous aider. A vous de les appliquer ou non. Voilà pour le discours préliminaire, on passe aux choses sérieuses … EDIT du 31/12/2020 : Le présent TUTO est aussi applicable dans le principe à une LiveBox 5, au détail près des écrans de l'interface qui peuvent être légèrement différents de ceux d'une LiveBox 4. A vous d'adapter/transposer en conséquence. Prérequis logiciels : · « Synology Assistant» ou « Advanced IP Scanner » (disponible sur Windows) ou « LanScan » (disponible sur Mac). 1 Préliminaires sur la LIVEBOX 4 Fibre Avant toutes choses, il convient d’initialiser correctement la LiveBox. Pour cela : · Connectez un PC/Mac sur le port LAN2 de la LiveBox. Laissez « libre » pour le moment, le port LAN1 de la LiveBox. Le sous-réseau « 192.168.1.0/24 » étant par défaut le sous-réseau LAN de la LiveBox, sur le PC/Mac, fixez manuellement l’@IP du PC/Mac sur ce sous-réseau (par ex : « 192.168.1.12 ») afin qu’il puisse s’y connecter. Ouvrez un navigateur WEB, connectez-vous en mode administrateur à la LiveBox en saisissant l’URL : « http://192.168.1.1 ». Par sécurité, on commence par effectuer une sauvegarde en local sur le PC/Mac, des paramètres de configuration existants de la LiveBox. Cliquez sur le bouton « Sauvegarder en local ». · Désactivez la sauvegarde automatique sinon la configuration actuelle sera automatiquement rétablie après l’opération suivante de réinitialisation. Cliquez sur le bouton « Sauvegarde automatique » pour le faire basculer sur « OFF ». · Réinitialisez la LiveBox avec les paramètres « usine ». Quand vous êtes prêt, cliquez sur le bouton « Redémarrer ». La réinitialisation s’effectue et la LiveBox redémarre à l’issue. Dès que la LiveBox a redémarré, ouvrez un navigateur WEB et depuis le PC/Mac connectez-vous en mode administrateur à la LiveBox en saisissant l’URL : « http://192.168.1.1 ». Menu « Réseau - DHCP » de la LiveBox : Conservez la plage d’@IP du serveur DHCP affectée par défaut, soit : de « 192.168.1.10 » à « 192.168.1.150 ». Cette plage vous laisse la possibilité future de pouvoir connecter directement à la LiveBox un nouveau périphérique. Laissez le service « DHCP » activé car il est nécessaire pour la connexion du décodeur TV si vous en utilisez un. Dans le cas contraire, vous pouvez alors désactiver le service « DHCP ». Menu « Réseau-NAT/PAT » de la LiveBox : assurez-vous qu’aucun transfert de ports n’est défini. Menu « Réseau – UpnP » de la LiveBox : Laissez le service « UpnP IGD » activé car il est nécessaire pour la connexion du décodeur TV si vous en utilisez un. Dans le cas contraire, vous pouvez alors désactiver le service « UpnP IGD ». Menu « Pare-feu » de la LiveBox : Réglez le niveau de sécurité sur « Faible ». Nota : Le pare-feu de la Livebox ne peut pas être complétement désactivé, tout au mieux on le règle le niveau de sécurité au minimum soit « Faible ». Toutefois, vous pouvez aussi personnaliser son action. Dans le cas présent, veillez à ce qu’il n’y ait aucune « règles de filtrage spécifiques » actives. Éventuellement vous pouvez à ce niveau autoriser le « ping ». Cela peut être utile en cas de problèmes réseaux. Menu « Wi-Fi » de la LiveBox : Désactiver les deux antennes 2,4 GHz et 5 GHz. On utilisera la fonction Wi-Fi du routeur bien plus stable et plus puissante. · Ne pas quitter l’interface d’administration de la LiveBox. 2 Connexion du routeur RT2600ac On procède maintenant à l’installation du routeur : Déballez le routeur. Installez les antennes Wi-Fi sur le routeur. Connectez le port WAN du routeur au port LAN 1 de la LiveBox. Branchez l’alimentation électrique du routeur. ⚠ Assurez-vous au préalable que le bouton On/off du routeur est bien sur « Off ». Démarrez le routeur en plaçant le bouton (On/Off) sur « On ». ⚠ Patientez … plusieurs minutes. Pour être sûr de partir sur une base saine, on va réinitialiser le routeur avec ses paramètres « usine » : pour cela, appuyez sur le bouton « reset » situé à l’arrière du routeur durant 10 sec et relâchez le. Le routeur redémarre. ⚠ Patientez … plusieurs minutes. Nota : A l’usage, il s’avère que le reset « usine » du routeur soit quelque peu capricieux. Il est fréquent d’avoir à le refaire plusieurs fois consécutives pour qu’il soit effectif. Ne soyez donc pas surpris de ce comportement ! Sur le PC/Mac, lancez une recherche avec « Synology Assistant » : Le routeur doit être trouvé à l’@IP « 192.168.1.x ». Notez cette @IP pour mémoire. Vérifiez que l’@MAC du routeur est bien : « 00 :11 :22 :33 :44 :55 » (i.e. la même que celle indiquée sur la boite d’emballage du routeur et qui sera appelée @MAC0 dans la suite). 3 Configuration de la LiveBox 4 Fibre Le routeur étant connecté à la LiveBox, on peut maintenant configurer correctement celle-ci : Menu « Mes équipements connectés » de la LiveBox : vérifiez la présence du routeur. Il est nommé par défaut « SynologyRouter ». Vous pouvez le renommer si nécessaire. Pour cela : Cliquer sur l’icône du routeur dans l’onglet « Carte ». L’onglet « Liste » s’affiche. Renommez le routeur, éventuellement modifiez le type d’équipement en sélectionnant le type voulu dans le popup. Bien évidemment la case « Autoriser en permanence » pour l’accès à Internet est cochée et enfin validez en cliquant sur le bouton « Enregistrer ». Menu « Réseau - DHCP » de la LiveBox : Afin de pouvoir intégrer le routeur à la DMZ de la LiveBox, il est nécessaire de lui attribuer un bail statique sur l’@IP de votre choix, par exemple « 192.168.1.2 ». Sélectionnez dans le popup : « SynologyRouteur ». Saisissez l’@IP du routeur : « 192.168.1.2 ». Saisissez l’@MAC0 du routeur : « 00 :11 :22 :33 :44 :55 ». Validez en cliquant sur « Ajouter ». Redémarrez la LiveBox afin de prendre en compte les modifications apportées au service « DHCP ». Quand le LiveBox est opérationnelle, redémarrez le routeur. ⚠ Patientez … plusieurs minutes. Ce redémarrage permet au routeur de récupérer sa nouvelle @IP. Ouvrez un navigateur WEB et connectez-vous en mode administrateur à la LiveBox en saisissant l’URL : « http://192.168.1.1 ». Sur le PC/Mac, lancez une recherche avec « Synology Assistant » : Le routeur doit être trouvé à l’@IP « 192.168.1.2 » avec l’@MAC0. Menu « Réseau - DMZ » de la LiveBox : intégrez le routeur à la DMZ. Sélectionnez dans le popup le « SynologyRouteur » et cliquez sur le bouton « Enregistrer ». Se déconnecter de l’interface d’administration de la LiveBox. 4 Configuration du Routeur RT2600ac On procède maintenant à la configuration proprement dite du routeur : Déconnectez le câble réseau du PC/Mac du port LAN2 de la LiveBox et connectez-le sur le port LAN1 du routeur. Sur le PC/Mac, lancez une recherche avec « Synology Assistant » : Le routeur doit être trouvé à l’@IP « 192.168.1.1 » avec l’@MAC1 : « 00 :11 :22 :33 :44 :66 » (@MAC1 du port LAN1 du routeur). ⚠ Cette @IP est définie dans les paramètres « usine » du routeur et ne peut être modifiée. Pour mémoire, Il existe une @MAC pour chacun des ports LAN physiques du routeur et une pour chaque réseau Wi-Fi configuré. · Ouvrez un navigateur WEB, connectez-vous au routeur en saisissant une des URL suivantes : « http://192.168.1.1 ». « http://router.synology.com » Une fois connecté, cliquez sur « Démarrer » pour lancer l'assistant de configuration de « Synology Router Manager » (SRM). Renseignez les informations pour configurer le compte administrateur et cliquez sur « Suivant ». o Nom : « votrePseudo ». o Mot de passe : « votre_mot_de_passe_fort ». o Confirmer Mot de passe : « votre_mot_de_passe_fort ». Renseignez les informations pour configurer le réseau WiFi et cliquez sur « Suivant ». o Nom (SSID) : « votre_réseau_WIFI ». o Mot de passe : « votre_mot_de_passe_fort ». o Confirmer Mot de passe : « votre_mot_de_passe_fort ». o Pays : « France ». Sélectionnez le mode de fonctionnement « Routeur sans fil », comme l’indique @unPixel dans son tutoriel sur la sécurisation et le paramétrage du routeur, d’ors et déjà par sécurité désactivez « Accès externe à SRM » et cliquez sur « Suivant ». Sélectionnez le type de connexion Internet « IP Manuelle » et saisir : Adresse IP : « 192.168.1.2 » Masque de sous-réseau : « 255.255.255.0 » Passerelle : « 192.168.1.1 » (@IP de la LiveBox). DNS Server : « 192.168.1.1 » (@IP de la LiveBox). Définir comme valeur par défaut : « Activé » Cliquer sur « Appliquer ». Un message de notification de l’assistant SRM indique alors que les sous-réseaux WAN et LAN spécifiés se recouvrent, ce qui peut bloquer la connexion à Internet. Pour mémoire, cette alerte est normale et logique puisque l’actuelle @IP de connexion pour la configuration du routeur est « 192.168.1.1 » et que l’on est en train de définir l’@IP « 192.168.1.2 » comme @IP de connexion à Internet, ces deux @IP appartenant au même sous-réseau « 192.168.1.0/24 », d’où le recouvrement. L’assistant SRM propose alors de corriger cette anomalie en créant lui-même un autre sous-réseau LAN. Cliquez sur « OUI » pour accepter la correction de configuration. L’assistant poursuit la configuration du routeur. ⚠ Patientez plusieurs minutes … jusqu’à la fin de la configuration. Une fois la configuration terminée, cliquez sur « Lancer le Synology Router ». Le sous-réseau LAN du routeur étant différent du sous-réseau LAN courant du PC/Mac, l’interface SRM ne s’affiche pas. C’est à la fois normal et logique ! SRM a affecté le routeur à un autre sous-réseau LAN. Il faut donc trouver ce nouveau sous-réseau pour s’y connecter et poursuivre la configuration. Dans la suite, adaptez les @IP données ici en exemple en fonction de votre cas particulier. Sur le PC/Mac, lancez une recherche avec « Synology Assistant » : Le routeur doit être trouvé avec l’@IP du sous-réseau LAN que l’assistant SRM lui a donc attribué, par exemple : « 10.0.14.1 » avec l’@MAC1 : « 00 :11 :22 :33 :44 :66 » (@MAC1 du port LAN1 du routeur). Sur le PC/Mac, fixez manuellement l’@IP du PC/Mac (par ex : « 10.0.14.12 ») sur le sous-réseau LAN du routeur (« 10.0.14.0/24 »). Ouvrez un navigateur WEB, connectez-vous au routeur avec le compte administrateur SRM spécifié précédemment, en saisissant l’URL : « http://10.0.14.1:8000 ». Ouvrez « Centre réseau – Statut » et vérifiez que le routeur est bien connecté à Internet. ⚠ L’affichage de l’état de la connexion n’est pas instantané il faut patienter quelques secondes. Ouvrez « Centre réseau – Internet » et vérifiez que le routeur utilise bien l’@IP qui lui a été attribué dans le sous-réseau de la LiveBox : « 192.168.1.2 ». Ouvrez « Centre réseau – Réseau local » et modifiez les paramètres de sous-réseau local du routeur pour lui attribuer l’@IP : « 192.168.2.1 ». Renseignez en corrélation du sous-réseau « 192.168.2.0/24 », les @IP de la plage du « serveur DHCP » (fixées de « 192.168.2.150 » à « 192.168.2.254 ») ainsi que celle de la passerelle (« 192.168.2.1 »). Nota : Dans cette configuration, les @IP inférieures à 150 sont réservées pour les « Réservations DHCP » (@IP fixe de certains périphériques). Indiquer également l’@IP de votre serveur DNS (ici dans l’exemple (« 192.168.2.10 ») mais si vous n’en avez aucun de configuré, saisissez simplement « 192.168.2.1 » (dans ce cas c’est votre routeur est votre serveur DNS par défaut). Modifiez l’@IP du « serveur DHCP invité » pour lui attribuer l’@IP « 192.168.3.1 ». De même, renseignez en corrélation du sous-réseau « 192.168.3.0 », les @IP de la plage du « serveur DHCP invité » (fixées de « 192.168.3.2 » à « 192.168.3.254 ») ainsi que celles de la passerelle (« 192.168.3.1 ») et du serveur DNS principal (« 192.168.3.1 » - votre routeur fait office de serveur DNS pour ce sous-réseau invité). Cliquez sur « Appliquer » pour enregistrer les modifications. Pour le réseau local, vous devriez obtenir un écran similaire à celui-ci, aux @IP près bien entendu : Redémarrez une dernière fois le routeur : Ouvrez un navigateur WEB, connectez-vous au routeur avec le compte administrateur SRM spécifié précédemment, en saisissant une de ces deux URL : « http://192.168.2.1:8000 ». « http://router.synology.com ». Poursuivre le paramétrage et la sécurisation du routeur sur la base du tutoriel de @unPixel « [TUTO] Sécuriser et paramétrer son routeur Synology ». Voilà, c'est un peu long, il faut beaucoup "jongler" avec les sous-réseaux, mais si vous êtes attentif cela ne devrait pas vous poser de problèmes. Sachez que depuis que j’ai mis en place cette configuration (cela fait bientôt 6 mois), je n’ai eu à faire AUCUN reboot de la LiveBox. J’en arrive presque à oublier cette dernière, donc pour moi le but initial est atteint 😊😊😊 Le fichier « .pdf » de ce tutoriel : [TUTO] RT2600AC en DMZ derrière Livebox4_20200604.pdf Bien évidemment, je prendrais en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ... Merci à @maxou56 pour ses compléments d’informations liées au monde Mac. Cordialement Oracle7😉

Bienvenue au club ... 😀

@maxou56 Merci d'avoir apporté cette nuance à mon propos qui effectivement était un peu trop restrictif. Je dormirais mon bête ce soir 😁 Cela dit dans le cas de @glattering j'avais bien raison dans ma réponse puisqu'il utilise le protocole OpenVPN avec les deux types (serveur et client). Cordialement oracle7 😏

@glattering Ah bon ? Tu es sûr de ton coup ? Cordialement oracle7😉

@glattering Bonjour, Je ne voudrais pas paraître rabat joie, mais je crains que (sauf erreur de ma part) ce que tu veuilles faire, ne soit pas possible. Que je sache un même NAS ne peut être à la fois serveur VPN et client VPN. D'où les problèmes que tu évoques. Pour faire ce que tu souhaites, il faudrait : que tu dispose d'un routeur placé derrière ta box. A ce moment là le routeur pourrait jouer le rôle de serveur VPN pour te permettre d’accéder à ton réseau local sous VPN depuis un client externe. ton NAS quant à lui, en tant que périphérique du réseau local de ton routeur, pourrait alors être le client de ton fournisseur VPN tiers externe comme tu le fait jusqu'à présent. Cordialement oracle7😉

Bonjour à tous, Après réflexion, j'aurais deux questions pour "initiés avertis" : Lors du déploiement du certificat, j'avais relevé dans le message d'exécution de la commande, une anomalie du type "http services were NOT restarted". Ne sachant pas comment la traiter, je l'avais provisoirement ignorée même si je n'ai heureusement pas constaté ensuite de dysfonctionnements qui lui seraient liés. Maintenant pour tout de même s'affranchir de cette anomalie, je me demande si on ne devrait pas ajouter à la commande de déploiement du certificat la commande suivante : --reloadcmd "/usr/syno/etc/rc.sysv/nginx.sh reload" qui a pour objet de relancer le serveur WEB du NAS. D'une part, peut-on donc effectivement ajouter cette instruction ? et d'autre part, si OUI, sera-t-elle suffisante pour lever l'anomalie ? Ma deuxième question concerne l'automatisation de l'application du nouveau certificat à tous les services. En effet, @bruno78 et moi même avons constaté que après sa création et/ou renouvellement, le nouveau certificat n'est pas ré-appliqué aux services à l'image de ce qui existait pour le certificat précédemment actif et marqué par défaut. Du coup, il faut refaire à la main toutes les affections. Pas top même si ce n'est pas la mer à boire en soit ! Par ailleurs l'observation des arcanes du NAS au niveau des certificats, et notamment dans le répertoire "/usr/syno/etc/certificate/_archive", nous révèle la présence de deux fichiers très intéressants : "DEFAULT" : qui contient le nom du répertoire où sont stockés les fichiers ".pem" et ".key" du certificat marqué par défaut, ce qui permet d'identifier (en principe) clairement le dernier certificat créé. "INFO" : qui lui contient le détails de toutes les affectations pour chaque certificat inscrit. Ce fichier "INFO" ressemble par exemple à cela : Nota : Pour une bonne compréhension, le premier niveau de balise, correspond au nom du dossier de chaque certificat. Les niveaux suivants parlent d'eux mêmes. { "A7eoae" : { "desc" : "ACME_Wilcard_LE_*.ndd.tld_new", "services" : [] }, "pAaeQI" : { "desc" : "ACME_Wilcard_LE_*.ndd.tld_old", "services" : [ { "display_name" : "webdav.ndd.tld", "isPkg" : false, "owner" : "root", "service" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "subscriber" : "ReverseProxy" }, { "display_name" : "nas.ndd.tld", "isPkg" : false, "owner" : "root", "service" : "FQDN", "subscriber" : "system" }, { "display_name" : "Synology Drive Server", "display_name_i18n" : "SYNO.SDS.Drive.Application:app:pkg_name", "isPkg" : true, "owner" : "SynologyDrive", "service" : "SynologyDrive", "subscriber" : "SynologyDrive" }, { "display_name" : "Log Receiving", "display_name_i18n" : "helptoc:logcenter_server", "isPkg" : true, "owner" : "root", "service" : "pkg-LogCenter", "subscriber" : "LogCenter" }, { "display_name" : "DSM Desktop Service", "display_name_i18n" : "common:web_desktop", "isPkg" : false, "owner" : "root", "service" : "default", "subscriber" : "system" }, { "display_name" : "FTPS", "isPkg" : false, "owner" : "root", "service" : "ftpd", "subscriber" : "smbftpd" } ] } } C'est ici que ma réflexion "tordue" intervient et en espérant ne pas être trop confus : ne pourrait-on pas via un Shell script manipuler ce fichier "INFO" pour y intervertir : les noms des dossiers respectifs des certificats notés ici dans la balise "desc" avec les suffixes "old" et "new", ainsi qu'intervertir aussi les balises "desc" correspondantes ? Voilà par exemple ce à quoi on devrait arriver pour le nouveau fichier "INFO" après permutations : { "pAaeQI" : { "desc" : "ACME_Wilcard_LE_*.ndd.tld_old", "services" : [] }, "A7eoae" : { "desc" : "ACME_Wilcard_LE_*.ndd.tld_new", "services" : [ { "display_name" : "webdav.ndd.tld", "isPkg" : false, "owner" : "root", "service" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "subscriber" : "ReverseProxy" }, etc ... Enfin, ce Shell script serait à exécuter en complément de la commande de renouvellement du certificat (après celle-ci), objet de la tâche périodique crée dans DSM. Mes compétences en Shell script étant limitées pour réaliser le dit Shell script et si l'idée est potentiellement réalisable, j'en appelle à une bonne âme pour prendre de son précieux temps afin d'en écrire le code qui va bien. Au final, on disposerait ainsi d'une automatisation complète du processus de création/renouvellement d'un certificat LE. Merci d'avance aux amateurs de code pour leur aide. Cordialement oracle7😉

@GrOoT64 et @TuringFan Bonjour, Pardonnez mon ignorance, mais pourquoi faire une redirection visible et pas plutôt invisible ? Cela me paraît mieux qu'elle soit invisible surtout vis à vis de regards indiscrets par dessus l'épaule, lors de la saisie de l'URL, et qui du coup pourraient voir la "vraie" URL, Non ? Cordialement oracle7😉

@Jeff777 Bonjour, Je n'ai pas dû suffisamment attiré ton attention dans ma précédente réponse : J'attire ton attention sur le fait que la variable d'environnement "CERT_DNS" correspond au script ".sh" que ACME va employer selon le fournisseur de domaine. Ce script est situé dans "/usr/local/share/acme.sh/dnsapi". Donc ta modification ne me semble pas correcte. A voir ... Désolé, mais remplacer "dns_ovh" par "ns.mondomaine.ovh" comme tu sembles le faire, ne peut pas marcher ! Et de fait, je crains que tu n'ai pas bien compris le mécanisme mis en oeuvre. Je t'explique : Avec cette variable "CERT_DNS", le script "acme.sh" sait qu'il doit exécuter le Shell script spécifique au fournisseur OVH en l'occurrence le script "dns_ovh" situé dans le répertoire "/usr/local/share/acme.sh/dnsapi" sur ton NAS. Sans cette variable, le Shell script "acme.sh" ne peut deviner seul quel fournisseur de domaine tu as. Par exemple, si tu avais été, pour ton domaine, chez "Cloudflare" ou chez Microsoft avec "Azure" il t'aurait fallut renseigner la dite variable avec respectivement "dns_cf" ou "dns_azure". Il faut bien voir que ces Shell scripts sont SPECIFIQUES à chaque fournisseur de domaine pour attaquer leurs API respectives sur leurs serveurs DNS. Je crois, mais je peux me tromper, comme tu es ton propre serveur DNS, tu n'as pas l'API nécessaire, ni le script adéquat pour aller examiner ta zone DNS sur ton propre serveur DNS pour, entres autres actions, y inscrire temporairement des enregistrements "TXT" afin de vérifier l'authentification de ton domaine. C'est ce que font précisément ces scripts lors du processus de création du certificat. J'espère ne pas avoir été trop confus dans mon explication. Il est parfois difficile de décrire de tels mécanismes simplement. @bruno78 J'en suis arrivé au même constat que toi. Après tout, ce n'est qu'un moindre mal et pas la mer à boire, non ? A moins que l'on trouve une solution pour automatiser cela, mais j'en doute. J'ai donc laissé un commentaire en ce sens dans le tutoriel. Cordialement oracle7😉

@TuringFan Je vais essayer de te répondre simplement en vulgarisant la chose : OUI. PuTTY, par exemple, enregistre la clé d'hôte de chaque serveur auquel tu te connectes, dans le registre Windows (je ne sais pas ce qui se passe sous Mac). Ensuite, à chaque fois que tu te connectes à un serveur, il vérifie que la clé d'hôte présentée par le serveur est la même clé d'hôte que lors de ta dernière connexion. Si ce n'est pas le cas, il t'envoie un un avertissement et il te donne la possibilité d'abandonner la connexion avant d'y saisir des informations privées (comme un mot de passe). Ensuite, le processus de connexion est sécurisé dans le sens où les informations échangées entre le client et le serveur, sont transmises de façon cryptée grâce au protocole SSH qui est employé ici. Pour mémoire : SSH (qui signifie «shell sécurisé») est un protocole de haute sécurité récemment conçu. Il utilise une cryptographie puissante pour protéger une connexion contre les écoutes, les détournements et autres attaques. Ce protocole est notamment conçu pour se protéger contre une attaque réseau appelée usurpation d'identité. c'est à dire qui consiste à rediriger secrètement ta connexion vers un autre ordinateur, afin d'envoyer ton mot de passe à la mauvaise machine. En utilisant cette technique, un attaquant pourrait apprendre le mot de passe qui protège ton compte de connexion, puis pourrait se connecter comme s'il s'agissait de toi et utiliser le compte à ses propres fins. D'où le danger ! D'un autre coté si tu utilises un simple couple "Login + MdP", tout ce petit monde circule en clair sur le réseau, tu imagines bien la suite ... Il n'y a pas à proprement parler de "reset" de SSH à faire (je te rappelle que SSH est un protocole de communication). Donc, on ne se prends pas la tête, on supprime la clé publique partout ou elle a été installée et on recrée un nouveau couple "clé privée - clé publique". C'est aussi simple que cela. Par la suite, le renouvellement périodique de ce couple est une sage résolution à ne pas oublier. Comme le dit @Fenrir dans son Tuto, cela ne sert à rien de modifier le port par défaut, sauf effectivement à complexifier l'exploitation courante. DE plus, tu ne fais que retarder de très peu le problème lié à une attaque potentielle. Le plus efficace est donc de ne pas ouvrir le port 22 à l'extérieur (i.e. de ne pas activer ce service sur ton routeur). Pour te donner un exemple, avant d'installer un routeur, j'avais ouvert le port 22 sur mon NAS (en fait pour X mauvaises raisons, mais bon ...) eh bien tous les jours c'est des dizaines d'alertes de tentatives de connexions , chinoises notamment mais pas que, qui tombaient, heureusement le mécanisme de blocage du NAS semble, je devrais plutôt dire, est assez efficace. Depuis, le port 22 est fermé et le service SSH est désactivé sur mon RT et là, comme par hasard, plus aucunes attaques constatées. Pourvu que cela dure, je croise les doigts 🤔 Au final, en y réfléchissant bien, pourquoi aurais-je besoin d’accéder en SSH à mon réseau local depuis l'extérieur ? Je n'ai pas trouvé pour l'instant de motif/raison valable à un tel besoin. Pour le scan des ports, au delà de voir s'il est ouvert ou non, c'est entre autres l'objectif de voir s'il y a derrière, en fait, un service qui répond. La connaissance de ce service permet alors à l'assaillant d'adapter son attaque. De toutes façons, il me paraît difficile d'empêcher ces scans, du moins je ne connais pas de moyens pour. Désolé, je ne sais répondre à ce point mais indirectement je te renvoie à ma réponse du point 4. Voilà, difficile de faire plus court et c'est ma vision des choses qui n'engage que moi ... Cordialement oracle7😉

A tous, J'ai mis à jour le tutoriel pour tenir compte des premiers retours effectués. § 2 : Utilisation du "vrai" root pour la connexion SSH au lieu du "sudo -i" § 3.1 : Utilisation de l'Id principal de connexion OVH § 5.2.1 : Réaffectations de services à faire suite à la création du certificat en mode Ajout. Cordialement oracle7😉

@bruno78 1 - OUI, si tu veux effectivement remplacer le certificat par défaut existant, mais je te rappelle qu'il sera ECRASE et donc irrécupérable ! 2 - Je ne saurais dire si on peut mettre la commande "--days XXX" dans la commande que l'on met dans le planificateur de tâches de DSM. J'avais plutôt compris qu'elle était à ajouter à la commande "--issue" utilisée pour la création du certificat et/ou lors du renouvellement avec "--force" (au lieu de "--renew" qui génère un message d'erreur). mais j'ai peut-être mal interprété les choses, non ? Maintenant, il faut voir si c'est possible, car je n'ai pas vu jusqu'à présent ce genre d'option dans les différents tutos trouvés sur la toile, pour la commande à mettre dans le gestionnaire de tâches de DSM. Cordialement oracle7😉

@bruno78 Je reviens sur la problématique du renouvellement que tu as évoquée dans une réponse précédente : J'ai examiné le corps du Shell scrypt "acme.sh", effectivement par défaut si la date de renouvellement n'est pas atteinte, le script la programme 60 jours après (variable DEFAULT_RENEW=60). Toutes fois, cette valeur par défaut de 60 jours peut-être modifiée en spécifiant l'instruction "--days XXX" avec "XXX" = nombre de jours pour le prochain renew. Attention cette commande "--days XXX" ne peut être utilisée qu'en conjonction de la commande "--issue". Donc là, on pourrait fixer les fameux 85 jours pour assurer le renouvellement avec juste un peu de marge avant l'échéance effective et donc l'ajouter ("--days 85") à la commande de création du certificat. Ton avis ? Reste, après le problème de la tâche "cron" qui n'est a priori pas affinable dans DSM au niveau de sa période de reproduction. Affaire à creuser donc ... Cordialement oracle7😉 @GrOoT64 Non pas de VM, mais un GRAND MERCI pour ta remarque, car (et je n'y avais pas prété suffisamment attention) mes attributions du certificat aux services étaient restées sur celles du certificat précédent par défaut. Voilà pourquoi on ne voyait rien sur ma capture d'écran. En conséquence, il faut que je reprenne mon commentaire de constat dans le tuto. Les assignations ne sont pas reprises automatiquement. Il faut les configurer toutes manuellement ce qui je trouve n'est pas plus mal au final. Je n'ai pas procédé de cette façon. J'ai importé directement sur le routeur les fichiers . key, .crt et .csr depuis une copie sur mon PC de ceux situés dans le répertoire de génération "/volume1/Certs" (que je garde précieusement !). Donc pas d'import de fichiers .pem. Cordialement oracle7😉

@GrOoT64 Bon bah, tant mieux que ce ne soit que cela mais c'est tout de même bizarre tu en conviendras, qu'un MdP de session SSH impacte ainsi l'exécution d'un Shell script. Je ne vois pas le rapport entre les deux ????? Cordialement oracle7😉

@GrOoT64 Tout affaire sent l'omission de l'export d'une variable d'environnement avant de lancer la commande de création du certtificat. Vérifies bien ... Cordialement oracle7😉

@PPJP +1, j'avais oublié celle là que nous avait donné de mémoire @Fenrir en son temps. Comme je ne l'ai pas encore testée, difficile d'en parler. @bruno78 Du coup en conjonction de l'instruction "--staging" et en employant tout simplement la méthode "annule et remplace" du § 5.2.1 ? A voir ... Cordialement oracle7😉

@Jeff777 et @bruno78 La limite est de 50 certificats pour un domaine donné mais effectivement, on ne peux en dupliquer que 5 par semaine. Voir ici toutes les limitations de Let'sEncrypt. Cordialement oracle7😉

@GrOoT64 Je te confirme ce que @Jeff777 vient de te dire, il faut se connecter avec l'Id Principal de ton compte OVH. Perso, je me connecte toujours avec lui, d'où je n'ai pas ce ce problème. Comme manifestement il y a une ambiguïté je vais amender le tutoriel pour bien préciser cela. Cordialement oracle7😉

@GrOoT64 Quelque part c'est rassurant, je ne suis pas le seul à avoir cette anomalie, heureusement qui n'est pas bloquante. Cordialement oracle7😉

@GrOoT64 Effectivement, C'est revenu, les serveurs Synology sont de nouveau disponibles ce matin. J'ai juste des mises à jour à faire manuellement malgré que les cases soient toutes cochées ????? Ce qui arrive tout de même assez régulièrement ! Bizarre ... Cordialement oracle7😉

@bruno78 Bonjour, As-tu essayé en exportant en préalable à la commande de renouvellement, les variables d'environnement : SYNO_Create=1 et SYNO_Certificate="Nom_du_Certificat" ? Cordialement oracle7😉

@Stigmate101 Bonjour, Dans ma précédente réponse du 12 mai dernier, je t'avais donné un lien vers un configurateur de chez Eaton, c'est déjà une bonne première approche pour estimer ce calcul. Par ailleurs, cela ne sert à rien de calculer au plus juste, donc précisément, la puissance à installer, car de toutes façons tu appliqueras un coefficient moyen de 1,6 (c'est la pratique courante) au total de puissance en Watt de tous tes équipements connectés à l'onduleur. Ensuite à la vue du résultat obtenu tu choisis l'onduleur dont la puissance est la plus proche en VA de ce résultat. Ne te prends pas plus la tête ... et gardes raison. De plus, il te faut prévoir de la marge pour les connexions supplémentaires futures qui interviendront immanquablement. Cordialement oracle7😉

@TuringFan Bonjour, Je découvre cet écran, je ne me souviens pas l'avoir déjà vu. Quelle application as-tu lancé pour l'obtenir ? A la réflexion, je n'ai pas encore configuré un PC comme client externe (faute de matériel) c'est donc peut-être normal et dans ce cas tu as raison.A priori je dirais qu'il faut suivre le processus. Personnellement, pour installer le client "VPN Plus" sur mon smartphone, je suis allé sur "Google Play" et j'ai tout simplement installé l'application "Synology VPN Plus". Il est aussi disponible sur l'Apple store. Ensuite tu saisis : "ndd.tld:noport" (noport = celui que tu as défini dans VPN Plus, xx43 ?, ton pseudo (Id de connexion à DSM), ton MdP, cocher les 2 cases et "Connecter". C'est on ne peux plus simple... Cordialement oracle7😉

@TuringFan OUI pour les 3 prérequis avec pour P1 : Un CNAME me parait suffisant : "xxxxx.ndd.tld. 0 CNAME nddd.fr.". Perso, je n'ai aucun enregistrement "A" dans ma zone DNS chez OVH. OUI aussi pour les 1 à 5 (sauf erreur de ma part). Et pour rajouter de la sécurité au point 1, tu exploites l'astuce donnée par @GrOoT64 qui verrouille l'utilisation des "xxxx.ndd.tld" au seul local et VPN par l'extérieur. Pour cela, tu rajoutes un profil d'accès qui n'autorise que ton réseau local et refuse tout le reste, aux redirections que tu as créées dans le reverse proxy. Je l'ai fait c'est super ! Ainsi la saisie depuis l'extérieur d'un "xxxx.ndd.tld" hors de ton VPN n'a aucune chance d'aboutir sauf sur une page d'erreur. Pour le point 5, il faut aussi bien évidemment que les droits utilisateur soient correctement réglés sur le dossier partagé qui contient les vidéos. Cordialement oracle7😉 @TuringFan Je ne comprends pas trop ton idée. Ce que tu appelles ton portail VPN n'est jamais que l'application cliente du VPN (en l'occurence VPN Plus) qui te permet d'établir la connexion VPN. Ensuite tu utilises un navigateur dans le quel tu tapes "xxxxx.ndd.tld" pour atteindre le service voulu. Rien de plus à faire ou alors j'ai raté un truc ? Cordialement oracle7😉