Les appareils domotiques disparaissent quand le téléphone se connecte au VPN

La lampe fonctionne depuis son application à la maison, cesse de répondre à l’instant où le téléphone se connecte au VPN et revient quand le tunnel tombe. Rien ne cloche avec la lampe. Le téléphone envoie désormais une partie ou la totalité de son trafic par un autre chemin, et l’application domotique utilise peut-être une méthode de découverte que ce chemin ne transporte pas. Identifiez l’opération en échec avant de réinitialiser quoi que ce soit.

Deux chemins, et le tunnel n’en touche qu’un

Une commande domotique peut voyager de deux façons. Elle peut aller directement vers un appareil proche par le réseau local, ou passer par un service cloud du fabricant qui atteint l’appareil par sa propre connexion. Le VPN du téléphone change le chemin du téléphone ; il ne déplace pas le hub, l’ampoule ou l’enceinte dans le tunnel. La configuration, le contrôle et les notifications peuvent chacun utiliser un mécanisme différent, ce qui explique qu’une panne partielle paraisse incohérente.

Le premier diagnostic n’est donc pas les réglages du VPN mais l’opération en échec. L’échec simultané de la configuration locale et du contrôle cloud pointe ailleurs entièrement.

Testez la découverte locale séparément

La découverte locale repose généralement sur le multicast lien-local, qu’un tunnel routé n’étend pas. Vérifiez si le nom se résout et si l’adresse est joignable sans l’application.

avahi-resolve -n lamp.local
ip route get 192.168.1.50
ping -c 3 192.168.1.50

L’appel au résolveur montre si mDNS répond, la recherche de route montre quelle interface transporterait le trafic vers l’appareil, et le ping montre si le chemin local fonctionne du tout. Une route qui envoie le sous-réseau de l’appareil dans le tunnel explique pourquoi la découverte échoue alors qu’Internet fonctionne encore. Un nom résolu sans réponse indique une isolation au point d’accès, pas au VPN. Remplacez le nom et l’adresse de l’exemple par des valeurs de votre propre réseau.

Si seul le chemin cloud se casse

Si les commandes locales fonctionnent et que les distantes non, le tunnel du téléphone peut interférer avec la session cloud plutôt qu’avec la découverte. Une nouvelle adresse de sortie peut déclencher la vérification du compte, casser une session épinglée ou échouer à un contrôle régional. Comparez une opération prise en charge en laissant l’application et le réseau inchangés par ailleurs, et conservez la validation des certificats. Le flux de récupération du service est le bon outil ; désactiver les contrôles de sécurité pour qu’une connexion passe ne l’est pas.

Vérifiez aussi le DNS, car l’application peut résoudre les points de terminaison du fabricant vers un nom d’hôte qui ne répond correctement que depuis la région attendue.

L’accès distant est une troisième conception

Atteindre les appareils de la maison depuis l’extérieur est un projet distinct du routage d’un téléphone par un VPN. Il exige une passerelle privée, des routes définies et des règles d’accès étroites, et il ne se crée pas en s’abonnant à un VPN avec sortie Internet. Une redirection de ports étendue pour compenser un problème de routage inexpliqué expose des appareils qui n’ont jamais été conçus pour cela. Testez la découverte, le contrôle local et le contrôle cloud un à la fois après chaque changement. Si vous avez ajouté une exception de réseau local pour l’application, confirmez que le reste du trafic du téléphone suit toujours le tunnel voulu.

Notez quel chemin a échoué et quel changement l’a corrigé. Les pannes domotiques sont généralement une limite de routage ou d’autorisations, et le prochain appareil rencontrera la même.