Aller au contenu

Messages recommandés

Posté(e)
il y a une heure, GrOoT64 a dit :

Attention, dans ton serveur DNS, l'adresse au dessus est un CNAME de nnd.tld
le A doit etre sur une autre adresse genre : RPI-HOM.ndd.tld

Sinon en LAN, si tu ping ton adresse home.ndd.tld tu tombe sur ton RPI et non sur ton NAS (reverse proxy)

Dans mon cas par exemple, le seul CNAME que j'ai c'est *.ndd.tld vers ndd.tld

Mais on peut décomposer ça en plusieurs cname comme video.ndd.tld, fichiers.ndd.tld, download.ndd.tld, photos.ndd.tld, rpi.ndd.tld etc... mais chacuns pointent sur ndd.tld

Pas certain de comprendre.

A date mon entrée du DNS local est : home.ndd.tld A 86400 192.168.X.X

J'ai essayé d'utiliser : home.ndd.tld CNAME 86400 ns.ndd.tld et home.ndd.tld A 86400 IP Routeur mais ça n'aide pas et ça casse même l'accès local en http.

il y a 34 minutes, oracle7 a dit :

A défaut de non gestion du loopback sur la box c'est cette zone qui permet d'utiliser les sous-domaines en local. D'où là aussi l'utilisation d'un enregistrement wilcard *.ndd.tld CNAME ndd.tld y est nécessaire. Elle évite ainsi l'emploi du port. Typiquement ainsi j'atteins mon RPI4 Jeedom directement en local avec juste un jdom.ndd.tld.

Je viens de créer une entrée home.ndd.tld CNAME 86400 ndd.tld et même ainsi le port reste obligatoire ...

il y a 32 minutes, oracle7 a dit :

Cela dit comme j'ai aussi la redirection automatique du http vers https avec le fichier .htaccess, je pense que du coup je repasse systèmatiquement par le Reverse Proxy quand je me connecte en local.

Idem

Posté(e) (modifié)

@TuringFan

Bonjour,

il y a 14 minutes, TuringFan a dit :

Je viens de créer une entrée home.ndd.tld CNAME 86400 ndd.tld et même ainsi le port reste obligatoire ...

Je ne comprend pas pourquoi le port est obligatoire puisqu'on repasse par le Reverse Proxy. Il doit y avoir autre chose, mais alors là je sèche 🥴... On doit rater un truc à la c...

Cordialement

oracle7😉

Modifié par oracle7
Posté(e) (modifié)

Bonjour à toutes et à tous,

 

  merci pour ce tuto (mais aussi celui-ci), mais je rencontre des difficultés.

  Voici les étapes réalisées : 

  1/ Adresse IP publique fixe :

Etant chez Free, j'ai demandé une adresse IP fixe V4 full-stack

