[Tuto] Reverse Proxy

[Einsteinium]

il y a 39 minutes, MilesTEG1 a dit :

Je veux bien reconnaitre que la commande que tu cites permet de savoir rapidement quels ports sont ouverts, mais je pense que les hackers utilisent des scripts où ils codent en durs les ports à tester. Et là, si tu n'as pas changé tes ports, tu risques l'attaque via une faille.

Effectivement, grossière dit, la plus part ce sont des bot qui farm les IP et en fonction test les ports des services les plus connus, idéalement il ne faut pas faire de l’ouverture de port, mais du reverse proxy avec des sous domaines exotiques (les ftp, mail, Plex.domaine.tld reviennent à la même chose que de laisser les ports par défauts)

Acme avec la méthode api Ovh, qui passent par enregistrement txt sur le domaine, permet de s’affranchir du port 80 à ouvrir, donc inutile s’ouvrir au monde.

Pour Plex va voir la configuration que je donne sur la version express, si tu as un sous domaine, nul besoin d’ouvrir le moindre port et tu pourras limite ton sous domaine à la France sans soucis 😉

[MilesTEG1]

Il y a 8 heures, oracle7 a dit :

Je te joins un lien intéressant sur un aspect des méthodes d'attaques, je te laisse en en juger  ...

Salut @oracle7

Tu es sûr de ton lien ? il point sur la page 6 du topic... Tu voulais pointer sur un post en particulier ?

Il y a 8 heures, Einsteinium a dit :

Effectivement, grossière dit, la plus part ce sont des bot qui farm les IP et en fonction test les ports des services les plus connus, idéalement il ne faut pas faire de l’ouverture de port, mais du reverse proxy avec des sous domaines exotiques (les ftp, mail, Plex.domaine.tld reviennent à la même chose que de laisser les ports par défauts)

Salut @Einsteinium également,

Yep, j'évite toujours les mots classiques pour les sous-domaines : files, camera, plex... soit je fais des abréviations maison, soit j'utilise un mot francisé 🙂 

Et tout à fait, il y a quelques mois, certains m'avaient convaincu de cesser d'exposer mon DSM via son nom de domaine (je passais quand même par le reverse proxy mais open pour y accéder depuis internet).
Maintenant, je n'ai que le port 443 et 6690 d'ouvert, et j'ai mis un profil de contrôle d'accès restreint aux IP LAN et VPN pour l'accès à DSM.

Je crois que c'était au début des attaques sur les QNap.

Il y a 8 heures, Einsteinium a dit :

Acme avec la méthode api Ovh, qui passent par enregistrement txt sur le domaine, permet de s’affranchir du port 80 à ouvrir, donc inutile s’ouvrir au monde.

Pour Plex va voir la configuration que je donne sur la version express, si tu as un sous domaine, nul besoin d’ouvrir le moindre port et tu pourras limite ton sous domaine à la France sans soucis 😉

Ok, je vais aller voir plus en détail ton tuto express 🙂 
Je te tiens au courant.
merci 🙂 

[MilesTEG1]

@Einsteinium J'ai coupé l'accès au port 443 au monde entier, sauf à la France pour laquelle j'ai une ligne dans mes parefeu qui l'autorise.
Et tout semble continuer de fonctionner sans soucis.
Merci 🙂 

[kevin.vanacppel]

Bonjour, 

 

  bon, toujours impossible d'ajouter un certificat.

@Kramlech : oui, l'IP est bien une IP fixe non partagée (IP fixe V4 full-stack - j'ai revérifié mon compte Free pour être sûr).

 

  Bien à vous

  

[oracle7]

@kevin.vanacppel

Bonjour,

il y a 24 minutes, kevin.vanacppel a dit :

bon, toujours impossible d'ajouter un certificat.

Quelle erreur t'est-elle retournée par DSM ?

Les ports 80 et 443 sont-ils bien transférés (NAT) de ta box vers le NAS et ces mêmes ports sont-ils bien ouverts/autorisés dans le pare-feu du NAS ?

