Il est découpé en 4 réseaux différents afin de cloisonner et restreindre les accès :
en violet : le réseau serveurs/services qui regroupe les équipements NAS, le Home Assistant, la Freebox (entre autres) et le Firewall me permettant de contrôler les flux des autres réseaux
en bleu : le réseau des équipements PC, Imprimantes, smartphone, etc… de mon foyer
en orange : le réseau pour les invités
en vert : le réseau des équipements IoT IP
Le besoin est donc de permettre à mon Home Assistant dans le réseau violet (192.168.1.0/24) d’atteindre par exemple une Yeelight qui est dans le réseau vert (192.168.3.38).
Je suis dans l’obligation de créer une route statique sur mon Home Assistant car la passerelle par défaut étant une Freebox, il est impossible de déclarer (sur la Freebox) des routes (=> limitation du produit).
Pour résoudre cela, il faut indiquer au Home assistant de joindre l’adresse IP du Firewall (192.168.1.253) afin d’atteindre un autre réseau.
PROCEDURE
Pré-requis
Il est impératif d’installer sur Home Assistant un module complémentaire SSH. Point important, il faut installer uniquement celui se nommant « SSH & Web Terminal » et décocher le mode protégé. Ceci ayant pour effet d’accéder à des commandes avancées que nous verrons par la suite (par exemple nmcli)
Vérification du non accès à la ressource
Une fois ce module installé et configuré, nous allons essayé de joindre l’IP de la Yeelight au moyen d’un ping
On voit dans la capture d’écran que 0 packets n’ont été reçus.
Lister toutes les connections actuellement configurée
La commande nmcli device show permet d’afficher les informations suivantes :
Il est important ici de repérer le nom de la carte (ici Supervisor eth0) en charge du réseau violet. C’est donc dans cette carte que nous allons ajouter une nouvelle route (les 2 premières ont été rajoutées automatiquement).
On voit dans cette liste qu’il n’y a pas de route vers le réseau vert (192.168.3.0/24)
Edition des paramètres de la carte
La commande nmcli con edit « Supervisor eth0 » (remplacer ce nom entre guillemets suivant le nom de votre carte indiqué dans la précédente commande) permet de rentrer en mode configuration
On peut observer un changement dans le prompt (on passe ici en nmcli>)
Afficher la configuration en détail de la carte
La commande print ipv4 permet d’afficher les détails de la configuration et donc de surcharger la configuration automatique (vue lors de la commande du point 3)
Ajout de la route
Notre volonté est de rajouter une nouvelle route, pour cela il faut saisir la commande set ipv4.routes 192.168.3.0/24 192.168.1.253. Ainsi, pour atteindre le réseau 192.168.3.0/24, il faut transmettre le paquet à la passerelle 192.168.1.253
Vérification du changement
Grâce à la commande print ipv4, on peut observer l’ajout de la nouvelle route
Application de la configuration
Cette étape est primordiale sinon l’ajout de la route ne sera pas prise en compte dans la carte. Il faut sauvegarder la configuration MAIS en mode persistent afin qu’elle soit appliquée même après un reboot. On utilise donc la commande save persistent (et surtout pas uniquement save)
Le résultat de la commande montre que la configuration a bien été mise à jour.
Quitter le mode nmcli
Il ne reste plus qu’à quitter le module grâce à la commande quit
Reboot de l’hôte
Dernière étape indispensable, il faut rebooter complètement l’hôte pour que le routage soit pleinement opérationnel : attention, cette opération peut prendre un peu de temps suivant votre configuration.
Pour ce reboot :
Supervisor > System > Restart Host
Vérification du fonctionnement
Pour confirmer le fonctionnement de cette nouvelle route, nous allons exécuter la commande du point 3 et vérifier la présence de la route
Merci @crampes2 pour ce tuto clair qui devrait m’aider à raccrocher un device présent dans mon sous-réseau; j’aurais toutefois 2-3 petites questions stp :
derrière ma freebox 192.168.1.254 j’ai une Nest wifi branché en éthernet dont l’adresse est 192.168.1.15 à laquelle est connecté une enceinte Nest en 192.168.86.21 = dois-je donc considérer que l’adresse de ma passerelle est 192.168.1.15 ?
j’ai installé HA en supervised sur PI en wifi, ce qui fait que la commande nmcli device show ne fait pas apparaître de « Supervisor eth0 » : parmi la vingtaine de GENERAL.DEVICE, ils ont tous un GENERAL.CONNECTION -- Parmi les GENERAL DEVICE qui ont un IP4.ROUTE j’ai 1) docker0 (bridge en DEVICE.TYPE) 2) hassio (bridge en DEVICE.TYPE) et 3) lo (loopback en DEVICE.TYPE) ; est-ce 1 parmi ces 3 là ? ou dois-je aller chercher un DEVICE.TYPE ethernet ou wifi ? dans tous les cas, pas de moyen d’appeler un nmcli con edit « Supervisor eth0 »
si jamais j’arrive à aller au bout de la manip et qu’elle s’avère infructueuse, y a-t-il moyen de revenir en arrière ?
HA a une adresse en 192.168.1.X donc? Si c’est bien le cas, c’est ça. Il faut dire pour atteindre 192.168.86.0 passer par 192.168.1.15.
Déjà HA en wifi, c’est plutôt à éviter. Je sais, ce n’est pas la question. Juste en passant L’autre méthode pour trouver la bonne interface si rien n’apparait clairement c’est de chercher celle ou tu vois l’adresse IP de HA (le fameux 192.168.1.x). Je pense que l’interface va être en wlan0 ou wifi
Oui. A la place de « set » faire « delete ». Une fois dans nmcli con edit avec help, print, describe tu auras la syntaxe exacte à donner pour ajouter ou enlever.
En effet @golfvert a répondu, il faut bien invoquer la passerelle en 192.168.1.15.
Là encore je rejoins @golfvert sur le fait du raccordement de HA en Wifi. C’est vraiment pas le meilleur type de connexion si tu veux garantir le fonctionnement de ta domotique. Toutefois, pour choisir correctement le nom de ta connexion, ce qu’il faut regarder c’est la carte qui porte l’adresse de ton réseau local. Si tu regardes le screenshot de l’étape 3, je prends « Supervisor eth0 » car dans IP4.address il y a bien l’ip de mon HA (192.168.1.3)
Revenir en arrière est évidemment possible en faisant une commande delete.
Merci pour vos retours @golfvert et @crampes2
Là, je vais malheureusement devoir patienter car je suis confronté à un kernel panic qu’il faut que je résolve
Par contre, j’ai un soucis chez moi avec cette manip.
J’ai une freebox donc un réseau en 192.168.1.0 et un routeur google pour mon wifi.
Mon raspberry pi est connecté direct à la box et à comme ip 192.168.1.41.
De son côté mon routeur wifi Google à comme ip : 192.168.1.20 et crée lui même son propre LAN sur 192.168.86.0
J’ai suivi la procédure (ma connexion eth0 s’appele par contre « Home Assistant OS default » et j’ai donc utilisé cette commande pour ajouter la route.
Les machines en IP en 192.168.86.x derrière la boîte google, elles ont accès à Internet?
Sur la freebox (comme sur toutes les box de m…), de mémoire, pas possible de mettre une route, si je ne m’abuse.
Donc, ça veut dire que ton routeur google doit faire de la NAT et c’est pas sûr, que sans config additionnelle, ça passe ce que tu veux faire.
il y a moyen de configurer « intelligemment » le réseau sur le wifi google?
Ou c’est pif-pouf, ça marche et quand ça marche pas, c’est pas documenté et rien n’est faisable?
Et le reste (une autre machine sur le réseau de la freebox), ça peut pinger le .20?
On peut imaginer que le google wifi bloque ça pour des questions de « pseudo-sécurité »…
Regarde Test de Google Wifi : simple et efficace, excessivement
On peut apparemment mettre le google en mode pont. Ca perd quand même certaines fonctionnalités.
Merci, je vais regarder ça, déjà je me rends compte que je peux modifier aucun paramètre de mon wifi depuis l’appli Google home, je comprends pas pourquoi, à refaire, je prendrais pas ces routeurs…
Effectivement. Les tests que j’avais vus ne m’avaient pas convaincu.
Le gros moins, pour moi, c’est l’absence de mesh si tu es en mode access-point. Parce que, sinon, mettre le wifi supplémentaire en point d’accès et garder la box pour le DHCP, ça marche.
Je vois que les routeur Google empêche le ping de l’interface WAN (donc mon ip en 192.168.1.20).
Le ping, c’est une chose mais j’ai quand même l’impression que Home Assistant devrait quand même être capable de communiquer avec mes ampoules connectées au Wifi grâce à l’ajout de la route non ?
Pas forcément… Vu le mode de fonctionnement en routeur qui fait du NAT par défaut vers la sortie, il faut un truc « spécial » pour autoriser les connexions entrantes du réseau .1 vers le réseau .86.
Il semblerait bien que le routeur google ne le fasse pas.
En théorie, c’est « mieux » pour la sécurité. Mais, un vrai routeur te permettrait de le faire. Là, l’idée du bidule, c’est « je branche, ça marche ». Certes mais, pas dans tous les cas. Je crains qu’à part le mettre en mode pont et de perdre le mesh, pas le choix.
Hello et bonne année a tous
Après restauration récente et progressive de mon HA, sans avoir testé nmcli, je me rends compte que je suis malheureusement dans le même cas de figure que @Geoffrey_Guitteny : Nest wifi (similaire à Google wifi) derrière une freebox, HA en wifi, et j’ai checké que ma passerelle était également non « pingable »
Du coup, je serais intéressé par ton retour, est ce que vas te servir des nest wifi uniquement en point d’accès ou est ce que tu vas les remplacer par un autre routeur ? Je crois que je vais m’en séparer pour ma part, car j’aime pas trop la façon de les configurer et en plus ben ça marche pas avec la freebox et home assistant.
Hello @Geoffrey_Guitteny
Non, je garde la fonctionnalité enceinte de la Nest WiFi utile dans une de mes pièces + tous mes devices sont sur le réseau de la Freebox et reconnus par HA.
J’aurais juste voulu rajouter cette enceinte Nest sous HA.
Sinon il y a un github googlewifi qui donne quelques services du sous-réseau.
Parmi les GENERAL DEVICE qui ont un IP4.ROUTE j’ai 1) docker0 (bridge en DEVICE.TYPE) 2) hassio (bridge en DEVICE.TYPE) et 3) lo (loopback en DEVICE.TYPE) ; est-ce 1 parmi ces 3 là ? ou dois-je aller chercher un DEVICE.TYPE ethernet ou wifi ? dans tous les cas, pas de moyen d’appeler un nmcli con edit « Supervisor eth0 » 
L’autre méthode pour trouver la bonne interface si rien n’apparait clairement c’est de chercher celle ou tu vois l’adresse IP de HA (le fameux 192.168.1.x). Je pense que l’interface va être en wlan0 ou wifi