image.thumb.png.b0fb0711b69fcb608d94d8c931e67ec5.png

  2/ Achat d'un nom de domaine puis redirections : 

 image.thumb.png.3b3a851018ab98dc3d97c8fa3e5d6cce.png

  3/ Vérification sur https://www.whatsmydns.net/ : 

  OK pour NDD.fr et sous-domaine.NDD.fr (sauf : 

  - Diemen, Netherlands,
  - Cullinan, South Africa, 
  - Mumbai, India,
  - Tokyo, Japan, 
  - Melbourne VIC, Australia

  4/ Ouverture et redirection des ports 80 et 443 sur le Freebox Serveur à destination du Synology 

 

image.thumb.png.277b3cbbb2e55dc3a1c33219a4d5d2d6.png

  Au passage, aucune autre redirection
  Redémarrage effectué pour prise en compte

5/ Pare-feu Synology :

image.thumb.png.4f4646c76a631f35c692498b109fd330.png

6/ Configuration du portail des applications de DSM

image.thumb.png.fb16e1518177b4b4170c30b44cbcbdcb.png

  Vérification : si je tape : IP_locale/35975 (ex. http://192.168.1.32:35975/ >>> j'arrive bien sur Download Station)

image.thumb.png.30f8c03d170fb07426c0ca850c05bd6e.png

  Vérification : si je tape : https://moments.ndd.fr, j'arrive sur cet écran 

image.png.6b7775a2855e60e1677d3521a8a2253f.png

puis, si j'accepte de continuer, j'arrive sur cet écran : 

image.png.146a7151b239d32b01bb40738ef104a5.png

  J'avoue avoir un doute, est-ce normal ou non de ne pas pouvoir ouvrir l'application à cette étape.

7/ Obtention SSL

  OK, mais sans le www.ndd.fr.

  Mais, lorsque je tape : moments.ndd.fr, il ne me renvoie pas vers ndd.fr:port_DSM_non_sécurisé (ndd.fr:35978).

  Egalement, si je tape : ndd.fr:35978, je n'ai rien.

  

  Je n'ai donc pas suivi le tuto jusqu'au bout, car j'imagine qu'il faut régler cette étape avant de passer à la suite, pourriez-vous svp m'aider ?

 

  Merci à vous

 

 

image.png

Modifié par Shadow59
Posté(e)

Bonjour @Shadow59

Tu n'as pas souvent fréquenté ce forum 😉,

sinon tu saurais que la coutume est de commencer par se présenter ici.

Sinon pour ton problème il te manque un certificat valide sur les applications pour pouvoir te connecter en https.

Posté(e) (modifié)
il y a 58 minutes, Shadow59 a dit :

Vérification : si je tape : https://moments.ndd.fr, j'arrive sur cet écran 

C'est normal que tu ais une alerte de sécurité si tu n'as pas encore demandé le certificat de Let's Encrypt.

il y a 58 minutes, Shadow59 a dit :

7/ Obtention SSL

  OK, mais sans le www.ndd.fr.

Je ne comprend pas ce que tu veux dire.. C'est la demande du certificat ? Pour quels sous domaines as-tu demandé ce certificat ? (Autres noms de l'objet dans le dialogue de génération du certificat)

il y a 58 minutes, Shadow59 a dit :

Egalement, si je tape : ndd.fr:35978, je n'ai rien.

Ca, c'est normal, le port 35978 n'est pas redirigé vers ton NAS au niveau de la box ...

Et petit détail qui a son importance, si tu veux utiliser Synology Drive pour synchroniser des fichiers depuis ton ordinateur, il faut que tu rediriges le port 6690 vers ton NAS (port utilisé par le client pour faire la synchro, non modifiable, et qui ne peut pas passer par le Reverse Proxy).

Grilled par @Jeff777

Modifié par Kramlech
Posté(e)

Bonjour @Jeff777 et @Kramlech,

  merci pour vos retours.

  @Jeff777 : oui, j'avais renseigné mon profil depuis mon espace mais pas depuis la page "Présentation".

  @Kramlech :

  Lorsque j'indique "OK, mais sans www.ndd.fr", cela signifie que j'ai réussi, il y a déjà quelques semaines, à avoir un certificat Let's Encrypt mais n'ayant pas dans "autre nom de l'objet" le "www.ndd.fr" (en revanche, il y a bien : moments.ndd.fr;video-station.ndd.fr;download-station.ndd.fr;file-station.ndd.fr;synology-drive.ndd.fr

  J'ai ajouté toutes les redirections sur la Freebox Server, dont le port 6690 (et l'ai redémarrée)

image.thumb.png.78768d10855c2d91a40f690b35b425b9.png

  Désormais,

  - lorsque je tape http://moments.ndd.fr (sans le "s") > j'arrive sur cette page depuis un smartphone non connecté au wifi : 

image.png.d7a5a64aa6281c5651a420dda94ea6a1.png

  - lorsque je tape : https://moments.ndd.fr (avec le "s") > j'arrive sur cette page également depuis un smartphone non connecté au wifi, le certificat n'est pas appliqué car j'ai le message d'erreur : 

image.png.3dd5dab2868ef2d6c0e43420582cca4d.png

 

 

  Je viens à l'instant d'essayer de refaire une demande de certificat Let's Encrypt, en ajoutant cette fois le "www.ndd.fr" dans "autre nom de l'objet", j'ai toujours le message d'erreur.

 

image.thumb.png.e4f6e50bf1a1f9917c6cad4d5ee372f3.png

 

  J'avoue sécher, d'autant plus que je suis carrément newbie sur ces sujets.

 

  Bien à vous

 

 

Posté(e) (modifié)

@Shadow59

Bonjour,

A mon humble avis, il est inutile de transférer ta ribambelle de ports 35xxx de ta box vers ton NAS. Vu que tu veux passer par le Reverse Proxy SEUL le port 443 HTTPS est utilisé pour entrer sur ton NAS ensuite c'est ce même Reverse Proxy qui redirige les flux selon le sous-domaine de l'URL vers l'application correspondante via le port HTTP 35xxx que tu as défini pour elle. Mais il faut alors que ce port 35xxx soit ouvert/autorisé dans le pare-feu du NAS.

As-tu aussi conformément au TUTO Reverse Proxy, créé le fichier .htaccess dans le dossier partagé www ?

Maintenant il est aussi normal que http://moments.ndd.fr ne fonctionne pas en local si ta box ne gère pas le looback. En général (mais pas que) on palie cela en définissant une zone DNS locale avec le package DNS Server installé sur le NAS, mais c'est une autre histoire.

Enfin, une fois ton certificat créé, l'as-tu bien affecté à tes services (sous-domaines et applications) concernées ? (Sécurité > Certificat > tonCertificat > Configurer).

Cordialement

oracle7😉

 

Modifié par oracle7
Posté(e)
il y a 45 minutes, Shadow59 a dit :

Je viens à l'instant d'essayer de refaire une demande de certificat Let's Encrypt, en ajoutant cette fois le "www.ndd.fr" dans "autre nom de l'objet", j'ai toujours le message d'erreur.

En plus de ce que viens de dire @oracle7, concernant l'échec de ta demande de certificat, il est possible que tes 5 essais autorisés dans une fenêtre de 5 jours consécutifs soient déjà effectués. Si c'est le cas, il ne te reste plus qu'à attendre patiemment.

Posté(e)
il y a 26 minutes, oracle7 a dit :

Mais il faut alors que ce port 35xxx soit ouvert/autorisé dans le pare-feu du NAS.

A priori, la configuration du pare-feu qu'il nous indique est correcte : pour 80 et 443 autorisées pour toutes les sources, tous les ports autorisés pour toutes les IP internes 192.168.x.x

il y a 44 minutes, Shadow59 a dit :

- lorsque je tape http://moments.ndd.fr (sans le "s") > j'arrive sur cette page depuis un smartphone non connecté au wifi :

Donc, c'est OK pour le HTTP (le Reverse proxy ne traite que les HTTPS). Donc tu accède à la page par défaut du Web Station.

il y a 31 minutes, oracle7 a dit :

Maintenant il est aussi normal que http://moments.ndd.fr ne fonctionne pas en local si ta box ne gère pas le loopback.

Il est chez Free, donc le loopback fonctionne. Voir juste avant mon explication pour le "non fonctionnement"

 

il y a 33 minutes, oracle7 a dit :

As-tu aussi conformément au TUTO Reverse Proxy, créé le fichier .htaccess dans le dossier partagé www ?

Attendons de faire fonctionner le HTTPS avec de travailler sur la redirection automatique HTTP => HTTPS !

il y a 34 minutes, oracle7 a dit :

Enfin, une fois ton certificat créé, l'as-tu bien affecté à tes services (sous-domaines et applications) concernées ? (Sécurité > Certificat > tonCertificat > Configurer).

Là, je pense que tu as effectivement mis le doigt sur le problème !! 👍

Posté(e)

@Shadow59

Bonjour,

il y a 4 minutes, Jeff777 a dit :

Si c'est le cas, il ne te reste plus qu'à attendre patiemment.

Oui, une semaine calendaire à compter de la dernière tentative infructueuse.

Cordialement

oracle7😉

Posté(e)
Le 13/03/2022 à 18:47, TuringFan a dit :

Pas certain de comprendre.

A date mon entrée du DNS local est : home.ndd.tld A 86400 192.168.X.X

J'ai essayé d'utiliser : home.ndd.tld CNAME 86400 ns.ndd.tld et home.ndd.tld A 86400 IP Routeur mais ça n'aide pas et ça casse même l'accès local en http.

Je viens de créer une entrée home.ndd.tld CNAME 86400 ndd.tld et même ainsi le port reste obligatoire ...

Idem

Bonjour @oracle7 et @GrOoT64,

Juste pour informer que c'est bon, je parviens à atteindre home.ndd.tld depuis le WAN et le LAN.

Voici ce que j'ai fait :

  • J'ai effacé les entrées créée sur le DNS local
  • J'ai effacé l'entrée sur le Reverse Proxy de mon NAS
  • Sur le DNS local (héberge sur mon routeur), j'ai crée une entrée home.ndd.tld A 86400 @IP NAS
  • Sur le Reverse Proxy (hébergé sur mon NAS), j'ai créé une entrée https://home.ndd.tld -> http://IP_Home_Assistant:8123
  • J'ai fait un ipconfig/flushdns sur l'invite de commande de mon client

Et là miracle ça marche !

J'ai une dernière question : mon certifcat wildcard joue son rôle, mon accès apparait donc comme sécurisé. je pensais justement qu'un certificat était lié à un nom de domaine et une machine et que je devrais l'installer sur mon Home Assistant (ou mon Raspberry Pi 4B) pour avoir un accès sécurisé ! Comment expliquer ce comportement ?

Posté(e) (modifié)

@TuringFan

Bonjour,

Il y a 16 heures, TuringFan a dit :

Sur le DNS local (héberge sur mon routeur), j'ai crée une entrée home.ndd.tld A 86400 @IP NAS

Je ne comprends pas, si tu as un wilcard (*.ndd.tld. CNAME 86400 ndd.tld.) de défini dans ta zone locale DNS sur le RT alors cette entrée (home.ndd.tld A 86400 @IP NAS) me paraît inutile.

C'est sûr le Ipconfig /flushdns n'était pas de trop ! On oublie trop souvent de le faire, on pense au cache Navigateur Web mais pas à lui.

Il y a 16 heures, TuringFan a dit :

je pensais justement qu'un certificat était lié à un nom de domaine et une machine et que je devrais l'installer sur mon Home Assistant (ou mon Raspberry Pi 4B) pour avoir un accès sécurisé !

Le certificat est lié uniquement à ton domaine pas du tout à ta machine, rien n'empêche de l'installer sur plusieurs machines (chez moi il est sur mes 2 NAS et mon RT).

Comme tu passes par le Reverse Proxy du NAS, tu n'as pas besoin de l'installer sur ton HomeAssistant qui n'est d'ailleurs pas exposé en direct à Internet pour le coup. Chez moi je ne l'ai pas fait sur mon RPI4 pour Jeedom et tout va bien, j'accède par ex sans problème depuis Jeedom au Market avec dans Réglages > Système > Configuration > Réseaux

JbGwa3K.png

Cordialement

oracle7😉

Modifié par oracle7
Posté(e)

De mon côté le certificat est demandé par le NAS sur l'ensemble des reverse proxy et je ne l'ai pas installé sur mon Rpi 4 avec Home Assistant car inutile

HA est accessible depuis l'extérieur via HTTPS uniquement et sur le reverse proxy, seul le port 443 est ouvert.

Je n'ai pas d'erreur de certificat

Posté(e)
Le 18/03/2022 à 12:37, oracle7 a dit :

Je ne comprends pas, si tu as un wilcard (*.ndd.tld. CNAME 86400 ndd.tld.) de défini dans ta zone locale DNS sur le RT alors cette entrée (home.ndd.tld A 86400 @IP NAS) me paraît inutile.

Non pas encore. Mais tu m'as convaincu la dernière fois.
Je vais donc le faire (i) sur le DNS de mon Registrar et (ii) sur mon DNS local.

Le 18/03/2022 à 12:37, oracle7 a dit :

qui n'est d'ailleurs pas exposé en direct à Internet pour le coup

Pas d'accès externe configuré et pas de DynDNS sur cette machine donc a priori pas joignable directement depuis l’extérieur sans passer par mon routeur puis mon Reverse Proxy ?

image.png.b2cebf1cc46c92c78622c595e62f2969.png

En revanche je ne lui ai pas encore formellement banni l'accès à internet depuis mon Routeur (ce que je vais surement faire d'ailleurs).
J'avais sur mon Routeur une règle de transfert de port que j'ai désactivé suite à l'activation de mon Reverse Proxy.