As-tu fait récemment plusieurs tentatives de création du certificat LE i.e. au moins 5 dans la même semaine ?

Cordialement

oracle7😉

Modifié le 5 mars 2022 par oracle7

[kevin.vanacppel]

Bonjour @oracle7,

  oui, les ports 80 et 443 sur la Freebox redirigent bien vers le Synology (au passage, qui a bien une IP fixe).

  Sur le Synology, l'ajout du certificat ne fonctionne pas que ça soit avec un pare-feu activé ou non (dans le cas où le pare-feu est activé, les ports 80 et 443 sont bien ouverts sur le Synology).

  Egalement, si je teste l'accès à mon nom de domaine (http://ndd.fr / https://ndd.fr), j'accède bien à la page par défaut Web Station si ça peut aider.

  Bien à vous

[Thierry94]

Bonjour,

Par hasard tu n'aurais pas mis une limitation adresses ou régions sur le port 80 dans ton pare-feu ?

[kevin.vanacppel]

@Thierry94

  Le pbl est présent avec un pare-feu activé ou désactivé (lorsque le pare-feu est activé, il n'y a aucune limitations d'adresses ou régions sur le port 80 sur le Synology).

  Bien à vous

[oracle7]

@kevin.vanacppel

Bonjour,

Je te ré-itère ma question : As-tu fait récemment plusieurs tentatives de création du certificat LE i.e. au moins 5 dans la même semaine ?

Chez quel fournisseur de domaine es-tu ?

Cordialement

oracle7😉

[kevin.vanacppel]

@oracle7

  Oui, j'ai effectué plusieurs tentatives de création du certificat, au moins 3 tentatives par jour cette semaine.

  Pour le fournisseur de domaine : OVH.

  Bien à vous

[MilesTEG1]

Les tentatives de création comptent dans le quota de Let's Encrypt ??

[oracle7]

@kevin.vanacppel @MilesTEG1

Bonjour,

Il y a 10 heures, kevin.vanacppel a dit :

Oui, j'ai effectué plusieurs tentatives de création du certificat, au moins 3 tentatives par jour cette semaine.

C'est bien ce que je pensais, ne cherches donc pas plus loin, tu as dépassé les limites fixées par LE quelque soit l'option création ou renouvellement. Tu as "droit" à 5 tentatives maximum par semaine calendaire. Maintenant tu es bloqué et il te faut attendre une semaine calendaire à compter de la dernière tentative effectuée pour pouvoir en refaire une nouvelle.

Par ailleurs, si je peux me permettre, quand quelque chose ne marche pas comme prévu, il est inutile de s'excrimer à refaire/relancer cette chose, cela ne marche généralement pas mieux, voire on empire les choses et c'est totalement contre-productif. Maintenant ce que j'en dit, c'est toi qui voit ...

Cordialement

oracle7😉

[TuringFan]

Bonjour à tous,

Je vous prie par avance de m'excuser si je poste au mauvais endroit, dans ce cas n’hésitez pas à me dire où poster.

Ma configuration

1. J'ai un NAS Synology derrière un Routeur Synology en DMZ d'une Livebox.
2. J'avais historiquement suivi ce tuto et celui sur le DNS et grâce à eux et à un DynDNS j'accède aujourd'hui sans problème à mes différents services via des "sous domaines" (ex : files.ndd.tld) depuis une IP LAN/VPN/WAN.
3. Je souhaite maintenant me lancer dans la domotique et je viens donc d'installer sur mon LAN un Raspberry Pi 4B 4Go sur lequel tourne Home Assistant dont l'adresse IP est 192.168.XX.XX et le port 8123 - pour information je me suis posé la question de l'arbitrage entre Raspberry et NAS et j'ai opté pour le premier pour (i) avoir un laboratoire sur lequel je peux "faire des bêtises" et (ii) car j'ai souvent lu que l'intégration Home Assistant sur un NAS Synology était parfois compliquée à cause de problèmes de compatibilité.

Mon paramétrage Home Assistant

Au même titre que mes différents services sur mon NAS j'ai donc :

