Aller au contenu

oracle7

Membres
  • Compteur de contenus

    5 235
  • Inscription

  • Dernière visite

  • Jours gagnés

    71

Tout ce qui a été posté par oracle7

  1. oracle7

    Insérer nouveau disque

    @cotp Bonjour, As-tu suivi le conseil de @firlin de mettre ton disque 12To seul dans le NAS ? et de redémarrer le NAS. Bien évidemment tu auras préalablement formaté ce disque par ex sous Win en NTFS avec un seul et unique volume prenant toute la capacité du disque. De toutes façons, lors de l'installation automatique de DSM, DSM le formate une nouvelle fois "à sa sauce", d'ailleurs d'entrée il te prévient que toutes les données existantes seront supprimées pendant l'installation. Par ex : C'est seulement ensuite lors de la création du groupe de stockage qu'il te proposera le format Btrfs ou ext4 : Cordialement oracle7
  2. @Stixen92 Bonjour, Lors de la toute première utilisation de la commande de création du certificat on utilise les deux options "--set-default-ca --server letsencrypt" afin de forcer la création d'un certificat Let'sEncrypt sinon c'est ZeroSSL qui est utilisé par défaut. Ensuite, acme.sh inscrit (garde en mémoire) le choix de passer par LE au lieu de ZeroSSL dans la variable d'environnement DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' qu'il inscrit dans le fichier account.conf (/usr/local/share/acme.sh/account.conf). Je n'en ai pas parlé dans le TUTO car c'est une action normalement automatique et transparante. Pour ceux qui ne l'avaient pas, le constat est que le simple fait de la rajouter est suffisant pour forcer un certificat LE. Par la suite, si cette variable DEFAULT_ACME_SERVER est présente, acme.sh la relit directement automatiquement et c'est aussi pourquoi les deux options suscitées ne sont alors plus utiles dans la commande de création du certificat et il faut les retirer avant de relancer le processus. C'est sans impact sur la suite. Cordialement oracle7
  3. @PiwiLAbruti Bonjour, Très intéressant tout cela, reste à voir le futur prix des caméras ... Seront-ils concurentiels ? Cordialement oracle7
  4. @Patrix Bonjour, Il faut être patient, toute modif dans ta zone DNS chez OVH peut mettre jusqu'à 24h00 pour être répercutée sur l'ensemble des serveurs DNS mondiaux. Après pour les Mails, cela peut-être un problème de SPF, DKIM et ou DMARC. Je te renvoie au TUTO pour leur configuration. Cà c'est pas bien, tu joue avec le jeu là et tu t'expose à des déconvenues ... Mais ce n'est que mon avis. Cordialement oracle7
  5. @Patrix Bonjour, Désolé j'ai oublié de te répondre sur ce point. Comme c'est un domaine Synology (comme ceux en synology.me) je crains que ce ne soit moins souple à l'usage qu'un domaine en ndd.tld (quoi que ...). Au final, dans DSM > Acces externe > DDNS , tu définis un DDNS en xxxx.myds.me qui pointe sur ton @IP externe puis tu crées un certificat LE pour ce domaine xxxx.myds.me avec son wilcard *.xxxx.myds.me (dans autre nom de l'objet) et le tour est joué ... Après tous tes "sous-domaines" seront du type yyyyy.xxxx.myds.me. Cordialement oracle7
  6. @Einsteinium Bonjour, Finalement j'ai trouvé ! En fait, ce qui correspond au point B) 2) du TUTO, j'ai renommé toutes les variables d'environnement SAVED_SYNO_xxxx en SYNO_xxxx tout simplement et là aucun soucis le deploy s'est effecté correctement : root@MomNAS:/volume1/docker/scripts_install/acme# docker exec Acme sh -c "acme.sh --deploy -d 'ndd.fr' --deploy-hook synology_dsm" [Thu Oct 27 13:16:13 UTC 2022] Logging into 172.18.0.1:5000 [Thu Oct 27 13:16:14 UTC 2022] Getting certificates in Synology DSM [Thu Oct 27 13:16:14 UTC 2022] Generate form POST request [Thu Oct 27 13:16:14 UTC 2022] Upload certificate to the Synology DSM [Thu Oct 27 13:17:34 UTC 2022] http services were restarted [Thu Oct 27 13:17:34 UTC 2022] Success Le log : [Thu Oct 27 13:16:12 UTC 2022] Running cmd: deploy [Thu Oct 27 13:16:12 UTC 2022] Using config home:/acme.sh [Thu Oct 27 13:16:12 UTC 2022] default_acme_server='https://acme-v02.api.letsencrypt.org/directory' [Thu Oct 27 13:16:12 UTC 2022] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Thu Oct 27 13:16:12 UTC 2022] DOMAIN_PATH='/acme.sh/ndd.fr' [Thu Oct 27 13:16:12 UTC 2022] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Thu Oct 27 13:16:12 UTC 2022] _cdomain='ndd.fr' [Thu Oct 27 13:16:12 UTC 2022] SYNO_Certificate='Certif_Acme_LE_Docker' [Thu Oct 27 13:16:12 UTC 2022] _base_url='http://172.18.0.1:5000' [Thu Oct 27 13:16:12 UTC 2022] Getting API version [Thu Oct 27 13:16:12 UTC 2022] GET [Thu Oct 27 13:16:12 UTC 2022] url='http://172.18.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Thu Oct 27 13:16:12 UTC 2022] timeout= [Thu Oct 27 13:16:12 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L ' [Thu Oct 27 13:16:13 UTC 2022] ret='0' [Thu Oct 27 13:16:13 UTC 2022] Logging into 172.18.0.1:5000 [Thu Oct 27 13:16:13 UTC 2022] POST [Thu Oct 27 13:16:13 UTC 2022] _post_url='http://172.18.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Thu Oct 27 13:16:13 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L ' [Thu Oct 27 13:16:14 UTC 2022] _ret='0' [Thu Oct 27 13:16:14 UTC 2022] token='TrAwA6QSsGyBc' [Thu Oct 27 13:16:14 UTC 2022] Getting certificates in Synology DSM [Thu Oct 27 13:16:14 UTC 2022] POST [Thu Oct 27 13:16:14 UTC 2022] _post_url='http://172.18.0.1:5000/webapi/entry.cgi' [Thu Oct 27 13:16:14 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L ' [Thu Oct 27 13:16:14 UTC 2022] _ret='0' [Thu Oct 27 13:16:14 UTC 2022] escaped_certificate='Certif_Acme_LE_Docker' [Thu Oct 27 13:16:14 UTC 2022] Generate form POST request [Thu Oct 27 13:16:14 UTC 2022] Upload certificate to the Synology DSM [Thu Oct 27 13:16:14 UTC 2022] POST [Thu Oct 27 13:16:14 UTC 2022] _post_url='http://172.18.0.1:5000/webapi/entry.cgi?api=SYNO.Core.Certificate&method=import&version=1&SynoToken=TrAwA6QSsGyBc&_sid=KSGjwX7bQHU3cFrm0CT0rxUJyKm5ArjSKX9sdS2SMscAvKAj8qQFevPpUAMQ98zoxjD7NFd3nIfM7t2-Rh1hAQ' [Thu Oct 27 13:16:14 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L ' [Thu Oct 27 13:17:34 UTC 2022] _ret='0' [Thu Oct 27 13:17:34 UTC 2022] http services were restarted [Thu Oct 27 13:17:34 UTC 2022] Success Et au passage le fichier "http.header" a bien été lui aussi renseigné. Du coup, le point B) 2) serait-il erroné ? Ton avis STP ? Pour moi oui, dans la mesure où le script acme.sh attend des variables d'environnement bien spécifiques nommées SYNO_xxxxx pour son exécution et pas leurs sauvegardes SAVED_SYNO_xxxxx qui au passage non pas été réécrites dans le fichier account.conf à l'issue du déploiement. Maintenant, ce qui m'échappe c'est que d'autres ont suivi ce TUTO et n'ont pas rencontré, du moins pas remonté, cette anomalie ????? Cordialement oracle7
  7. @Patrix Bonjour, Puisque ton @IP externe est dynamique, il te faut utiliser un DynDNS (DynHost, DDNS). Chez OVH voir : https://docs.ovh.com/fr/domains/utilisation-dynhost/ À voir aussi : https://aradaff.com/relier-une-ip-dynamique-a-un-nom-de-domaine-fixe/ Donc avec un DynDNS, tu n'as pas à et ne doit pas définir manuellement ce fameux enregistrement "A". Tu n'as que les "CNAME" éventuels à définir. Cordialement oracle7
  8. @Einsteinium Bonjour, Après avoir fait une installation "fraiche" de DSM7 sur un NAS d'un ami, j'ai pu créer sans problème un certificat LE mais lorsque je lance le deploy je récolte systèmatiquement une erreur d'authentification. J'ai pourtant bien créé un utilisateur spécifique tel qu'indiqué dans le TUTO et x fois vérifié son password (même testé avec et sans caractères spéciaux). username : AcmeDocker password : Xxx9xx$xxxxXxx0xx$ root@MonNAS:/volume1/docker/scripts_install/acme# docker exec Acme sh -c "acme.sh --deploy -d 'ndd.fr' --deploy-hook synology_dsm" [Wed Oct 26 19:17:56 UTC 2022] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 7 [Wed Oct 26 19:17:56 UTC 2022] Logging into 172.18.0.2:5000 [Wed Oct 26 19:17:56 UTC 2022] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 7 [Wed Oct 26 19:17:56 UTC 2022] Unable to authenticate to 172.18.0.2:5000 using http. [Wed Oct 26 19:17:56 UTC 2022] Check your username and password. [Wed Oct 26 19:17:56 UTC 2022] If two-factor authentication is enabled for the user, set SYNO_TOTP_SECRET. [Wed Oct 26 19:17:56 UTC 2022] Error deploy for domain:ndd.fr [Wed Oct 26 19:17:56 UTC 2022] Deploy error. Sinon pas de 2FA pour l'utilsateur qui déploie, depuis le NAS en SSH, je ping sans problème le conteneur 172.18.0.2 et le réseau bridge du conteneur semble correct : root@MomNAS:/volume1/docker/scripts_install/acme# docker inspect synology-network [ { "Name": "synology-network", "Id": "2a969450a3140d78e785cc887066eb2fc94a11cffb383b23b6f260dda1f6fd38", "Created": "2022-10-26T14:58:26.87054153+02:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.18.0.0/24", "Gateway": "172.18.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "a3b329fc53b64b1a6ec034a7d1bca4c2bea44a36fdbbe4f94dadbe04ad15779d": { "Name": "Acme", "EndpointID": "83bdf0820ac5f1dd8b2f19b7a806786b490ef246bc516066d1c5d343e225c2e3", "MacAddress": "d2:ca:ab:cd:18:02", "IPv4Address": "172.18.0.2/24", "IPv6Address": "" } }, "Options": { "com.docker.network.bridge.name": "br-synology" }, "Labels": {} } ] A noter aussi que contrairement à une installation précédente sur une autre machine, le fichier http.header reste vide. Y-a-t-il un rapport ? En tous cas, il y a sûrement un problème aussi de ce coté là. Mais là aussi je sèche ... J'ai peut-être omis ou mal paramétré quelque chose dans DSM7 mais je ne vois pas quoi ni où. Je tourne donc en rond à chercher d'où pourrait venir ces problèmes (mais surtout le premier). Auriais-tu SVP une éventuelle piste/idée à m'indiquer ? Cordialement oracle7
  9. @limannzerga Bonjour, Je crains que ton problème soit juste une mauvaise configuration. Une petite recherche sur le site de Cyberghost te donne ceci : https://support.cyberghostvpn.com/hc/fr/articles/360012606699-Comment-configurer-CyberGhostVPN-sur-votre-peripherique-Synology-NAS Cordialement oracle7
  10. @PiwiLAbruti Bonjour, Ma réponse concernait uniquement sa version "@work", je l'avais compris comme cela ... Par ailleurs, je suppose, avec l'usage de ces routeurs respectifs, qu'il souhaite mieux gérer et mieux sécuriser ses réseaux locaux @home et @work, dans tous les cas bien mieux que ne le feraient ses LB avec leur "défauts" et leurs limitations. Cordialement oracle7
  11. @TwistedJ Bonjour, Il y a 2 solutions pour connecter un téléphone à ta Livebox : Si le modèle de téléphone est compatible, tu peux associer le téléphone directement à la Livebox, la base ne servira qu'au chargement de celui-ci. Sinon, il suffit de brancher la base de ton téléphone sur le port 1 ou 2 dédié à la téléphonie de ta Livebox. Cordialement oracle7
  12. @TwistedJ Bonjour, Bien sur que si, tu peux faire LB en DMZ directement vers le RT2600. La partie Tél VOIP est à dissociée car indépendante, il y a une prise dédiée à cela sur la LB. Mais au final, si tu as suivi correctement mon TUTO que je t'avais déjà indiqué, tu devrais t'en sortir aisément. Rien de bien compliqué ... Home --> LB en DMZ 192.168.1.1 ----- 192.168.1.2 RT2600 192.168.2.1 -------- Switch TPlink ------- X périphériques en 192.168.2.x Cà c'est normal puisqu'il est connecté au réseau local de la LB qui lui est en 192.168.1.0/24. En plus sur la LB il faut donner une @IP fixe au RT2600 via un bail statique. Ensuite, c'est à toi, comme dit dans le TUTO de créer un réseau local en 192.168.x.0/24 à partir du RT2600, où tu connecteras tous tes autres périphériques. Ton routeur faisant offiche de passerelle entre ton réseau local en 192.168.2.0/24 et la LB en 192.168.1.0/24, tes prériphériques pourront alors atteindre ceux directement placés derrière la LB. OUI tout à fait, sachant que pour la sauvegarde croisées (avec HyperBackup par ex) le lien sera direct entre les deux NAS au travers du VPN. Cordialement oracle7
  13. @Guytoon48 Bonjour, Oui c'est le plus simple à faire ... Cordialement oracle7
  14. @Maximes Bonjour, Même si elles se resemblent, c'est pour moi deux choses différentes. La zone DNS définie sur ton routeur sera purement locale afin de pouvoir utiliser des noms de domaine sur ton réseau local au lieu d'@IP locales pour atteindre les services/équipements. Il suffit d'avoir un simple enregistrement de type CNAME dans ta zone DNS OVH qui fait pointer ton www.domaine.fr vers domaine.fr. Astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait). Cordialement oracle7
  15. @Dr.Genova Bonjour, Justement c'est pour palier cela que je t'ai indiqué le lien sur le post qui résoud cela. Cordialement oracle7
  16. @Guytoon48 Bonjour, Quel est ton besoin réel : Accéder à ton réseau local depuis internet à partir de périphériques externes au réseau ? Naviguer sur internet de façon "anonyme" ? Dans le premier cas VPN serveur de Synology est la solution. Il te permet de connecter un périphérique à ton réseau local de façon sécurisé comme s'il était physiquement branché sur le réseau. Dans le second cas tu passes par un fournisseur externe (NordVPN, CyberGhost, etc ...) qui te fournit un accès sécurisé (ou presque) à SON réseau et à une porte "anonyme" vers internet. Ton @IP réelle est alors en quelque sorte "masquée" par une autre qui t'es fournie. Selon tes besoins, tu installes alors le client VPN de ton fournisseur externe sur le NAS ou sur un PC/Mac de ton réseau local. Perso je préfère la dernière solution car sur mon PC/Mac je filtre ce que je DL avant de le transférer seulement si c'est "propre" sur le NAS. Le NAS est un serveur de données et pas un second ordinateur ! mais ce n'est que mon avis... Cordialement oracle7
  17. @Maximes Bonjour, NON, il n'y a rien à changer dans la zone DNS chez OVH, tu laisses les serveurs OVH donnés par défaut (qq choses comme dns112.ovh.net et ns112.ovh.net pour les deux enregistrements NS). J'utilise mondomaine.fr et à titre d'exemple ma zone ressources dans DNS Serveur sur mon routeur : J'ai comme toi FND en redirecteur 1 et mon dynDNS chez OVH sur mondomaine.fr pointant sur mon @IP externe (box). Cordialement oracle7
  18. @Dr.Genova Bonjour, @Jeff777 pourra certainement t'en dire plus à propos de la box Free mais il me semble que ce serait mieux de placer celle-ci en mode bridge. De mémoire c'est son cas sauf erreur de ma part. Sinon peut-être que tu pourrais t'inspirer de ce TUTO en transposant ce qui est valable pour une LiveBox à ta box Free. Après, seulement si tu ne disposes pas d'une seconde liaison filaire pour relier directement ton décodeur TV à ta box, alors si tu as des switchs manageables qui te permettent de jouer avec les VLAN (), je t'invite à regarder ce post et là aussi de transposer ce qui va bien. Cordialement oracle7
  19. @Jeff777 Bonjour, Regardes le tableau d'adressage IPv6 du lien wiki sur les adresses fourni précédemment par @PiwiLAbruti Cordialement oracle7
  20. @dadoupipo Bonjour, Sauf erreur de ma part ( @PiwiLAbruti me corrigera au besoin), quand on utilise un reverse proxy on accède normalement à celui-ci depuis l'extérieur via une URL de la forme https://service.ndd.tld (sous entendu en standard via le port 443 mais cela peut-être un autre port !) sachant que ndd.tl pointe sur @IPexterne du NAS RP. Donc il faut déjà connaitre l'existance de ce domaine pour atteindre le NAS RP (c'est ce domaine que tu communiques normalement à tes amis, non ?), et une URL du type https://@IPexterne:443 ne rentrera pas dans le reverse proxy et ne sera pas traitée par le frontend de celui-ci. Justement c'est le frontend du RP qui en fonction du service indiqué dans l'URL de connexion externe, va solliciter le backend du RP qui lui va aiguiller le flux entrant vers le bon service indiqué dans la règle de RP : Si le service est local au NAS qui supporte le RP alors l'@IP de destination (dans la règle du RP) est du type http://localhost:portduService ou http://@IPNASsupportRP:portduService. Si le service est sur une autre machine du réseau local ou une machine distante alors l'@IP de destination (dans la règle du RP) est du type http://@IPmachineLocale:portduService ou http://@IPmachineDistante:portduService. Au final, si tu as correctement configuré le pare-feu de ton NAS applicatif pour accepter l'@IP du NAS RP et/ou mis en liste blanche l'@IP du NAS RP, il n'y a pas de raisons que ton NAS applicatif bloque l'@IP du NAS RP. Cordialement oracle7
  21. @dadoupipo Bonjour, D'une part et tout bêtement, as-tu au moins vérifié que cette @IP n'est pas dans la liste des @IP bloquées (Sécurité / Protection / Autoriser/bloquer la liste / Liste des blocages) ? Si oui, supprimes la tout simplement de la dite liste. D'autre part, ensuite je t'invite à suivre le conseil avisé de @PiwiLAbruti : pour l'usage de "localhost" dans l'@ de destination de ta règle de revers proxy, et pour mettre l'@IP de ton NAS qui supporte le reverse proxy dans la liste des @IP autorisées (Sécuurité / Protection / Autoriser/bloquer la liste / Liste des permissions). C'est pas plus compliqué et on ne peut plus clair, non ? Saches aussi que mettre "localhost" c'est exactement la même chose que de mettre l'@IP du NAS reverse proxy ou que de mettre 127.0.0.1. "localhost" n'est qu'un alias de ces @IP repectives et ce quelque soit le fait que tu fasses appel à d'autres Synology "physiques" dans tes règles de reverse proxy. Sinon tu peux STP préciser ton assertion plus que confuse : ??? Accessoirement : Astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait). Cordialement oracle7
  22. oracle7

    [Tuto] Reverse Proxy

    @aurelp Bonjour, "Quelles sueurs froides" ??? J'ai une configuration similaire à la tienne avec DNS Serveur installé sur le routeur RT2600 et aucuns problèmes. Je ping bien en local mon domaine ndd.tld qui répond avec l'@IP local de mon NAS principal. Alors pourquoi chercher une alternative à quelque chose de simple à mettre en place (cf TUTO) et qui fonctionne parfaitement ? Cordialement oracle7
  23. @dadoupipo Bonjour, Tu peux préciser ce que tu as fait exactement. Action dans le pare-feu ou définition d'un profil de contrôle d'accès dans le reverse proxy ou autre chose encore ? Possible que tu ais un blocage trop large sur une plage d'@IP qui contient en fait ton @IP externe sur la quelle pointe ton domaine, d'où tes déboires ... Cordialement oracle7
  24. oracle7

    Dhcp et décodeur Orange

    @PiwiLAbruti Bonjour, Pour info (si besoin en est) il faut aussi que l'uPnP soit activé sur la Livebox pour que le Décodeur TV fonctionne sans quoi les ports nécessaires à établir la connexion vidéo avec les seveurs d'Orange ne seront pas ouverts. De plus ces ports sont différents d'une connexion à l'autre. Cordialement oracle7
  25. oracle7

    Dhcp et décodeur Orange

    @KROliv Bonjour, Tout à fait normal !!! Avec une Livebox, son DHCP est obligatoire sinon pas de Décodeur TV. Regardes la réponse de @maxou56 tout en haut de cette présente page. Il n'y a pas de raisons que ce soit différent avec la LB6 ! Cordialement oracle7
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.