=> La non existence d'une règle d'accès sur le firewall de mon routeur + la non existence d'un paramétrage URL externe est elle suffisante pour indiquer "qu'il n'est pas exposé à internet" ou faut il aussi ajouter un bannissement depuis le routeur pour formellement pouvoir le dire ?

Juste pour ma culture, d'un point de vue technique que ce passe t il quand on configure une URL externe ? C'est une sorte de dynDNS ?

Le 18/03/2022 à 12:37, oracle7 a dit :

Comme tu passes par le Reverse Proxy du NAS, tu n'as pas besoin de l'installer sur ton HomeAssistant

Ok, dans ce cas cela pourrais-je créer une entrée dans mon Reverse Proxy pour pointer vers mon routeur qui me permettrait d'éviter de copier à la main tous les 3 mois mon certificat depuis mon NAS (cf. ton super tuto) vers mon Routeur ?

Le 18/03/2022 à 12:37, oracle7 a dit :

Chez moi je ne l'ai pas fait sur mon RPI4 pour Jeedom et tout va bien, j'accède par ex sans problème depuis Jeedom au Market avec dans Réglages > Système > Configuration > Réseaux

JbGwa3K.png

 

De mon côté aucune règle d'accès configuré (cf plus haut).
Pour moi cela est redondant avec :

  • En LAN : (i) l'utilisation du DNS local qui pointe vers le NAS sur lequel (ii) le Reverse proxy fait pointer sur le bon port de Home Assistant
  • En WAN : (i) l'utilisation de l'entrée CNAME du DNS de mon registrar qui fait pointer vers mon ndd.tld qui (ii) pointe ensuite via le Dyn DNS du registrar vers mon Routeur sur lequel (iii) mon firewall route le vers mon NAS sur lequel (iv) le Reverse proxy fait pointer sur le bon port de Home Assistant.