1. Fixé l'adresse IP locale de mon Raspberry via le DHCP de mon routeur
2. Créé sur la résolution locale de mon DNS (hébergé sur mon routeur) une entrée du type : home.ndd.tld A 86400 192.168.XX.XX. Sauf erreur de ma part cela permet, uniquement à mes équipement locaux (LAN/VPN), de pointer sur mon Raspberry sans se souvenir de l'adresse IP : est-ce bien cela ?
3. Créé un redirection depuis mon registar : home.ndd.tld CNAME 0 ndd.tld. Sauf erreur de ma part cela permet, aux équipement exterieurs (WAN), de pointer sur mon Raspberry sans se souvenir de l'adresse IP extérieur de mon routeur : est-ce bien cela ?
4. Créé une entrée dans le reverse proxy : home.ndd.tld HTTPS 443 vers HTTP 8123 192.168.XX.XX.
5. Créé sur mon routeur une règle de redirection de ports 8123 WAN vers 8123 IP 192.168.XX.XX.

A noter que je n'ai pas de problème de certificat car j'ai suivi le tuto de @oracle7 sur les certificats wildcard.

Mes questions :

1. J'ai peur de m'enméler un peu les pinceaux entre (i) redirection Registar, (ii) DNS local et (iii) reverse proxy : le (i) permet de pointer vers mon LAN avec un nom de domaine (et non une IP externe qui change régulièrement), le (ii) permet de pointer via un domaine vers un appareil de mon LAN (et non une IP locale) et le (iii) permet de pointer via un domaine vers une application avec un port dédié et non une IP et un port : c'est bien cela ?
2. Avec cette configuration j'arrive à bien accéder à mon service Home Assistant depuis le WAN en https via https://home.ndd.tld en revanche impossible depuis le LAN Je suis obligé de passer par du http (ce qui n'est pas un problème en LAN) mais aussi de devoir préciser le port via http://home.ndd.tld:8123. Je ne comprends pas pourquoi cette différence ? Pouvez-vous svp m'aider là dessus ?

A noter que comme indiqué ici j'ai activé les Web Sockets (sans comprendre pourquoi) sur le reverse proxy de ce service et validé l'IP de mon NAS en tant que proxy de confiance dans la configuration de Home Assistant.

Merci d'avance pour votre aide,

Modifié le 13 mars 2022 par TuringFan

[_DR64_]

il y a une heure, TuringFan a dit :

Créé une entrée dans le reverse proxy : home.ndd.tld HTTPS 443 vers HTTP 80 192.168.XX.XX:8123.

C'est faux ça

home.ndd.tld HTTPS 443 vers HTTP 8123 192.168.XX.XX

il y a une heure, TuringFan a dit :

Créé une règle de redirection de ports 8123 WAN vers 8123 LAN sur mon routeur.

ça aussi d'ailleurs.

Ton routeur est en DMZ sur ta box donc tous les ports sont ouverts vers celui là.
 
Le reverse proxy fonctionne dans ta configuration sur le port WAN HTTPS (443).
En gros, tout le flux exterieur HTTPS 443 arrive sur ton routeur.

Tu dois rediriger dans ton routeur 80 et 443 vers ton NAS

Ensuite dans ton NAS, tu configure ton reverse proxy en lui disant par exemple https://home.ndd.tld:443 = http://localhost:80
ou encore https://home.ndd.tld:443 = http://192.168.1.17:8123

Ton registrar te fait pointer vers ton IP WAN, ton IP WAN te fait pointer vers ton routeur, ton routeur te fait pointer vers ton NAS, ton NAS te fait pointer vers ton périphérique / application

[oracle7]

@TuringFan

Bonjour,

Ahreee... 🤣🤪 grillé par @GrOoT64 qui t'a parfaitement répondu sur tous les points.

