Classement

Bonjour à tous, Nous allons voir dans ce tutoriel comment mettre en place rapidement un certificat Let's Encrypt avec la méthode acme.sh en utilisant l'api Ovh en Docker, si vous êtes rapide, en 10 minutes c'est en place. Pourquoi en docker ? Car je suis contre la pollution du DSM, des corruptions par update, mais aussi par simplicité et rapidité. 1) On commence par la création de clé d'api chez ovh : https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/* On remplit donc le formulaire, pour "Validity" (1) on choisit "Unlimited", pour "Rights" (2) on remplace dans les champs "mydomain.com" par le vôtre et dans "Restricted IPs" (3), on rajoute son IP afin qu'en cas de vol des clés, elles ne puissent être exploitées et votre domaine détourné. (NB : Si vous n'avez pas une IP fixe, on passe ce dernier point) On garde les clés retournées en résultat sous la main pour la suite. 2) Passons maintenant au docker : A) On commence par la création d'un dossier "Acme" dans le dossier docker. B) La création du fichier de config : On crée avec l'éditeur de texte du DSM (Codage UTF-8) le fichier "account.conf" à la racine de notre dossier "Acme" contenant : LOG_FILE="/acme.sh/acme.sh.log" LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SAVED_OVH_AK='XXXXXXX' SAVED_OVH_AS='XXXXXXX' SAVED_OVH_CK='XXXXXXX' DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' On remplace dedans le contenu des 3 variables "SAVED_OVH_**" par nos clés obtenues précédemment par OVH. C) La création du docker : On va mettre un petit peu de code pour la création du docker et son actualisation journalière via le gestionnaire de tâche... Panneau de configuration / Planificateur de tâches / Créer / Tâche planifiée / Script défini par l'utilisateur Utilisateur : Root On programme pour une exécution par jour la nuit (5h c'est bien) Exécuter la commande : docker pull neilpang/acme.sh:latest docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart unless-stopped neilpang/acme.sh:latest daemon On exécute manuellement la tâche une première fois pour la création du docker. C Bis) Le docker-compose.yml : version: "2.1" services: acme: cpu_shares: 10 mem_limit: 128M container_name: Acme network_mode: bridge labels: - com.centurylinklabs.watchtower.enable=true volumes: - /volume1/docker/Acme:/acme.sh:rw restart: unless-stopped image: neilpang/acme.sh:latest command: daemon D) Création du certificat : Avec le planificateur de tâche en exécution unique (cf point 2C) ou en ssh (root) en remplaçant "mydomain.com" : docker exec Acme sh -c "acme.sh --issue --keylength 4096 -d 'mydomain.com' -d '*.mydomain.com' --dns dns_ovh" Il n'y a rien à détailler pour expliquer cette commande, le keylenght peut être, on double la valeur par défaut qui est aujourd'hui considérée comme faible à 2048. /!\ Renouvellement automatique du certificat sans action de votre part 3) Installation des certificats : A) Importation manuel : Vos certificats seront disponibles directement dans filestation "docker/Acme/votredomaine" et ce qui nous intéresse dedans : Certificat : mydomain.com.cer Clé privée : mydomain.com.key Certificat intermédiaire : ca.cer On va maintenant faire leur import manuellement, dans "Panneau de configuration/Sécurité/Certificat". En cas d'import manuel, vous pouvez activer la notification mail, mais cette action se réalise toujours 1 mois avant expiration : https://github.com/acmesh-official/acme.sh/wiki/notify B) Déploiement automatique : NB : Faire un premier déploiement manuel avant le déploiement automatique, afin de bien le mettre par défaut et supprimer celui de synology par défaut. 1) Création d'un compte que l'on rajoutera dans le groupe admin, on lui mettra aucun acces à tous les dossiers et refuser à toutes les applications, on active pas la double authentification qui sera inutile. 2) On ré édite notre fichier "account.conf" créé au point 2B, on y rajoute : SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='nom utilisateur' SAVED_SYNO_Password='le password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='description du certificat mise dans le DSM' 3) Ensuite une fois les modifications faites, avec le planificateur de tâche en exécution unique (Cf point 2C) ou en ssh (root) : docker exec Acme sh -c "acme.sh --deploy -d 'mydomain.com' --deploy-hook synology_dsm" Guide officiel : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide Pour d'autres API que ovh : https://github.com/acmesh-official/acme.sh/wiki/dnsapi 😉

Non, ça n'a aucun rapport avec le port. C'est le NAS qui ajoute cette en-tête HTTP avant d'envoyer une requête à la Freebox. Il n'y a aucun intérêt à chiffrer les échanges entre le NAS et la Freebox, mais les deux fonctionnent (tcp/80 ou tcp/443). Je n'ai pas cherché à comprendre pourquoi la Freebox a un comportement différent en HTTP et en HTTPS, et ça ne m'intéresse pas. Orange faisait la même chose avec les Livebox v4 où il fallait l'en-tête Host: 192.168.1.1 pour y accéder, je ne sais pas si c'est le cas sur les modèles plus récents.

L'en-tête personnalisé sert uniquement à tromper la Freebox en lui faisant croire que le nom d'hôte mafreebox.freebox.fr a été utilisé pour l'atteindre. C'est pour contourner l'erreur que tu avais indiquée : Ça n'a rien à voir avec le port 80. Si le NAS n'est pas accessible en IPv6, ça ne peut pas fonctionner. Le pare-feu IPv6 des Freebox (hors Freebox Pro) est un honte : c'est un gros interrupteur qui bloque ou autorise tout le trafic IPv6. Il n'y aucun moyen de filtrer le trafic sans rajouter un pare-feu digne de ce nom derrière la Freebox.

Tu n'as que le port tcp/443 à ouvrir à destination du NAS sur la Freebox. Ensuite, tout se fait dans le proxy inversé. Par exemple : dsm.domain.synology.me > localhost:5000 freebox.domain.synology.me > 192.168.1.254:80 Si les restrictions d'accès du pare-feu ne sont pas suffisantes, je te conseille vivement de configurer des profils de contrôle d'accès dans le proxy inversé.

Si le port est bien ouvert sur la Freebox, ça ne vient pas de la Freebox. Je pencherais plutôt pour un blocage du port sortant depuis la connexion en Allemagne. Je ne connais aucune entreprise sérieuse qui laisse du trafic utilisateur sortir sur d'autres ports que les suivants (hors besoins exotiques) : HTTP (tcp/80) HTTPS/DoH (tcp/443) QUIC/DoQ (udp/443) D'où l'intérêt d'utiliser systématiquement le proxy inversé pour toutes les interfaces web (DSM inclus).

Le mieux est d'utiliser tcpdump : tcpdump -nq 'port (443 or 1234 or 5001)'Ça affiche le trafic en amont du pare-feu du NAS. Donc ça permet de savoir si le trafic parvient bien jusqu'au NAS, peu importe qu'il soit bloqué ou non par le pare-feu.

Les domaines ayant pour TLD .me sont souvent bloqués, il s'agit peut-être d'un blocage DNS de ton entreprise. Vérifie que la résolution de domaine.synology.me retourne bien ton adresse IP : > nslookup domaine.synology.meou > Resolve-DnsName domaine.synology.me Et aussi celui sur la sécurité : https://www.nas-forum.com/forum/topic/77493-tuto-pas-%C3%A0-pas-s%C3%A9curisation-du-nas-pour-dsm-7/

Bonjour Il faudrait revoir le tuto sur le reverse proxy. L'intérêt du reverse proxy est de limiter l'ouverture des ports. Seuls 443 doit être ouvert éventuellement 80 si tu n'as pas de redirection http vers https et quelques autres exceptions.

Mystérieusement cela a repris vers 4h ce matin. Je me demande si l'ip du vpn n'a pas été Blacklist chez eux. Tout est rentré dans l'ordre pour moi et Milles Merci d'avoir pris le temps de répondre

Bon bah, l'intuition était la bonne, j'ai désactivé le Wake on Lane, plus de problème de latence sur la télé.