Bonjour,
je rajoute aussi, la possibilité de le faire sur une livebox:
Bonjour à tous et merci de vos réponses. Désolé du retard à vous répondre mais c’est difficile pour moi d’être plus dispo en ce moment.
Que dire :
@le_top Belle réponse mais glou-glou-glou je coule, tu m’as perdu. J’aimerai être un homme de réseau mais ce n’est pas le cas. Lorsque j’aurai pris le temps de mieux connaître ça je ré-étudirai ta solution.
@WarC0zes Ta réponse servira certainement à certains qui suivent ce post mais étant sur freebox sur mes 2 sites, je ne me suis pas senti concerné. Merci tout de même.
@ddfdom Oui, sûrement je mélange un peu les choses mais ce que tu m’expliques dans ta réponse je l’avais bien assimilé. Je te repose la question que j’ai posée ici Problème de réseau et d'accès externe - #97 par Kenderv44. Pourquoi, alors que l’adresse ip de mon ha (et donc de mon nginx je suppose) est 192.168.0.34 je ne peux pas y accéder et que je suis obligé de passer par 0.0.0.0/0. ce qui me semble un peu plus craignos.
Question subsidiaire : j’ai pu me connecter à mon site 1 en 5g depuis mon tél et j’ai pu supprimer le fichier ip_bans.yaml. Donc j’ai essayé de me reconnecter depuis mon pc, et là je tombe sur cet écran
et je me retrouve de nouveau avec le fichier .ip_bans.yaml. Pourquoi l’ip publique de mon site 2 est-elle systématiquement bannie ? Merci
Edit: Où sont les logs qui pourraient me donner des pistes ?
Commentes les lignes de bannissement pour voir si c’est bien de la que vient ton soucis et surtout regard ce qui se trouve dans ce fichier
Tes nom ne sont pas en addon de HA ? Si npm est en addon il faut mettre le range des conteneurs car les addon sont des conteneurs et leur ip est différente donc par défaut ça doit être 172.16.0.0/16
Je n’ai plus de freebox à configurer depuis un moment, mais je crois qu’il y a un menu pour les dyndns. Le comble c’est que j’ai trouver un tuto en anglais, mais pas en FR:
Les IPv4 full stack chez free son fixes pas besoin de dyndns
Concernant le banissement.
Le reverse proxy n’est pas l’IP de ton HA. C’est le (groupe d’) IPs sur lequel un proxy peut faire l’intermédiare entre le client (ton téléphone) et le service final (l’interface web de HA).
Sur une installation j’ai par exemple:
http:
use_x_forwarded_for: true
cors_allowed_origins:
- https://google.com
- https://www.home-assistant.io
trusted_proxies:
- 172.30.33.0/24 # Add the IP address of the proxy server
Donc c’est tout le sous-reseau 172.30.33.0 qui est ajouté. C’est le réseau interne de mon HAOS.
Concrètement, sur cette installation j’ai un proxy nginx qui tourne dans un module complémentaire. Nginx me permets de mettre en oeuvre le HTTPS.
C’est NGINX qui décode le HTTPS en HTTP et qui transfère la requête en clair vers Home Assistant. Ensuite, NGINX va chiffre la réponse de HA au client.
Pendant ce temps là Nginx dit au service web de HA: tiens, je suis proxy, j’ai une requête qui vient de telle adresse, ce serait sympa de me donner la réponse, je la transmettrai.
Et HA se dit, mais c’est qui ce proxy? Je gardes mes secrets… Ah, OK, ce proxy c’est un copain car il est dans « Trusted proxies ».
Pour preuve de l’address, un ping:
root@core-ssh.local.hass.io:~/config# ping addon_core_nginx_proxy.hassio
PING addon_core_nginx_proxy.hassio (172.30.33.2): 56 data bytes
64 bytes from 172.30.33.2: seq=0 ttl=64 time=0.066 ms
Donc on peut mettre 172.30.33.2 pour être plus précis, et peut-être même addon_core_nginx_proxy.hassio .
C’est (dans mon cas) nginx qui reçoit les requêtes de l’adresse « publique » de HA (192.168.0.34). Ce n’est l’adresse publique de la box, mais comme entre la box et HA c’est juste du NAT, il n’y a pas besoin d’exprimer une confiance à ce niveau.
D’aillleurs, « en local » tu passe peut-être directement par le port 8123, et en externe par le port HTTPS (443). Pour mon example, le 8123 va directement sur le serveur web de HA, donc pas de proxy, mais le 443 pas par nginx, donc un proxy.
Chez moi c’est bien plus complexe encore: j’ai une box, suivi par un pare-feu sur lequel j’ai HAProxy qui fait le proxy pour HAOS qui lui est installé sur un Proxmox.
Une représentation approximative:
Je sais que je vais en perdre quelques-uns, donc pour les courageux:
J’ai configuré le DNS de mon pare-feu pour qu’il donne en interne l’addresse de lui-même (le pare-feu) comme adresse pour mon domaine ha, et en externe ce sera l’adresse public pour le même domaine. Après quelques exercices de ce genre on commence à s’y faire « au réseau ».
Mais home-assistant.local:8123 fonctionne ausse et va directement sur HAOS sans passe par le HAProxy.
Pour finir, un scan de ce reseau interne de HAOS nous apprend que le service web y tourne sur http://172.30.33.1:8099 , donc entre l’adresse http://192.168.0.34:8123 et le vrai serveur il y a également une traduction (attendue, mais avec changement de port).
root@core-ssh.local.hass.io:~/config# nmap -p 1-9000 172.30.33.1/24
Starting Nmap 7.94 ( https://nmap.org ) at 2025-04-15 22:12 CEST
Nmap scan report for addon_core_mosquitto.hassio (172.30.33.0)
Host is up (0.000014s latency).
Not shown: 8996 closed tcp ports (reset)
PORT STATE SERVICE
1883/tcp open mqtt
1884/tcp open idmaps
8883/tcp open secure-mqtt
8884/tcp open unknown
MAC Address: 62:14:EA:11:23:59 (Unknown)
Nmap scan report for addon_core_nginx_proxy.hassio (172.30.33.2)
Host is up (0.000015s latency).
Not shown: 8998 closed tcp ports (reset)
PORT STATE SERVICE
80/tcp open http
443/tcp open https
MAC Address: F6:CC:3D:CD:FB:16 (Unknown)
Nmap scan report for addon_a0d7b954_uptime-kuma.hassio (172.30.33.3)
Host is up (0.000014s latency).
Not shown: 8999 closed tcp ports (reset)
PORT STATE SERVICE
3001/tcp open nessus
MAC Address: 96:62:FC:35:7F:18 (Unknown)
Nmap scan report for core-ssh.local.hass.io (172.30.33.1)
Host is up (0.0000070s latency).
Not shown: 8998 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
8099/tcp open unknown
Nmap done: 256 IP addresses (4 hosts up) scanned in 2.81 seconds
1 « J'aime »
Petit détail ce que tu appel réseau interne de HA est le bridge réseau docker qui connecte les composants entre eux, HA étant lui aussi un conteneur docker comme tous les addons dans HAos
Waouh ! Moi qui espérait une réponse simple. Belle explication, j’ai tout lu mais j’ai pas tout compris. Merci tout de même ça servira sûrement à un certain nombre d’entre nous.
Un peu de mieux tout de même. J’ai supprimé à 2 reprises le fichier ip_bans.yaml hier soir mais je n’ai toujours pas pu me reconnecter depuis mon pc. Mais plus têtu (obstiné 
) qu’1 breton y’a pas ( sauf 2 bretons). Donc ce midi j’ai réessayé de me connecter, toujours depuis mon pc, et là surprise, je me connecte sans problème. Je n’ai rien fait d’autre que ce que je viens de décrire. Les bannissements auraient-ils une durée de vie limitée après avoir été supprimés du fichier ? Toujours est-il que depuis ce midi je suis connecté à plusieurs reprises sans problème depuis mon site 2.
Il me reste à tester le changement de 0.0.0.0/0 en 192.168.0.34/16 mais là je le ferai quand je serai sur site 1, trop peur de ne plus pouvoir m’y connecter depuis le site 2.
Merci à tous et à vos bonnes ondes anti-bannissement.
Joyeuses fêtes de Pâques et gare aux indigestions de chocolats
1 « J'aime »
Attention c’est 192.168.1.34 @Kenderv44
Tu devrais te faire une matrice de flux pour comprendre ce qui se passe va aide des fois un petit schéma
Pourquoi 1.34 moi je suis en 192.168.0.1 à 192.168.0.254. C’est quoi une matrice de flux ? Y’a plus de 50 ans que j’ai quitté l’école alors j’ai besoin de recyclage.
C’est mon doigt qui a rippé
oublies le /16 surtout
C’est un schéma qui défini par ou passe le flux de communication comme l’a mis dans son post @le_top
C’est bien là le problème, c’est que je n’en sait trop rien. Entre mon PC, mon installation ha sur un Rpi, une box, un fournisseur de nom de domaine, un Nginx je ne sais pas bien qui parle a qui et par quel chemin. Bientôt octogénaire il ne fait pas trop m’en demander. C’est déjà pas mal que je puisse faire fonctionner ma domotique tant bien que mal. Parfois ça rame.
1 « J'aime »
C’est justement un bon moyen d’avancer sur le sujet
Un peu caché, j’avais mis le lien vers l’édition en ligne de de schéma au-dessus du schéma.
Malheureusement l’interface du forum ne comprend pas « mermaid » - peut-être un truc à activer.
Schéma que j’ai fait en partie pour suggérer ce qui a été ensuite écrit: se faire un petit schéma peut aider, et aussi , partager le schéma qu’on pense avoir peut aider à se faire aider - y compris à corriger le schéma.
J’ai écris VM, mais c’est en réalité conteneur, car out est sous conteneur docker sous HAOS.
C’est là ou il faut faire attention: il faut mettre l’IP depuis laquelle le proxy (souvent nginx) communique avec le service web (« interne ») de home-assistant.
D’ailleurs on peut mettre plusieurs IP (déjà que /24 après l’adresse IP implique 256 adresses).
Je pense que le fichier des bans n’est relu qu’au prochain démarrage de home assistant et qu’il sert justement à se rappeler des bans précédemment appliqués - sinon la liste est en mémoire et le fichier des ban n’est pas surveillé.
Il y a peut-être un service qui permets désormais de réautoriser une IP sans redémarrage, mais il y a des années en arrière je ne l’ai pas trouvé.
Merci de ta réponse. Le schéma est assez explicite mais je ne comprends pas à quoi correspondent les 2 adresses 172.30.33.1 et 172.30.33.2. Ce sont des exemples je suppose ?
Pour mon install ce serait 192.168.0.34 je peux donc mettre 192.168.0.34 avec ou sans /24 dans mon fichier configuration.yaml ?
A quoi servent ces lignes dans l’exemple que tu donnes une peu plus haut ? Merci
Ce sont les adresses côté docker car tous les composants HA sont en fait des conteneurs docker
Oui tu peux mettre l’adresse complète de ton reverse proxy sans le /24
L’intérêt du schéma est d’avoir une vue synthétique de comment est architecturé ton réseau
Comme le dit ddfdom, ce sont les adresses des conteneurs docker qui tournent sous HAOS.
C’est à priori pour tous les HAOS la même plage.
Ils sont issues du rapport de nmappartagé plus haut (c’est un outil pour scanner le réseau):
Nmap scan report for addon_core_nginx_proxy.hassio (172.30.33.2)
Nmap scan report for addon_a0d7b954_uptime-kuma.hassio (172.30.33.3)
Nmap scan report for core-ssh.local.hass.io (172.30.33.1)
On constate que sur cette installation 172.30.33.2 est l’adresse IP de l’addon NGINX. Et dans mon cas c’est mon reverse proxy.
Cela dépend: si ton reverse proxy indique qu’il est sur l’adresse 192.168.0.34 au service web interne de home assistant ce sera utile, sinon ce sera probablement inutile et certainement insuffisant, mais non gênant.
Je ne me rappelle plus exactement des cas de figure précis.
CORS est un mécanisme pour le domaine https://www.home-assistant.io va accéder à des données sur mon instance.
Quand on passe sagement par le navigateur cela permet de réguler en partie la possibilité de consulter une resource à partir d’un autre domaine.
Ce n’est pas une « autorisation » complète car il reste les clefs API à fournir par exemple.
Quand on construit la requête avec un outil tel que CuRL, on contourne aisément cette limitation.
Il n’y a probablement pas besoin de l’ajouter pour tout le monde, mais j’en ai eu besoin à un moment donné à minima.
1 « J'aime »
OK, merci à tous pour vos explications en espérant qu’elles aient pu servir également à d’autres que moi
Joyeuses Pâques
1 « J'aime »
Son nginx proxy manager n’est pas en addon , n’est ce pas @Kenderv44 ?
D’où l’intérêt d’un schéma
Selon un post plus haut, @Kenderv44 a installé Nginx Proxy Manager, vue le nom, que c’est l’add on.
Mon installation utilise NGINX Home Assistant Proxy SSL.