Cela dit, car j'ai exactement la même configuration box/DMZ routeur/NAS/RPI4Jeedom, et j'accède sans problème avec un jdom.ndd.tld en local comme de l'extérieur à mon Jeedom, du coup je me pose une question. Tu dis que tu as installé sur un RPI4 un "Home Assistant" pour te lancer dans la domotique mais sans indiscrétion, pourquoi ce choix et pourquoi n'as-tu pas tout simplement installé sur ton RPI4 un Jeedom avec boot sur SSD ? C'est à mon humble avis une solution bien plus ouverte et performante et de surcroît plus évolutive pour faire de la domotique. En plus Jeedom dispose d'une communauté très active pour son support (à l'image de la présente pour les NAS).

Après avoir largement épluché la toile sur ce sujet, je suis en train personnellement de déployer cette solution et j'en suis extêment content. J'en suis à une trentaine de capteurs divers en Zigbee et une bonne dizaine en Z-Wave.

Tu devrais y regarder de plus près. Maintenant ce que j'en dis. C'est toi qui voit ...

Cordialement

oracle7😉

[TuringFan]

Merci pour vos réponses rapides @GrOoT64 et @oracle7,

J'étais visiblement fatigué quand j'ai rédigé mon poste car j'ai écris des bêtises /imprécisions :

Il y a 10 heures, GrOoT64 a dit :

C'est faux ça

tu as raison

Il y a 10 heures, GrOoT64 a dit :

home.ndd.tld HTTPS 443 vers HTTP 8123 192.168.XX.XX

c'est bien ce que j'ai sur mon reverse proxy (je passe un edit sur mon post original pour corriger)

Il y a 10 heures, GrOoT64 a dit :

ça aussi d'ailleurs

raison encore

Il y a 10 heures, GrOoT64 a dit :

https://home.ndd.tld:443 = http://192.168.1.17:8123

c'est bien ce que j'ai (je passe un edit sur mon post original pour corriger)

Il y a 10 heures, GrOoT64 a dit :

https://home.ndd.tld:443 = http://localhost:80

pas certain de comprendre cette entrée :

• Localhost c'est pour la même machine non (donc mon NAS dans mon cas) ?
• Pourquoi un reverse proxy HTTPS vers HTTP sur la même machine ?
• Dans tous les cas j'imagine que chez moi le localhost doit être remplacé par l'IP d'Home Assistant ?

Il y a 10 heures, GrOoT64 a dit :

Tu dois rediriger dans ton routeur 80 et 443 vers ton NAS

j'ai également ces deux redirections sur mon routeur

Il y a 10 heures, GrOoT64 a dit :

Ton registrar te fait pointer vers ton IP WAN, ton IP WAN te fait pointer vers ton routeur, ton routeur te fait pointer vers ton NAS, ton NAS te fait pointer vers ton périphérique / application

ok donc :

• X.ndd.tld. -> IP WAN  : via une entrée CNAME du registrar
• IP WAN -> IP LAN Routeur (qui héberge le DNS local) : via le Routeur en lui-même ?
• IP LAN Routeur -> IP LAN NAS : via DNS local (hébergé sur le Routeur)
• IP LAN NAs -> IP LAN + port service : via Reverse Proxy (hebergé sur le NAS)

C'est bien cela ?

Du coup je ne comprends toujours pas pourquoi pour ce service spécifique je dois sur mon LAN (i) utiliser du http et (ii) préciser le port alors que je reste toujours (LAN/VPN/WAN) en https sans précision de port pour tous mes autres services !

@GrOoT64 et @oracle7 Avez-vous une explication là dessus ?

Il y a 2 heures, oracle7 a dit :

Cela dit, car j'ai exactement la même configuration box/DMZ routeur/NAS/RPI4Jeedom, et j'accède sans problème avec un jdom.ndd.tld en local comme de l'extérieur à mon Jeedom, du coup je me pose une question. Tu dis que tu as installé sur un RPI4 un "Home Assistant" pour te lancer dans la domotique mais sans indiscrétion, pourquoi ce choix et pourquoi n'as-tu pas tout simplement installé sur ton RPI4 un Jeedom avec boot sur SSD ? C'est à mon humble avis une solution bien plus ouverte et performante et de surcroît plus évolutive pour faire de la domotique. En plus Jeedom dispose d'une communauté très active pour son support (à l'image de la présente pour les NAS).

Super remarque : justement je n'ai trouvé aucun argument fort en faveur ou en défaveur d'une des deux solutions (Jeedom vs. Home Assistant) en dehors du fait que (i) Home Assistant semblait intégrer plus rapidement de nouveaux équipements et (ii) l'UX me semblait assez sympa. La communautés semble également bien présente en français ou en anglais. Mais honnêtement je suis encore en phase de test et pas impossible que j'essaie ensuite Jeedom. Je suis preneur d'arguments factuels pour l'arbitrage entre les deux solutions si tu en as ?

Pour info je boot bien mon Home Assistant directement depuis une clé USB SSD branchée sur mon Raspberry Pi 4B 4Go qui est branché au LAN en RJ45.

A noter d'ailleurs que j'observe sur mon routeur une IP LAN différente pour mon Raspberry Pi et Home Assistant ! Quand Home Assistant est booté le raspberry semble alors non connecté au réseau ... Comme si sur un PC je dissociais le PC vs. Windows qui prendrait le dessus sur le hardware ... D'ailleurs quand je fais du SSH je ne peux atteindre le Raspebrry Pi uniquement quand Home Assistant n'est pas booté. As tu le même comportement ? Est-ce un sujet de machine virtuelle ou similaire ?

PS pour les protocoles je pense a priori partir sur du Z-Wave et EnOcean.

Merci encore,

Modifié le 13 mars 2022 par TuringFan

[_DR64_]

il y a 17 minutes, TuringFan a dit :

• Localhost c'est pour la même machine non (donc mon NAS dans mon cas) ?
• Pourquoi un reverse proxy HTTPS vers HTTP sur la même machine ?
• Dans tous les cas j'imagine que chez moi le localhost doit être remplacé par l'IP d'Home Assistant ?

1- Localhost c'est pour la même machine oui (j'ai mis cet exemple au cas ou 😄 )
2- Si tu veux te passer de taper le numéro de port à la fin de tes adresses pour les applications de ton NAS par exemple, ou encore même pour joindre directement DSM tu rediriges l'adresse https://dsm.ndd.tld (443 de base) vers http://ipdunas:5000 
3- oui tout à fait

il y a 23 minutes, TuringFan a dit :

Du coup je ne comprends toujours pas pourquoi pour ce service spécifique je dois sur mon LAN (i) utiliser du http et (ii) préciser le port alors que je reste toujours (LAN/VPN/WAN) en https sans précision de port pour tous mes autres services !

Erreur de config quelque part surement.
Si tu ping ton adresse en question, elle pointe vers le NAS ou vers le RPI ? car elle devrait pointer vers le NAS comme c'est lui qui le transfert vers ton RPI

Pour le dernier point, je parle en LAN hein :')

[oracle7]

@TuringFan

Bonjour,

@GrOoT64 a encore dégainé plus vite que moi ....🤣

il y a 27 minutes, TuringFan a dit :

Du coup je ne comprends toujours pas pourquoi pour ce service spécifique je dois sur mon LAN (i) utiliser du http et (ii) préciser le port alors que je reste toujours (LAN/VPN/WAN) en https sans précision de port pour tous mes autres services !

Pour compléter, je dirai qu'il est contre productif de faire du HTTPS sur le réseau local. C'est inutile, car tu n'as pas de pirates en herbes chez toi ? De plus, avec le Reverse Proxy tu entres déjà en HTTPS via l'unique port 443 et ensuite il te redirige vers l'application cible sur son port dédié et cela en HTTP puisque l'on est sur le réseau local sinon cela reviendrait à crypter (HTTPS sur HTTPS) une seconde fois un flux HTTPS déjà lui même sécurisé. Donc ta redirection de Reverse Proxy doit être simplement https://home.ndd.tld:443 vers http://@IPlocalHomeAssistant:8183.
La destination cible est http://localhost:port uniquement quand tu veux atteindre DSM (5000) ou des applications du NAS du type FileStation (7000), AudioStation (8800, SurveillanceStation (9900), etc ...

il y a 36 minutes, TuringFan a dit :

justement je n'ai trouvé aucun argument fort en faveur ou en défaveur d'une des deux solutions (Jeedom vs. Home Assistant)

Je crains que HomeAssistant soit une solution moins ouverte que Jeedom,de plus HomeAssitant que je saches n'intègre pas plus vite un capteur que Jeedom. Cela tient essentiellement (si j'ai bien compris) au plugin que tu utilises pour gérer ton réseau Zigbee, z-Wave ou EnOcéan.