Est-ce bien cela ?
SI oui, pourquoi as tu conservé ce paramétrage ?

Merci d'avance,

Posté(e) (modifié)

@TuringFan

Bonjour,

Il y a 1 heure, TuringFan a dit :

En revanche je ne lui ai pas encore formellement banni l'accès à internet depuis mon Routeur (ce que je vais surement faire d'ailleurs).
J'avais sur mon Routeur une règle de transfert de port que j'ai désactivé suite à l'activation de mon Reverse Proxy.

Attention si tu lui banni l'accès à Internet, dans ce cas ton homeAssistant ne pourra plus accéder au market et tu ne pourras plus intégrer de plugins.

Il y a 1 heure, TuringFan a dit :

Pas d'accès externe configuré et pas de DynDNS sur cette machine donc a priori pas joignable directement depuis l’extérieur sans passer par mon routeur puis mon Reverse Proxy ?

ET

Il y a 1 heure, TuringFan a dit :

Est-ce bien cela ?
SI oui, pourquoi as tu conservé ce paramétrage ?

Bah Non . Je suppose que ton HomeAssistant est comme Jeedom, il lui faut pouvoir joindre (et être joignable sur) le réseau interne local et de même pouvoir atteindre l'extérieur (Market entre autres). Voilà ce que j'ai pour mon Jeedom :

