« sinon » : ‹ oui ›
« en meme temps » : non ! inutile de surcharger ton réseau en ajoutant un pi au cul de ton nas qui ne servira que de reverse proxy !
préférable : pas certain puisque tu as déjà le matériel qu’il te faut et qu’il sera allumé H24 !
équivalent : sur le principe oui, un reverse-proxy est un reverse-proxy qu’il soit sur Pi ou Nas !
~ si tu es à l’aise avec les lignes de commandes et les structures vhost d’Apache ou Nginx => alors pourquoi pas, amuse toi
~ si ça n’est pas le cas, alors synology te propose une belle IHM toute simple qui te guide et fait tout pour toi
et pour moi dans le cas où tu souhaites quand même ajouter un Pi supplémentaire (ou une 3e boite) pour faire uniquement du reverse proxy, il faut le mettre derrière ton routeur
c’est toujours le même principe : c’est à ce reverse proxy de recevoir les requetes 80/443 puis de les dispatcher au bon équipement sur ton réseau.
Si tu le mets au meme niveau que ton NAS alors tu auras toujours la problématique de devoir gérer des ports différents !
J’ai un certificat sur mon jeedom, sur le port 8443 (il n’est pas impossible que j’ai ouvert le 443 et le 80 sur le jeedom pour le 1er challenge)
J’ai un autre certificat sur mon syno, avec tout un tas de sous domaines pour le reste de mon reseau, et qui me sert de reverse proxy
le tout sur le même nom de domaine.
J’ai fait ça pour 2 raisons :
1/ il arrive que mon syno quitte le réseau (ou se fait éjecter, j’arrive pas à débugger…)
2/ quand coupure de courant, jeedom éteint le syno, et j’aimerai conserver l’accès à ma box
La fibre arrive sur la Freebox
Freebox envoie son 192.168.0.xxx sur le routeur.
Le routeur redistribue des IP fixes 192.168.1.xxx aux ordis et au NAS, sur tous les ports.
Mais pas au PI qui, lui, sera branché sur la 2ème prise RJ45 du NAS.
Je crée un nouveau certificat sur le NAS qui « protègera » le PI.
Le PI reçoit ses données du NAS, uniquement sur le port 80.
J’ai bon jusque là ?
Ensuite, sur le PI, dois-je supprimer le certificat existant ou on s’en fout ?
Quelque chose d’autre à faire avant de me lancer ?
Un grand merci à vous et j’espère que je vais progresser pour, un jour peut-être, moi aussi apporter mon aide aux autres !
Le pi est branché sur ton routeur pas sur le nas ! C est un appareil comme un autre.
C’est le routeur qui sert de DHCP et qui va fournir une adresse IP à ton raspberry pas le NAS
Pas que pour le pi ! Pour tout ce qui pourrait être derriere ton nas
Pour que ça soit propre je te dirais bien oui on supprime.
Mais dans un premier temps fait déjà une install propre avec le NAS et compagnie vérifie que tu fonctionnes et seulement après tu feras ta suppression
mais il ne représente que le flux d’une requête http, il ne représente pas comment les appareils sont connectés, et ils le sont tous « en étoile » sur le router.
Effectivement, tu mentionnes Plex, j’ai une MiBox sur une télé, avec Plex…
Et la différence avec ton dessin, comme j’ai dit, je n’ai pas mis de sous-domaines, mais la différence d’aiguillage se fait sur les ports. (je dois changer ça ?)
Bon…
Si je comprends bien, je ne change rien, physiquement, à mes branchements ???
Ce que je ne comprends pas (désolé, c’est peut-être à cause de l’âge ! ), c’est comment mon Pi, branché direct au routeur, sait que le Syno assure sa sécurité !
Je sais… je suis ch.ant, mais appliquer sans comprendre, c’est pas mon truc !
si c’est comme sur ton dessin, alors tu es bon oui !
le Pi ne le sait, et en soit il s’en fou puisqu’il recoit des requetes sur le port 80, donc non sécurisées
si tu veux que les échanges entre ton NAS et Pi soient en 443, alors il faudra aussi gérer un certificat supplémentaire sur le PI (quid de l’utilité ?! cf précédents échanges)
Je DOIS donc utiliser (ou plutôt, tu me recommandes) des sous-domaines à la place de mes ports « exotiques » ?
Par exemple, pour Syno, j’avais vu qu’il était recommandé de changer les ports 5000/5001 qui sont plus fréquemment attaqués, parce qu’ils sont « connus ».
De même, pour le Pi, je n’utilise directement ni le 80 ni le 443, mais des ports choisis personnellement qui redirigent vers eux.
Tort ou raison ?
OK
Chui content d’avoir quand même fait un truc bien !
Alors, c’est là que je ne comprends pas ! (courage, je vais y arriver !)
D’après ce que je vois sur mes branchements, le Pi est relié au routeur, sans passer par le NAS.
Où est sa protection, s’il est directement sur le :80 ?
Chez OVH avec le certificat créé sur le NAS ? (encore une fois, je suis désolé des questions d’un vieux cerveau dont les neurones commencent visiblement à décliner !)
encore une fois : c’est tout l’interet du reverse proxy !!!
si tu veux utiliser des ports exotiques, alors pas besoin de faire du reverse proxy !
une fois de plus : si tu passes par un sous domaine tu n’exposes pas directement ton port 5000/5001 !
donc si t’appelles http(s)://monNas.domain.ovh (donc en 80 ou 443) => sur ton nas il redirigera en local:5000 ou 5001 !
et donc les attaques sur tes ports 5000 & 5001 n’auront aucun effet puisqu’ils ne sont pas ouvert sur ta box (donc ouvert à l’extérieur!)
bon … visiblement mon schéma n’était pas assez clair !
il y a pourtant les ports et des exemples !
je ne vais pas savoir faire plus
faut peut etre commencer par le début … a quoi tu t’attends quand tu parles de « protection » …???
Ca y est !
Je crois que ma confusion est là…
Le certificat ne « protège » pas.
Il est juste là pour dire « la page que tu essaies d’atteindre est bien celle que je reconnais »
D’où le fait que l’accès au Pi (ou autre) n’est pas « filtré », mais juste (comme son nom l’indique !) que son adresse est « certifiée valide » par letsencrypt.
Donc je lance la certification sur mon Syno pour « mondomaine.ovh » …
2 ou 3 adaptations à faire chez OVH…
Mise en place du reverse proxy…
Et là, « nas.mondomaine.ovh » et « jeedom.mondomaine.ovh » seront reconnus… et conduiront où je veux que ça conduise.
C’est ça ?
Je crois que j’étais parti sur une mauvaise route et que je la suivais sans réfléchir !
Je l’ai dit… c’est l’âge !
(j’admire ta patience ! … et je t’en remercie encore !)
Perso, les certificats * ça apporte plus d’ennuis que d’avantages, s’il est compromis, faut tout changer partout en urgence… Et ça péte en même temps
Puis ça fonctionne avec un seul sous niveau
Bon, maintenant, j’ai de quoi me mettre le feu aux neurones !
Allez… je pense que je vais prendre mon déambulateur et y aller doucement…
En cas de gros (faut quand même que je me démerde un peu par moi-même pour régler les petits ! ) soucis, je reviendrai faire un tour sur ce fil.
C’est pour ça que je disais que perso, j’aimais pas les *…
Quitte à automatiser (en partie du moins) la propagation d’un certif, j’en profite pour carrement avoir une génération et renouvellement auto, mais chacun le sien
Le problème du wildcard certif c’est que ça ratisse large et que je ne sais pas si Let’s Encrypt les gère proprement pas tester.
La solution HA Proxy est aussi très bonne mais pour les néophytes c’est pas simple de gérer les configs entre les listen les backend les frontend de HA proxy ça devient vite l’angoisse du débutant
Après tu peux aussi faire une simple redirection de ports en disant sur ta box :
le 1443 redirige en https sur ip_jeedom:443
le 2443 redirige en https sur ip_nas:443
et ainsi de suite faut juste bien penser à bookmark les bons ports dans ton browser
Faut simplement rediriger le port 443 ET 80 sur le serveur qui gérera le certificat let’s encrypt en effet certbot en tout cas utilise le 80 comme test pour joindre ton serveur enfin moi c’est ce qu’il m’a fait avec mon nom de domaine NO-IP
)
… et je t’en remercie encore !)