il y a 50 minutes, TuringFan a dit :

A noter d'ailleurs que j'observe sur mon routeur une IP LAN différente pour mon Raspberry Pi et Home Assistant ! [...] As tu le même comportement ? Est-ce un sujet de machine virtuelle ou similaire ?

Non pas du tout le même comportement. Quand Jeedom est installé sur un SSD (connecté en USB3 via un hub USB3 auto alimenté), il a d'office l'@IP locale du RPI4 qui est lui même connecté en RJ45 à ton réseau local. Il n'y a donc pas de changement d'@IP. Du coup, j'accède sans problème en SSH au RPI4 via son @IP locale. De toutes façons, à part mettre à jour de système d'exploitation Linux Raspberry Pi OS (Debian Buster) de temps en temps, je n'utilise pas SSH plus que cela (pas besoin). Pour Jeedom, tout se passe dans sa propre interface. Maintenant je ne connais pas suffisament HomeAssistant pour te dire si c'est un problème de VM.

EnOcéan semble être de moins en moins usité au profit de Zigbee (le prix et la profusion des capteurs y est pour beaucoup) et en plus Zigbee est un réseau maillé. Je n'utilise z-Wave que pour certains capteurs car il porte plus loin que Zigbee mais cela reste un standard fermé contrairement à Zigbee (voir ici).