PGnEk4y.png

A lui aussi il faut donc que tu lui indiques dans sa comfiguration comment communiquer avec son environnement.

Il y a 1 heure, TuringFan a dit :

Juste pour ma culture, d'un point de vue technique que ce passe t il quand on configure une URL externe ? C'est une sorte de dynDNS ?

Je crains que tu ne mélanges les notions :

  • Je ne sais ce que tu appelles une URL "externe", mais une URL qu'elle soit utilisée en locale ou sur un client externe, est juste une @IP réécrite sous forme "littérale" si je puis dire. Dans ta copie d'écran de ton HomeAssistant pour les URL internes ou externes tu peux saisir indifféremment http(s)://@IPLocale/@IPexterne ou http(s)://sousdomaine.ndd.tld auquel tu ajoutes selon, le port 80 HTTP ou 443 HTTPS.
  • Un DynDNS est un système qui permet de "relier" ton @IP externe à ton nom de domaine. Ainsi quand ton @IP externe change, le NAS s'en apperçoit et informe OVH qui met à jour automatiquement le lien entre cette nouvelle @IP et ton nom de domaine.
Il y a 1 heure, TuringFan a dit :

Ok, dans ce cas cela pourrais-je créer une entrée dans mon Reverse Proxy pour pointer vers mon routeur qui me permettrait d'éviter de copier à la main tous les 3 mois mon certificat depuis mon NAS (cf. ton super tuto) vers mon Routeur ?

