Problème de SSL avec Ndd et Freebox Pro

[ploufplouf]

Bonjour à tous,

Après avoir lu et tester plein de tuto, je n'arrive pas à finaliser ce que je souhaite. J’espère trouver de l'aide avec vous ^^

Voici mon problème :
Je souhaite à partir d'un nom de domaine perso faire pointer sur mon nas synology ds718+ à travers une freebox pro.
Rien de bien compliqué à la base.

 

Ce que j'ai fait (les données sont anonymisées):

1- NDD : Chez O2switch dans le zone editor je fais pointer mon sous domaine sur une IP fixe
Nom : sd.domaine
TTL : 14400
Type : A
Enregistrement : 11.11.11.11

2- Freebox Pro : Je crée une règle dans la partie WAN > LAN
Action : Autoriser
Protocole : TCP
Port de destination sur la freebox : 61718 - 61718
Activer la redirection de port : Oui
IP de redirection : 192.168.10.100
Port de la redirection : 65001
Resultat : https://sd.domaine:61718 renvoi vers le réseau local https://192.168.10.100:65001

3- Synology : J'ai créé un compte synology pour avoir un certificat DDNS du type nom.synology.me. Le certificat est bien appliqué à tous les services disponible (FTPS, KMIP, Parametre systeme par défaut et storage consol server).
Resultat en local : https://nom.synology.me:65001/#/signin > OK le certificat est bon et fonctionnel.
Resultat depuis le web : https://sd.domaine:61718/#/signin > KO, le navigateur me répond que la page n'est pas sécurisé.

Vu que le monde du réseau es un peu nébuleux pour moi...

je voudrais savoir si quelqu'un pourrais m'aider à trouver une solution
Merci d'avance !

[Mic13710]

J'avoue ne pas bien comprendre l'utilisation d'un port exotique 61718. Pour quoi ne pas avoir dirigé directement le 65001 vers le NAS ?

Il y a 3 heures, ploufplouf a dit :

J'ai créé un compte synology pour avoir un certificat DDNS du type nom.synology.me.

Le certificat concerne donc nom.synology.me. Il ne s'applique qu'à ce ndd, pas à un autre. Il est normal que toute requête faite sur votre sd.domaine vous donne la réponse que vous avez puisqu'il n'y a pas de certificat qui le couvre.

[ploufplouf]

@Mic13710
Merci de ton retour.

> Pour ce qui est du port, c'est juste un port libre au hasard pour l'exemple.

> Et pour ta remarque concernant le certificat, dit comme ça c'est parfaitement logique...
Du coup je m’emmêle les pinceaux... l'idée final c'est d'avoir un sous domaine qui pointe vers un container du syno, le tout sous ssl.
Donc si je comprend bien :
- le ndd et le ssl sont chez le registra
- le sous domaine renvoi vers l'ip fixe de la box
- la box fait une redirection de port vers l'ip du syno et de son port
mais quand je fais ça, j'ai un probleme de sécurité.
Peut etre qu'il y a des solutions avec des proxy ou autre, mais je ne maitrise pas du tout ce sujet ...

Des idées?

[Mic13710]

Ma remarque ne concernait pas le port en particulier bien qu'il y ait matière à discussion sur le choix de ports autres que ceux par défaut, mais sur le fait de na pas utiliser le même port sur le routeur et sur le NAS ce qui conduit à des URL avec des ports différents selon qu'on se trouve côté WAN ou côté LAN.

Pour commencer, un sous domaine c'est un abus de langage car ça n'existe pas. ndd.fr est un nom de domaine, toto.ndd.fr est un autre nom de domaine à part entière, de deuxième niveau et rattaché à ndd.fr.

Le ndd est effectivement hébergé chez le registrar, pas le certificat. Les certificats proposés par les registrar ne couvrent que les applications hébergées chez eux, essentiellement les sites web et les messageries.

Le registrar diffuse la zone DNS de votre ndd vers les différents serveurs DNS du monde. Ces serveurs DNS se contentent de résoudre un ndd pour orienter une requête vers l'IP correspondante. Donc oui, toute requête sur votre ndd sera dirigée vers votre box, si l'IP est correcte bien entendu.

Pour qu'une requête en https qui arrive sur la box puisse être résolue sans alerte de sécurité, il faut que le certificat du ndd soit présent sur le point de destination, cad, le NAS en l’occurrence.

Vous avez trois possibilités pour créer votre certificat à partir du NAS :