Cordialement

oracle7😉

 

 

[TuringFan]

Merci à vous deux @GrOoT64 et @oracle7

Il y a 2 heures, GrOoT64 a dit :

1- Localhost c'est pour la même machine oui (j'ai mis cet exemple au cas ou 😄 )
2- Si tu veux te passer de taper le numéro de port à la fin de tes adresses pour les applications de ton NAS par exemple, ou encore même pour joindre directement DSM tu rediriges l'adresse https://dsm.ndd.tld (443 de base) vers http://ipdunas:5000 
3- oui tout à fait

Il y a 1 heure, oracle7 a dit :

Donc ta redirection de Reverse Proxy doit être simplement https://home.ndd.tld:443 vers http://@IPlocalHomeAssistant:8183.
La destination cible est http://localhost:port uniquement quand tu veux atteindre DSM (5000) ou des applications du NAS du type FileStation (7000), AudioStation (8800, SurveillanceStation (9900), etc ...

Ok, du coup a priori je suis bon sur ma configuration :

1. J'ai ma redirection CNAM registrar : home.ndd.tld -> IP WAN de mon routeur
2. J'ai mon entrée de type A sur le DNS local (hébergé sur mon routeur) : home.ndd.tld -> IP LAN de Home Assistant
3. J'ai une redirection de ports sur mon routeur : 8123 IP WAN -> 8123 192.168.X.X (IP LAN de Home Assistant)
4. J'ai mon entrée sur mon Reverse Proxy (hébergé sur mon NAS) : https://home.ndd.tld 443 -> http://192.168.X.X:8123 (http://home.ndd.tld:8123)

Ma configuration 4 est donc superflue et je peux la supprimer (grâce au travail du reverse proxy) : je viens de supprimer cette redirection et mon accès WAN en https est préservé ce qui semble démontrer que le Reverse Proxy fonctionne bien.

En revanche je ne comprends toujours pas pourquoi en LAN je dois passer par du http et préciser le port ! Une idée ?

Il y a 1 heure, oracle7 a dit :