Décidemment, désolé mais tu mélanges tout. En deux mots, avec le Reverse Proxy tu crées des règles de redirection automatique des flux Internets en fonction du sous domaine indiqué dans l'URL entrante vers une application/service donné sur ton réseau local principalement (mais cela peut être aussi vers un NAS externe par ex).

Par ailleurs, ton routeur tout comme ton NAS a besoin d'un certificat SSL LE pour fonctionner correctement. Tu y couperas pas il te faudra tous les trois mois (après chaque renouvellement) charger manuellement sur ton routeur les fichiers de ton certificat générés sur ton NAS. Cela n'a rien à voir avec le Reverse Proxy.

Cordialement

oracle7😉

 

Modifié par oracle7
Posté(e)

Ok mais je ne comprends pas pourquoi paramétrer ces éléments puisque de toute façon l'accès se faite déjà via https://homeassistant.ndd.tld  depuis le WAN et le LAN ?

Le 20/03/2022 à 12:47, oracle7 a dit :
  • Je ne sais ce que tu appelles une URL "externe", mais une URL qu'elle soit utilisée en locale ou sur un client externe, est juste une @IP réécrite sous forme "littérale" si je puis dire. Dans ta copie d'écran de ton HomeAssistant pour les URL internes ou externes tu peux saisir indifféremment http(s)://@IPLocale/@IPexterne ou http(s)://sousdomaine.ndd.tld auquel tu ajoutes selon, le port 80 HTTP ou 443 HTTPS.
  • Un DynDNS est un système qui permet de "relier" ton @IP externe à ton nom de domaine. Ainsi quand ton @IP externe change, le NAS s'en apperçoit et informe OVH qui met à jour automatiquement le lien entre cette nouvelle @IP et ton nom de domaine.

Ok mais dans le cas où je préciserais https://@IPexterne:443 comment le flux serait amené jusqu'au Home Assistant une fois arrivé à ma passerelle WAN<->LAN (mon routeur chez moi) ?

Le 20/03/2022 à 12:47, oracle7 a dit :

Décidemment, désolé mais tu mélanges tout. En deux mots, avec le Reverse Proxy tu crées des règles de redirection automatique des flux Internets en fonction du sous domaine indiqué dans l'URL entrante vers une application/service donné sur ton réseau local principalement (mais cela peut être aussi vers un NAS externe par ex).

Par ailleurs, ton routeur tout comme ton NAS a besoin d'un certificat SSL LE pour fonctionner correctement. Tu y couperas pas il te faudra tous les trois mois (après chaque renouvellement) charger manuellement sur ton routeur les fichiers de ton certificat générés sur ton NAS. Cela n'a rien à voir avec le Reverse Proxy.

