Migration HA vers un nouveau réseau - RETEX
Introduction
Actuellement, un PC Windows (Dell OptiPlex) avec VMWare Workstation est utilisé pour héberger une VM - Home Assistant.
L'ensemble communique dans le flat network (LAN) de la Box, soit le réseau 192.168.0.0 /24.
L'idée ici est de placer le PC Windows dans un vlan "TEST" en 192.168.1.0 /24. Pour cela, je dois l'intégrer à l’infrastructure suivante:
Ici OPNsense à un rôle de routage principalement, les règles au niveau du firewall seront très permissives, l'objectif ici n'est pas de sécuriser la machine.
Migration du PC Windows
Après avoir configurer le VLAN test et son service DHCP. Je relie le PC au switch. je me connecte à distance via le AP. Je constate que le PC à bien récupéré une IP du VLAN TEST. Je configure de nouveau le réseau afin d'attribuer une IP fixe à la machine en 192.168.1.250/24:
Concernant la VM HA, cette dernière est toujours dans l'ancien réseau:
Je redémarre la VM, elle récupère elle aussi une IP via le DHCP, je parviens à me connecter à HA sans difficulté. On peut voir l'historique des jetons de connexions:
Les intégrations
Le capteur d'humidité en Bluetooth BLE, reste fonctionnel.
Prises connectées Meross
Intégration au réseau wi-fi
Pertes des prises connectées Meross, ces dernières utilisent le cloud Meross et sont intégrées dans l'ancien reseau wi-fi.
Pour cette procédure la géolocalisation est requise, penser à l'activer:
On lance l'application Meross, on sélectionne la prise et on appuie sur :
On peut voir qu'effectivement la prise n'est plus connectée au wifi:
On appuie sur SSID, l'app. déclenche la procédure d'appairage:
"L'appairage" commence:
Il faut indiquer le SSID (ici domolab) et le mot de passe du réseau wi-fi:
La prise est maintenant intégré dans le nouveau réseau wi-fi:
Au niveau de Home Assistant, l'intégration des prises est effectuée via le compte Meross. La procédure est donc transparente pour les automatisations, les entités sont identiques.
Analyse coté Firewall
On passe du LAN de la Box à un vlan derrière OPNsense, voyons les communications sur le réseau domolab.
Ici, on peut voir le dongle bluetooth (192.168.1.102) utilise les ports NetBIOS pour la découverte réseau:
- Port 137 UDP: NetBIOS Name Service (NBNS) - résolution de noms
- Port 138 UDP: NetBIOS Datagram Service - envoi de messages broadcast
Il envoie des requêtes broadcast (vers 192.168.1.255) pour:
- Annoncer sa présence sur le réseau
- Découvrir d'autres appareils compatibles
- Résoudre des noms NetBIOS (ancien protocole Windows principalement)
Au niveau du DHCP, on retrouve les bails pour la VM et la prise Méross:
Lorsque j'utilise l'application je ne vois pas de traffic lié au niveau des logs "Live View" du firewall. Car les connexions sont deja établies :
On constate que la prise Meross (192.168.1.105) se connecte au serveur cloud Meross (99.81.71.200) via HTTPS (443 - connexion chiffrée).
On voit également le trafic retour du cloud vers la prise, cela passe par le NAT.
Ainsi que la découverte locale (mDNS multicast - 224.0.0.251) via le protocole IGMP (Internet Group Management Protocol).
whois de l'ip 99.81.71.200 :
On retrouve le cloud d'Amazon avec les servers AWS.
Update: 21/11/2025Changement du dongle Bluetooth
Remplacement du dongle Bluetooth.
HA OS étant sur une VM (VM Ware), j'utilise le passthrough usb. l’équipement est détecté automatiquement.
Rien de particulier ici. Bonne surprise, la "liaison" Bluetooth BLE avec le capteur de température et d’humidité est "restaurée" automatiquement.
Conclusion et implications de sécurité
Architecture réseau et flux de communication
Cette migration met en évidence un point crucial concernant l'architecture des objets connectés Meross : toutes les communications passent obligatoirement par le cloud Meross hébergé sur AWS.
Le flux de communication est le suivant :
- La prise Meross se connecte au réseau Wi-Fi domestique (SSID : domolab, 192.168.1.0/24)
- Elle établit une connexion HTTPS (port 443) vers le cloud Meross (99.81.71.200 - AWS)
- Home Assistant communique également avec le cloud Meross via l'intégration officielle
- Les commandes transitent par le cloud, même pour un contrôle local
Accès au réseau Wi-Fi domestique
Oui, la prise Meross possède les identifiants complets du réseau Wi-Fi (SSID + mot de passe). Ces informations sont :
- Stockées dans la mémoire interne de la prise
- Utilisées pour établir la connexion au point d'accès
- Potentiellement accessibles par le fabricant via une mise à jour firmware
Point de vigilance
Le fait que la prise connaisse les identifiants Wi-Fi signifie qu'elle a techniquement accès à tout le réseau local. Dans notre cas, elle pourrait théoriquement :
- Scanner les autres appareils du VLAN
- Tenter de communiquer avec d'autres équipements (PC, VM Home Assistant, etc.)
- Exploiter d'éventuelles vulnérabilités sur d'autres appareils du réseau
Implications de sécurité
Dépendance au cloud
- Point de défaillance unique : Si le cloud Meross est indisponible, les prises ne sont plus contrôlables
- Latence : Chaque commande doit faire l'aller-retour vers AWS, même pour un contrôle local
- Confidentialité : Toutes les commandes et états des appareils transitent par les serveurs Meross
- Durée de vie : Si Meross ferme ses serveurs, les appareils deviennent inutilisables
Risques potentiels
- Interception : Bien que chiffré (HTTPS), le trafic passe par un tiers de confiance
- Vulnérabilités firmware : Une faille dans le firmware de la prise pourrait compromettre le réseau
- Accès fabricant : Meross a théoriquement un accès complet aux appareils via le cloud
- Compromission du compte : Si le compte Meross est compromis, un attaquant peut contrôler tous les appareils
Bonnes pratiques recommandées
Pour limiter les risques avec des appareils cloud-dépendants :
- Segmentation réseau : Placer les objets connectés dans un VLAN dédié isolé du reste du réseau
- Règles firewall strictes : Autoriser uniquement le trafic sortant vers le cloud (pas de communication inter-VLAN)
- Mot de passe fort : Utiliser un mot de passe unique et complexe pour le compte Meross
- 2FA : Activer l'authentification à deux facteurs si disponible
- Alternative locale : Privilégier des appareils compatibles avec des protocoles locaux (Zigbee, Z-Wave, Matter) pour réduire la dépendance au cloud
- Veille de sécurité : Surveiller les annonces de vulnérabilités concernant Meross