Non pas du tout le même comportement. Quand Jeedom est installé sur un SSD (connecté en USB3 via un hub USB3 auto alimenté), il a d'office l'@IP locale du RPI4 qui est lui même connecté en RJ45 à ton réseau local. Il n'y a donc pas de changement d'@IP. Du coup, j'accède sans problème en SSH au RPI4 via son @IP locale. De toutes façons, à part mettre à jour de système d'exploitation Linux Raspberry Pi OS (Debian Buster) de temps en temps, je n'utilise pas SSH plus que cela (pas besoin). Pour Jeedom, tout se passe dans sa propre interface. Maintenant je ne connais pas suffisament HomeAssistant pour te dire si c'est un problème de VM.

Ok peut être un truc exotique chez moi mais in fine comme toi je pense utiliser que très rarement le SSH vers le Raspberry Pi. Cela vient peut être du fait que mon raspberry est en RJ45 mais que je l'ai également configuré pour pouvoir se connecter au wifi ?

Il y a 1 heure, oracle7 a dit :

EnOcéan semble être de moins en moins usité au profit de Zigbee (le prix et la profusion des capteurs y est pour beaucoup) et en plus Zigbee est un réseau maillé. Je n'utilise z-Wave que pour certains capteurs car il porte plus loin que Zigbee mais cela reste un standard fermé contrairement à Zigbee (voir ici).

Mes capteurs EnOcean sont un héritage d'une solution grand public dont je ne suis pas satisfait (d'où ma démarche) mais je pense que les capteurs en eux même doivent faire le job.

Concernant la portée et le maillage j'ai cru comprendre que justement Z-wave était le plus robuste. Je vais lire ton article. Tu peux aussi regarder cette vidéo.

Modifié le 13 mars 2022 par TuringFan

[oracle7]

@TuringFan

Bonjour,

Désolé mais pas sûr que ta configuration soit "tout bon" :

il y a 9 minutes, TuringFan a dit :

1. J'ai ma redirection CNAM registrar : home.ndd.tld -> IP WAN de mon routeur

Pas utile si tu as défini un wilcard *ndd.tld CNAME ndd.tld dans ta zone DNS chez ton registar.

il y a 11 minutes, TuringFan a dit :

2. J'ai mon entrée de type A sur le DNS local (hébergé sur mon routeur) : home.ndd.tld -> IP LAN de Home Assistant

Idem inutile aussi si tu as défini un wilcard *ndd.tld CNAME ndd.tld dans ta zone DNS locale (DNS Server).

il y a 12 minutes, TuringFan a dit :

J'ai une redirection de ports sur mon routeur : 8123 IP WAN -> 8123 192.168.X.X (IP LAN de Home Assistant)

Inutile aussi, puisque c'est le Reverse Proxy qui fait la redirection sur ce port et que tu rentres sur le routeur via le port 443.

il y a 14 minutes, TuringFan a dit :

J'ai mon entrée sur mon Reverse Proxy (hébergé sur mon NAS) : https://home.ndd.tld 443 -> http://home.ndd.tld:8123

Non pas pour la destination de ta redirection car home.ndd.tld pointe sur ton @IP externe alors que tu dois indiquer l'@IP locale du home soit : https://home.ndd.tld:443 vers http://@IPlocalHomeAssistant:8183.

Merci pour la vidéo, c'est toujours mieux qu'un long discours ou des pages à lire ...🤣

Cordialment

oracle7😉

[TuringFan]

Merci @oracle7

il y a 20 minutes, oracle7 a dit :

Pas utile si tu as défini un wilcard *ndd.tld CNAME ndd.tld dans ta zone DNS chez ton registar.

non je n'ai pas cette entrée d'où mon ajout manuel

il y a 20 minutes, oracle7 a dit :

Idem inutile aussi si tu as défini un wilcard *ndd.tld CNAME ndd.tld dans ta zone DNS locale (DNS Server).

non je n'ai pas cette entrée d'où mon ajout manuel

il y a 20 minutes, oracle7 a dit :