Oui ça c'est bien clair pour moi mais tu semblais indiqué que le passage par le Reverse proxy permettait de faire la certification puisque celui-ci est hebergé sur mon NAS qui possède un certificat valide.

Je me disais donc qu'un passage par le Reverse Proxy pour aller sur le Routeur pourrait permettre de s'affranchir du certificat sur celui-ci.

Ta réponse est claire : ce n'est pas possible (même si je n'ai pas le niveau pour comprendre pourquoi).

Merci encore, 

  • 3 semaines après...
Posté(e)

Bonjour,

Je viens de découvrir ce topic (je vais essayer de faire ma présentation dès que possible).

Tout fonctionne sauf le certificat let's encrypt.

J'ai désactivé le pare-feu, j'ai bien la redirection de ports 80 et 443 sur ma freebox, mais impossible de joindre le serveur let's encrypt.

Je n'ai aucune configuration de sécurité atypique sur mon NAS, j'ai eu ce message dès la première tentative.

J'ai mis une adresse email perso, est-ce nécessaire d'avoir le mail associé à mon domaine ?

Je vous remercie d'avance.

image.thumb.png.a11db9e6e624cc02e0e6087f99a7157b.png

Posté(e)

@Kyar Puisque vous avez un ndd perso, je vous conseille vivement de laisser tomber la méthode via DSM et d'appliquer l'un des tutos suivants :

Si votre NAS est compatible Docker :

S'il ne l'est pas :

Posté(e)

bonjour

j'ai suivie le tuto, j'ai bien validé mes certificats comme demandé, mais pourtant j'ai une alerte comme quoi mes redirections ne sont pas sécurisé . J'ai fait ca:

Est ce bon?

merci

 

capture1.png

Posté(e)

non, pour l'instant je joins directement les sous dommaines en ecrivant le https. Je verrais plus tard pour l'http (en effet, j'heberge deux site sur deux nom de domaines, ce qui complique la tache).

Posté(e)

j'ai compris le probleme , il fallait que j'aille dans certificat>parametres , et lier les services avec le certificat du bon site. Maintenant tout fonctionnne. Il y a encore une chose, j'aimerait pouvoir me connecter à roundcube avec le reverse dns, du style https://mail.monsite.fr. Cependant pour faire un proxy inversé, il me faudrait le port de destination sur localhost, mais j'ai l'impression que ca n'existe pas pour mail station , ni pour phpmyadmin. Comment puis je leur creer leur port?

merci

Posté(e)

Merci pour ta réponse Mic, j'ai bien mon certificat maintenant.

J'ai par contre un nouveau problème, je n'ai plus accès au websocket avec mon reverse proxy (socked closed dans un terminal Docker).

Dans mes recherches je dois modifier mon profil et rajouter une entrée avec le websocket mais je n'ai pas d'onglet dans mes règles de proxy inversé.

Dans les captures d'écrans, les gens ont "general", "custom header" et "advanced settings" dans une règle proxy mais moi je n'ai que la page principale avec description, source et destination.

Quelqu'un aurait une idée ?

Posté(e)
Le 11/04/2022 à 02:40, vaneck a dit :

Cependant pour faire un proxy inversé, il me faudrait le port de destination sur localhost, mais j'ai l'impression que ca n'existe pas pour mail station , ni pour phpmyadmin. Comment puis je leur creer leur port?

Ce sont des applications Web qui tournent dans le Serveur Web du NAS (Web Station), et qui utilisent donc les port standard du serveur (80 et 443). Tu ne peux pas modifier ces port, et donc pas passer par le Reverse Proxy.

Ce qu'il faut que tu fasses, c'est de créer des Virtual Host qui redirigeront par exemple l'URL https://phpmyadmin.monsite.fr vers le répertoire dans lequel est situé le site à atteindre (web/phpmyadmin par exemple).

Pour faire cela, il faut aller dans Web Station, Portail du service Web ...

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • 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.