1. par DSM. C'est le plus simple mais aussi le plus contraignant à l'usage car DSM utilise le mode HTTP-01 qui nécessite d'ouvrir les ports 80 et 443 pour renouveler le certificat tous les 2 mois.
2. via le script acme.sh en mode DNS 01. Il s'installe en SSH à partir d'un terminal. Sa mise en oeuvre est beaucoup plus complexe mais le renouvellement et le déploiement se font ensuite automatiquement. Il n'y a pas besoin d'ouvrir de port particulier. https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide
3. en docker si votre NAS est compatible, qui utilise le même script acme.sh. Il y a un tuto dans la section des tutoriels.

[CoolRaoul]

De mon côté, depuis que j'ai compris qu'ayant déclaré un nom en "synology.me" via DDNS on disposait d'un certificat SSL wildcard et automatiquement renouvelé je ne m'emmerde plus.
Je réserve mon nom domaine aux usages "pro" et les quelques services hébergés par le NAS auxquels j'ai besoin d'avoir accès externe j'y accede en <nom>.synology.me via le reverse proxy (pas de port ouvert sur l'extérieur autre que le 443 et le 80). Et la conf firewall permet d'affiner les réglages.

[Mic13710]

@CoolRaoulJ'ai 2 ndd que j'ai acquis avant l'arrivée des synology.me. Ceci explique cela. Je n'ai donc pas de ndd synology.me, ni d'ailleurs de compte quickconnect.

Je fais les renouvellements et déploiements des certificats avec acme.sh et le deploy-hook associé depuis pratiquement ses débuts et exception faite de déploiement parfois capricieux, ça fonctionne au poil. C'est bien plus souple que par DSM où il faut lister tous les ndd (pas de wildcard) pour les domaines autres que synology.me ce qui complique la mise en oeuvre.

Pas de port 80 ouvert. Seulement le 443 plus les ports propriétaires des applications (6690 pour Synology Drive, 500 et 4500 pour L2TP/IPSec...): et bien entendu le reverse proxy pour diriger les ndd vers leurs applications ou autres équipements (Domoticz, Unifi Controler, Rasberries, etc...) et bien entendu, le parefeu du NAS qui sécurise les accès.

Je reconnais volontiers que le ndd de synology facilite grandement la mise en place d'un ndd perso. Je l'ai d'ailleurs utilisé sur 2 NAS que j'ai mis en service la semaine dernière et c'est très facile à mettre en place, d'autant plus facile que DSM propose de créer un certificat LE dès que le ndd a été créé.

[CoolRaoul]

Il y a 2 heures, Mic13710 a dit :

C'est bien plus souple que par DSM où il faut lister tous les ndd (pas de wildcard)

Ca fait partie des choses qui m'ont bien gavé ça !

Il y a 2 heures, Mic13710 a dit :

Je fais les renouvellements et déploiements des certificats avec acme.sh et le deploy-hook associé depuis pratiquement ses débuts et exception faite de déploiement parfois capricieux, ça fonctionne au poil

J'avais jeté un oeuil sur le tuto mais j'ai trouvé ça un peut trop touffu pour mon besoin, j'ai eu la flemme d'aller plus avant.

Il y a 2 heures, Mic13710 a dit :

Je reconnais volontiers que le ndd de synology facilite grandement la mise en place d'un ndd perso

C'est ce que j'ai conseillé récemment à un pote que j'ai aidé à reconfigurer son NAS. On ne peut pas trouver plus simple en effet.

 

Il y a 2 heures, Mic13710 a dit :

Pas de port 80 ouvert. Seulement le 443 plus les ports propriétaires des applications

Forcément ouvert chez moi, mais j'ai détaillé ailleurs mon avis sur le fait que ça ne change pas grand-chose au niveau sécurité à partir du moment où le 443 est ouvert aussi.
Sinon pour les applis DSM en http j'utilise les alias ce qui m'évite d'avoir à ouvrir leur port. Et quant aux autres, elles écoutent uniquement en interne (sur localhost) et le reverse proxy se charge de donner accès depusi extérieur. Juste besoin des ports du VPN à ouvrir.

Modifié le 31 mai par CoolRaoul

[ploufplouf]

Bonjour,

d'abord merci à @Mic13710 pour ta réponse complète, ça bien éclairci sur qui fait quoi.

En ce qui concerne mes services syno, la plupart ne sont même pas installer (photos, drive...). Ce syno la sert principalement à faire discuter serveur à serveur pour de l'API via docker.
Entre temps (et provisoirement) j'ai mis en place <nom>.synology.me, meme si celui-ci semble avoir d'autres contraintes pour faire discuter serveur à serveur... mais c'est pas grave pour le moment car les api ont des origins cors qui limitent les choses.

Je vais me pencher sur le tuto acmesh que tu as partagé, ça me semble être une bonne piste, quitte à adapter.

Merci

Modifié le 4 juin par ploufplouf