Inutile aussi, puisque c'est le Reverse Proxy qui fait la redirection sur ce port et que tu rentres sur le routeur via le port 443.

en ligne : je l'ai supprimée

il y a 21 minutes, oracle7 a dit :

Non pas pour la destination de ta redirection car home.ndd.tld pointe sur ton @IP externe alors que tu dois indiquer l'@IP locale du home soit : https://home.ndd.tld:443 vers http://@IPlocalHomeAssistant:8183.

décidément j'écris n'importe quoi, pardon, mon entrée reverse proxy est bien https://home.ndd.tld:443 -> http://192.168.X.X:8123 (je passe de nouveau un edit).

Du coup ma config est bonne non ?

[oracle7]

@TuringFan

Bonjour,

il y a 27 minutes, TuringFan a dit :

Du coup ma config est bonne non ?

Oui, même si je trouve à mon humble avis que ce n'est pas "propre" pour les deux premières. Du coup, je ne comprends pas pourquoi tu ne veux pas mettre/utiliser un wilcard, c'est tellement plus simple pour la gestion ensuite, surtout lorsque tu utilises un nouveau sous-domaine : plus rien à rajouter. Et tu as en plus un certificat wilcard, alors ?

Mais bon c'est toi qui voit ...

Cordialement

oracle7😉

 

[TuringFan]

il y a 6 minutes, oracle7 a dit :

Oui, même si je trouve à mon humble avis que ce n'est pas "propre" pour les deux premières. Du coup, je ne comprends pas pourquoi tu ne veux pas mettre/utiliser un wilcard, c'est tellement plus simple pour la gestion ensuite, surtout lorsque tu utilises un nouveau sous-domaine : plus rien à rajouter. Et tu as en plus un certificat wilcard, alors ?

Tu as raison, je devrais le faire.

J'ai gardé ma configuration historique pour me forcer à repasser dessus de temps en temps et virer ce qui est inutile mais en ligne avec toi : je vais le faire.

En revanche une idée pour mon problème qui m'oblige à utiliser une adresse locale en http et à préciser le port ?

Le fait de devoir préciser le port fait penser à un défaut sur le Reverse Proxy mais le fait de ne pas avoir de redirection de port 8123 sur le Routeur et un accès valide depuis le WAn montre pourtant que le Reverse Proxy tourne ... je ne comprends vraiment pas.

Deux pistes auxquelles je pense :

1. Pour une raisin que je ne maitrise pas je dois utiliser les web socket sur l'entrée du Reverse Proxy qui correspond à Home Assistant.
2. Le comportement exotique qui semble attribuer une IP au Raspberry Pi monté "vide" (sans home assistant, uniquement Raspbian) et une IP différente quand le Raspberry Pi est monté avec Home Assistant.

Si quelqu'un à une idée ...

[_DR64_]

il y a une heure, TuringFan a dit :

https://home.ndd.tld:443

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

[oracle7]

@TuringFan

Bonjour,

il y a 55 minutes, TuringFan a dit :

Le fait de devoir préciser le port fait penser à un défaut sur le Reverse Proxy mais le fait de ne pas avoir de redirection de port 8123 sur le Routeur et un accès valide depuis le WAn montre pourtant que le Reverse Proxy tourne ... je ne comprends vraiment pas.

il y a une heure, TuringFan a dit :

En revanche une idée pour mon problème qui m'oblige à utiliser une adresse locale en http et à préciser le port ?

A défaut de me tromper, pour moi ce n'est pas un défaut sur le Reverse Proxy comme tu l'avances mais je crains plutôt qu'il ne te faille regarder du coté de ta zone DNS locale (DNS Server) qui ne gére pas bien ton sous-domaine home.ndd.fr. 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. 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.

Pour le websocket, je pense, sauf erreur de pa part, que c'est la façon dont communique ton HomeAssistant sur le réseau qui l'impose. C'est déjà le cas pour d'autres applications (calibre, photoprisme, etc ...). Mais je n'en sais pas plus , désolé ...

Cordialement

oracle7😉