Home Assistant & Aqara Hub M3

Produit en cours de test et article en cours d'écriture.

Dans la série des clic compulsifs d'un soir, voici le dernier Hub d'Aqara, le M3. Je parle de clic car je ne reçoit pas ces produits d'un quelconque service de presse qui me presserait d'être gentil, mais je les achètes, quitte parfois à les retourner à ce cher Amazon. Et en plus, contrairement à pas mal de sites "pute à clics", je les teste vraiment.

Ca vaut 130 € et il y a un code promo de 20% qui traine.

Ce produit offre de grandes promesses sur papier glacé et il est même annoncé officiellement compatible avec Home Assistant. Mais la réalité est un peu différente...

  • Connectivité POE : la promesse est tenue et c'est bien pratique, ça permet de le poser n'importe ou sans un horrible chargeur et si le switch est secouru ça sera sans coupure électrique.
  • Du WI-FI bi bande : C'est la moindre des choses. WPA3 inside.
  • Alimentation USB C : plus pratique, et peu énergivore (1.6 W mesurés).
  • Zigbee : Ne vois y trompez pas, si la plaquette annonce bien le support de 127 devices, il s'agit de devices Aqara. N'espérez donc pas remplacer votre passerelle Zigbee habituelle. Il n'en reste pas moins que c'est intéressant, certains devices Aqara n'étant pas tout à fait à la norme Zigbee 3, ils seront mieux gérés ici (actuellement je les gère avec cette passerelle peu couteuse qui fonctionne très bien avec cette intégration).
  • Bluetooth : aucun device ne remonte (sondes Xiaomi par exemple).
  • IR : Ca fonctionne mais la fonctionnalité reste sur le Hub, l'intérêt aurait été que ça remonte sur Home Assistant via Matter ou HK.
  • HomeKit : Les devices reconnus remontent bien dans Home Assistant et probablement sur les produits Apple.
  • Matter & Thread : Si j'arrive bien à faire remonter dans Home Assistant les devices Zigbee, je n'ai pas réussit à associer de device Matter (testé avec une Nuki 4 et un capteur d'ouverture Aqara P2, ce qui est un comble).

Conclusion (temporaire)

Une fois de plus dans une industrie qui va très vite on se retrouve avec un hardware de bonne facture avec du software à la traine.

Je ne pense pas que cette passerelle acceptera des devices Zigbee d'autres marques, sauf peut être des accords avec des leaders genre Philips Hue, mais il ne faut pas trop rêver. Par contre on peu penser qu'ils termineront la partie Matter et espérer que les remontées vers Home Assistant ne se limitent pas au strict minimum.

Pour l'instant il est donc urgent d'attendre...

EDIT 16/06/2024

Comme souvent les pas mal de sites ont encensé le communiqué de presse de ce produit sans vraiment le tester. Depuis mon premier test il n'y a pas d'évolution coté firmware. Hier soir j'ai ajouté le TVOC Aqara pour voir, hélas ça ne remonte pas en Matter vers HA, heureusement qu'il y a HomeKit

 

Home Assistant & WebRTC

Comme d'aucuns ont pu le remarquer, le flux des caméras sous Home Assistant à tendance parfois à laguer et ne pas être très réactif. On pourrait penser que ça vient de la qualité des caméras, pourtant j'utilise un système Unifi Protect très bien intégré à Home Assistant et parfois j'ai l'impression d'avoir les mêmes lags que sur une chinoiserie achetée pas cher sur Ali ! En fait Home Assistant utilise le protocole RSTP afin de communiquer avec les caméras ou dans mon cas le NVR et en l'état le résultat n'est pas à la hauteur de ce que j'obtiens avec l'appli Unifi Protect. Sauf que je veux avoir ça dans HA car ça m'apporte plein d'options intéressantes. Voir la version simple à la fin !

Afin de contourner ce problème il y a WebRTC que les développeurs connaissent bien. Et l'un d'eux, Alex, qui est également l'auteur d'autres très bonnes intégration, a développé Go2RTC qui va de façon transparente nous permettre d'utiliser WebRTC pour visualiser nos caméras.

J'avais déjà lu quelques sujets sur WebRTC et HA, mais ce qui m'a donné subitement envie de l'intégrer est la vidéo de ce jeune homme :

Ceux qui me suivent savent que je ne suis pas fan des tutoriaux vidéo, surement une question de génération (je suis vieux !), mais passer du temps à faire play / pause m'agace et me fait perdre du temps. Ceci étant il explique clairement l'essentiel que je vais reprendre ici en l'adaptant à l'infrastructure Unifi Protect.

Le problème est documenté et sera probablement corrigé dans une prochaine version de Go2RTC, en attendant il faut le contourner. L'intégration Unifi Protect intègre les caméras en se basant sur le flux RSTPS, ce qui va nous donner ça :

"url": "rtsps://192.168.10.1:7441/2sgdfdsgdfgf3DNu5F?enableSrtp"

Sauf que Go2RTC ne supporte pas SRTP, et donc c'est le bug ! La bonne URL est donc celle ci :

"url": "rtsps://192.168.10.1:7441/2sgdfdsgdfgf3DNu5F"

Je n'ai pas trop cherché, mais je n'ai pas trouvé ou faire la modification et comme Go2RTC recrée les liens lors de chaque démarrage, j'ai contourné le problème en créant dans HA des caméras génériques basées sur la bonne URL (on pense à décocher la vérification du certificat car il est généralement bidon et on n'entre pas d'authentification puisque le lien est open bar).

On répète ça sur toutes les caméras et on pense à les renommer proprement.

L'étape suivant va consister à installer l'addon Go2RTC. Pour ça on va dans les addons HA et on ajoute l'adresse du dépôt idoine dans les sources et on installe :

https://github.com/AlexxIT/hassio-addons

Une fois cet addon installé et lancé on va ajouter l'intégration RTSPtoWebRTC à Home Assistant que l'on fera pointer sur :

http://localhost:1984

Et c'est presque tout, miracle vos caméras sont maintenant bien plus réactives !

A ce stade les barbus vont me dire, oui, mais tous ces ports passent bien en local, mais depuis l'extérieur ? Ouvrir des ports n'étant pas conseillé (j'utilise Nabu Casa ou Cloudflared), on va tuneliser en utilisant le service Ngrok sur lequel on va devoir créer un compte. Une fois le compte créé et validé , on récupère le token d'authentification que l'on vient coller dans la console de Go2RTC :

ngrok:
  command: ngrok tcp 8555 --authtoken <token>
   
webrtc:
  listen: ":8555" # external TCP/UDP port
  candidates:
    - stun:8555

Ensuite on va configurer l'option dans l'intégration RTSPtoWebRTC :

stun.l.google.com:19302

Voilà, c'est fini. La suite de la vidéo nous parle de Frigate et Fully Kiosk. Deux sujets que j'aborderais une autre fois.

Version simple

A la base je voulais juste un affichage plus fluide de mes caméras et j'ai installé toute cette usine qui a certainement un intérêt dans un contexte Frigate. Mais si l'on souhaite uniquement un peu de fluidité dans l'affichage et profiter de WebRTC simplement, et bien il y a plus simple.

Dans ce cas le seul composant à installer est l'intégration WebRTC Camera depuis HACS et de le configurer en l'ajoutant aux intégrations.

Ensuite on peu ajouter une carte Lovelace très simplement :

type: 'custom:webrtc-camera'
url: 'rtspx://192.168.6.1:7441/3jurvIekaWvpee222'

Ou aller plus loin avec quelques option :

type: custom:webrtc-camera
streams:
- url: ''
- url: 'rtspx://192.168.6.1:7441/3jurvIekaWee222'
shortcuts:
  - name: Privacy
    icon: mdi:cctv-off
    service: switch.toggle
    service_data:
      entity_id: switch.terrasse_nord_privacy_mode
ui: true
poster: https://demo.home-assistant.io/stub_config/bedroom.png
muted: true

La doc est très complète et ça remplacera efficacement la carte Picture Glance pour afficher les caméras. Ca fonctionne mais ça reste un peu pauvre, alors même si vous n'utilisez pas Frigate rien n'empêche d'utiliser leur carte qui est bien plus riche et permettra par exemple de caster le rendu vers un téléviseur...

IPBan pour Windows Serveur.

Même s'il est préférable (et je vous le recommande) de ne pas exposer directement des serveurs sur internet, l'idéal est faire ça avec un reverse proxy, on n'a parfois pas le choix. Le confinement l'a démontré ou en urgence pas mal d'entreprises n'ont eu d'autres choix que d'exposer à la va-vite des serveurs RDP sur Internet à des fin de télétravail. La moindre des chose serait d'utiliser un VPN ou une passerelle RDP comme Guacamole, mais si ce n'est pas possible il faut sécuriser au maximum, RDP, pour ne citer que lui étant très vulnérable.

Je ne vais pas parler de ce qui est à faire sous Linux mais pour les serveurs Windows.

On a deux étapes :

  • Le firewall intégré
  • La protection des applications

Le firewall

Contrairement à une légende urbaine, le firewall intégré à Windows est solide, à condition toutefois de le configurer correctement et de n'exposer que ce qui est réellement utile.

Il y a 3 catégorie auxquelles on affecte les règles : Public, Private et Domain (équivalent Private si on est connecté à un domaine Active Directory).

Si on expose un Windows sur Internet la première chose à considérer est que l'interface exposée doit se trouver en mode Public :

PS C:\Users\Administrator> Get-NetConnectionProfile

Name             : Network 5
InterfaceAlias   : WAN
InterfaceIndex   : 3
NetworkCategory  : Private
IPv4Connectivity : Internet
IPv6Connectivity : Internet

Si ce n'est pas le cas, comme dans cet exemple on ajuste avec :

PS C:\> Set-NetConnectionProfile -InterfaceIndex 3 -NetworkCategory Public

Cette considération étant prise en compte, de base très peu de choses sont exposées en Public et on pourra ouvrir un port pour laisser passer un service. Et idéalement s'il s'agit de RDP on va restreindre cette exposition aux IP des clients... Idéalement, car dans la pratique peu de client disposent d'IP fixes et certains services doivent êtres accessibles de façon universelle.

L'interface du firewall de Windows datant du siècle dernier on pourra avantageusement se servir de eu se servir de WFC (récemment acquis par Malwarebytes) afin de le gérer plus facilement.

A ce stade on teste avec avec un scan externe afin de s'assurer que seul le ports utiles sont ouverts (Advanced port Scanner ou NMap par exemple)

Mails il va donc falloir renforcer cette sécurité par d'autres moyens !

Sous Windows il existe une seconde couche de défense moins connue : WFP (Windows Filtering Platform). Si WFP peut être très efficace, sa configuration est délicate et se passe en PowerShell, ce qui la rend peu accessible. Et c'est ici que va rentrer en action IPBan qui un peu à la manière de Fail2ban disponible sous Linux va nous permettre d'ajouter une ligne de défense supplémentaire.

IPBan

D'abord une petite précision, il existe deux versions d'IPBan :

  • Une version gratuite sans interface qui travaille uniquement avec un fichier de configuration XML qui donne mal au crane et surtout qui s'appuie uniquement sur le firewall de Windows.
  • Une version pro et payante qui dispose d'une interface et s'appuie sur WFP pour plus de réactivité. Cette interface peut être locale ou centralisée afin de gérer plusieurs serveurs.

C'est la version Pro à laquelle on va s'intéresser ici. Son cout annuel n'est pas prohibitif ($ 29.00 pour un serveur et $ 99.00 pour tous vos serveurs) si on le compare à d'autres produits qui en font moins pour bien plus cher. Cerise sur la gâteau, le support par mail ou sur Discord est vraiment très réactif !

La fonction de base d'IPBan est d'interdire l'accès à une IP après x tentatives infructueuses de connexion. 

De base il va surveiller les applications suivantes grâce aux Events de Windows, mais égaiement aux logs des applications :

  • OpenSSH
  • Microsoft Exchange
  • SmarterMail
  • MailEnable
  • Apache Tomcat
  • RDP
  • Microsoft SQL
  • MySQL
  • Postgre SQL
  • PhpMyAdmin
  • VNC
  • RRAS
  • SVN

Mais ce n'est pas limitatif et l'administrateur peut également ajouter ses propres surveillances en lui demandant d'aller scanner events et logs. Le GitHub de l'éditeur héberge d'ailleurs un certain nombre d'intégrations personnalisée qui vous faciliteront la tache, en voici un exemple pour surveiller le serveur FTP de Filezilla :

<LogFile>
	<Source>Filezilla</Source>
	<PathAndMask>C:\Program Files (x86)\FileZilla Server\Logs</PathAndMask>
	<FailedLoginRegex>
		<![CDATA[
			(?<timestamp>[^\s]+)\s.*\s\[FTP\sSession\s[0-9]+\s(?<ipaddress>[^\]]+)\]\sUSER\s(?<username>[^\n]+)\n.*\sspecify\sthe\spassword[^\n]*\n.*\sPASS\s[^\n]*\n.*\s(?<log>Login\s(?:or\spassword\s)?incorrect)[^\n]*
		]]>
	</FailedLoginRegex>
	<FailedLoginRegexTimestampFormat></FailedLoginRegexTimestampFormat>
	<SuccessfulLoginRegex>
		<![CDATA[
			(?<timestamp>[^\s]+)\s.*\s\[FTP\sSession\s[0-9]+\s(?<ipaddress>[^\]]+)\]\sPASS\s[^\n]*\n.*\[FTP\sSession\s[0-9]+\s[^\s]+\s(?<username>[^\]]+)\].*Login\ssuccessful[^\n]*
		]]>
	</SuccessfulLoginRegex>
	<SuccessfulLoginRegexTimestampFormat></SuccessfulLoginRegexTimestampFormat>
	<PlatformRegex>Windows</PlatformRegex>
	<PingInterval>10000</PingInterval>
	<MaxFileSize>0</MaxFileSize>
	<FailedLoginThreshold>0</FailedLoginThreshold>
</LogFile>

Au delà de ce blocage d'IP via WFP, il est également possible de :

  • Visualiser facilement les connections valides
  • Gérer des listes blanches et noires
  • Vous notifier
  • Bloquer ou autoriser les connections en provenance de certains pays (GeoIP)
  • Bloquer certains ASN
  • Bloquer des listes d'IP de réputation douteuse en s'abonant à des listes partagées.
  • Se synchroniser avec le reverse proxy de Cloudflare
  • ...

En conclusion c'est l'outil indispensable pour qui doit exposer un serveur directement sur Internet !

IPv6 @ Scaleway...

Depuis plus de 20 ans tout le monde parle d'IPv6, mais dans la pratique ce n'est pas encore l'euphorie au niveau de l'adoption. En France, une fois n'es pas coutume, on est un peu en avance, Free en tête qui a passé tout son réseau fibre en IPv6. En fait du 4rd pleinement documenté dans le RFC 7600. Dans la pratique c'est du tunneling (donc 2 clients qui discutent en IPv4 le font par un tunnel direct au dessus de leur IPv6, ca ne passe par une passerelle).  Par contre à ce que j'ai pu lire la sortie IPv4 vers le reste du monde ce fait via des 'Border Relay 4rd' ou du NAT64+. Et là si ces équipement ne sont pas suffisamment dimensionnés ça peut créer un goulot d'étranglement.

Il y a quelques temps je me suis aperçu que l'un de nos serveurs hébergé chez Scaleway présentait en soirée une importance latence, voire des lags pour les clients Free, ce qui est un comble car Free et Scaleway font partie de la même boutique !

Il semble donc qu'il y ait un entonnoir au niveau de la passerelle de sortie vers l'IPv6. Je ne connais pas les détails de l'infrastructure Free, mais je me suis dit qu'en rendant mon serveur accessible en IPv6 je pourrais contourner le problème, et que de toutes façons il était temps que je passe ma part d'IPv6 !

Sauf que ce n'est pas si simple, d'une par je n'ai jamais pratiqué, et d'autre par la documentation fournie par Scaleway est obsolète.

Chez Scaleway j'ai deux types d'approche, des serveurs loués (Dédibox) et une infra avec les propres serveurs installés dans une baie louée (Dédirack). Mon serveur étant une VM sous Windows 2019 sur un serveur Dédibox je me suis basé sur la documentation officielle qui fait référence à la fourniture d'un DUID (sur la console Online) après avoir demandé un bloc IPv6 et passé le serveur en SLAAC. Au vu des captures d'écrans cette doc doit dater de l'époque Windows NT (siècle dernier), j'espère qu'ils vont  la mettre à jour, aussi je mets les copies d'écran de la version actuelle ici : 1 | 2 .

Cette documentation mets en avant l'utilisation du DUID en modifiant une clé de registre de Windows. Hors changer le DUID dans l'implémentation Windows est devenu impossible comme l’expliquent ces deux articles parmi tant d’autres 1 | 2.

Le DUID change maintenant à chaque reboot en se basant sur l'adresse MAC de l’interface. C'est maintenant le comportement normal et attendu. Cette doc n'a donc plus lieu d'être dans sa version actuelle !

En fait pour obtenir une IPv6 sous Windows il n'y a rien de plus à faire que d'activer le stack IPv6 de Windows par défaut (client DHCP) (après avoir demandé un bloc IPv6 /48). Et c'est tout, l'obtention de l'IPv6 se fait via le serveur DHCPv6 de l'infrastructure Scaleway (il est également possible de renseigner une adresse prise dans le bloc).

Alors, pourquoi toute cette galère depuis des mois ?

Je me suis obstiné sur l'utilisation du DUID que la documentation mets en avant ! Normal j'ai appris à lire. Et d’autres sites y font référence. Ensuite il se trouve que cette machine avait un firewall plutôt blindé, et comme elle n'utilisait pas d'IPv6 auparavant tous les entrées Core Networking IPv6 étaient désactivées, donc les échanges avec le DHCPv6 et RA ne pouvaient pas se faire correctement. Je les ai réactivés dès lors que j’ai compris que la première option était obsolète.

A aucun moment le support Scaleway n'a su me dire qu'il ne fallait pas poursuivre dans la voie du DUID, ce qui aurait évité une perte de temps de toutes parts ! Le ticket de support n’est surement pas remonté auprès des bonnes personne et la culture Windows pas très présente, et meme si je les comprends il est impossible aujourd'hui d'ignorer le monde Microsoft !

Par contre de base Windows génère une IPv6 aléatoire, ce qui peut être utile sur un client mais gênante sur un serveur, on désactive en PS:

  Set-NetIPv6Protocol -RandomizeIdentifiers Disabled

Ou :

  netsh interface ipv6 set global randomizeidentifiers=disabled store=active
  netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
  netsh interface ipv6 set privacy state=disabled store=active
  netsh interface ipv6 set privacy state=disabled store=persistent

On peut également désactiver l'utilisation d'une IPv6 temporaire :

  Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

Voilà, en espérant que Scaleway clarifie son article car si le passage de l'utilisation d'un DUID à du full DHCPv6 facilite largement la tâche, encore faut-il l'expliquer ! Je n'ai pas testé sous Linux, mais sous pfsense ou OPNsense la procédure est relativement identique.

Et dans un Dédirack ?

On aurait pu penser au vu de la console Online qui affiche sur une même pages les infos réseau de mon Dédirack (IPv4) et de mon bloc IPv6 /48 que ce bloc soit également utilisable dans la baie Dédirack. Mais non, après avoir lourdement insisté auprès du support j'ai enfin eu la réponse :

Pour faire de l'IPv6 dans un Dédirack (offre housing de Scaleway), il faut demander au support un bloc /48 et ensuite le gérer en statique à sa convenance. Ca ne s'invente pas.

Et ça fonctionne ? Et bien non, car il aura fallu plusieurs jours et plusieurs personnes pour que l'on s'aperçoive que quelqu'un ne sais pas faire de copié/collé chez eux (ou un farceur ?), et que dans le bloc /48 que l'on m'a fourni il y avait un C00D qu'il fallait lire C00C !

Et sur l'offre Elastic Metal ?

Je n'ai pas encore testé, mais j'y ai installé un serveur ESXi et je crois savoir que la procédure est encore différente.

Sources et liens

 

RustDesk

Au fil des ans TeamViewer s’est imposé dans l'IT. Au départ pseudo gratuit ce produit offre maintenant de plus en plus de fonctionnalités (souvent inutiles) et son cout augmente d’années en années. On pourrait imaginer le remplacer par AnyDesk, mais hélas leur politique est quasiment identique et ce serait reculer pour mieux sauter.

Pendant le confinement certains en ont eu assez de se faire “raquetter”. Si le mot vous parait fort, constatez simplement les augmentations successives dont la dernière de 20% que rien ne justifie à mes yeux, l'éditeur se justifiant quant à lui par l'ajout de fonctionnalités qui me sont inutiles. Entendons nous bien, tout a un prix et tout travail ou service mérite une rémunération, mais tout doit rester dans la nuance, même quand on se retrouve dans une position de domination, ce qui est d'ailleurs le cas pour d'autres, comme Microsoft et ses dernières augmentations au niveau 365 ou Azure...

Bref, c'est donc ainsi qu'une petite équipe de développeurs a créé RustDesk. RustDesk offre les mêmes fonctionnalités de base dans le cadre de l’open source. Je teste Rustdesk depuis près d’un an et j’estime que l’heure est venue de franchir le pas.

RustDesk est disponible sous différentes distributions Linux, MacOS, Windows, Android et IOS.

Il existe plusieurs façons d’utiliser RustDesk :

Version isolée sans serveur

La plus simple et totalement gratuite, mais qui présente quelques inconvénients :

  • Pas de chiffrement, cela veut dire que toutes les infos circulent en clair (pas sécure pour les clients, mauvaise pratique).
  • Lenteurs possibles car ça utilise les serveurs publics, ce qui reste limité.
  • Pas de carnet d’adresse synchronisé entre les devices clients. Et là ça bloque car comme beaucoup de monde j'utilise un PC fixe au bureau et un laptop quand je me déplace, sur lequel je souhaite retrouver mon environnement de travail. Ils auraient pu envisager une synchronisation de type "drive", mais cela aurait posé des questions de sécurité car en plus de synchroniser les identifiants il faut stocker des mots de passe.

Version gratuite avec serveur

Toujours gratuit (en dehors du cout d'un serveur VPS (qui peut être mutualisé)), et on résous la question du chiffrement :

  • Le serveur sert de relais (amélioration de la vitesse) et de serveur de chiffrement afin de sécuriser les liens.

Version payante avec serveur privé

La totale qui va couter quelques euros (10 € / mois pour deux utilisateurs, ou 20 € /mois pour 20 utilisateurs + le serveur), mais à mon sens indispensable dans un cadre professionnel

  • Le serveur offre une console qui permet de lister les clients installés et éventuellement les partager
    • Seul l’admin peut activer les partages à ce stade. Partager fait remonter les ID pour un autre utilisateur, mais le mot de passe associé au device reste nécessaire.
  • Avoir des logs, qui se connecte à quoi (dispo pour chaque utilisateur), transferts de fichiers.
  • Changer l’ID d’un client
  • Utiliser un carnet d’adresse qui sera synchronisé entre les clients de chaque utilisateur, mais non accessible à l’admin.
  • Appliquer des stratégies
  • Et d'autres fonctionnalités à venir car le projet est en constante évolution....

Il n'existe pour l'instant pas de version Cloud et je n'ai pas le sentiment que ce soit dans l'ordre des priorités de l'équipe.

Installation

Je me place ici dans le cadre de la version serveur après avoir acquis une licence.

L'installation du serveur se fait sous Linux ou dans un container Docker. La procédure est décrite ici et je ne vais pas la reprendre. J'ai choisit Docker pour la facilité d'un Compose...

Coté client, contrairement à TeamViewer qui fonctionne uniquement avec une infrastructure cloud, RustDesk fonctionne avec une infrastructure privée si l’on veut disposer de toutes ses fonctionnalités. Quand on installe le client il va donc falloir configurer les informations liées au serveur. Ce device sera alors uniquement accessible par des clients également configurés pour ce serveur (tout au moins pour l’instant car il y a des évolutions en cours).

Pour configurer le client afin qu’il soit reconnu par le serveur on a plusieurs solutions :

  • Soit on installe l’exe normalement et on copie la config dans ID / Relay server
Qfi0TWlxGWrUdfqdsfVENxxxxxxxxxxxxxxxxxxxxxxxqfsqdfN3boJye

  • Soit on renomme l’exe d’installation afin d’y intégrer la clé, ce qui va donner quelque chose du genre:
rustdesk-licensed-Qfi0TWlxGWrUkR5Vxxxxxxxdfsdfsdfsdfye.exe
  • Soit on crée un script de déploiement et ainsi appliquer la configuration après l’installation dans le cadre d’un script PowerShell, on dispose alors de ces trois commandes, et on verra plus bas ce à quoi peut ressembler un script de déploiement  :

Se connecter

En général quand on utilise ce genre de produit, souvent pour de l'assistance client ou de la gestion de serveurs, il y a deux types d'installations :

  • Le device client, le mien, sur lequel après avoir configuré le serveur (chapitre précédent), je vais me connecter avec l'identifiant fournit par l'administrateur du serveur : 
  • Le device distant auquel on va affecter (ou pas) un utilisateur

Affecter un device à un utilisateur

Si on affecte un device à un utilisateur, cet utilisateur (et uniquement lui) verra ce device distant monter dans son logiciel client. Il pourra également l’ajouter à son carnet d’adresse personnel. Si on ne l'affecte pas, tous les utilisateurs le verront, pourront l'ajouter à leur carnet d'adresse et s'y connecter (sous réserve de disposer du mot de passe préalablement défini).

Des fonctionnalités de groupe et de partage de groupe sont également prévues. Il est ainsi possible de partager les devises affectés à un groupe à un autre utilisateur. A noter que pour l'instant groupe = utilisateur et que l'on ne peut pas directement affecter des devices à un groupe isolé. La solution consiste donc à créer un utilisateur virtuel qui partagera ses devices avec d'autres utilisateurs. Par exemple j'ai créé un utilisateur virtuel Société A qui partage ses devices avec les deux personnes chargés de la maintenance de Société A. Ca consomme une licence utilisateur mais je n'ai pas trouvé mieux pour l'instant.

Il existe plusieurs façons pour y parvenir :

  • En se connectant avec son user/password (mais c’est une très mauvaise idée que de faire ça sur le PC d’un client)
  • En l’associant dans l’interface d’administrateur (mais seul l’admin peut le faire)
  • En utilisant l’API sur le client dans le cadre d’un déploiement vie un script

Pour ça il faut un token. Les tokens qui permettent l’accès à l’API sont délivrés par l’admin.

PS C:\Program Files\RustDesk>.\RustDesk.exe  –assign –token "rapi_xxxxxxxxdyw==" –user_name “admin” | more

La console

Chaque utilisateur peut voir la liste de ses devices, l’état de la connexion ainsi que diverses infos (par exemple :

ip: 82.65.xxx.xxx;
version: 1.2.3;
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2.53GHz, 4/4 cores; mem: 8GB

Un log est également disponible tant pour les connections que pour les transferts de fichiers. Cette console est destinée à évoluer pour plus de fonctionnalités.

L'administrateur peut quant à lui, outre gérer utilisateurs et devices, affecter des stratégies aux utilisateurs et devices :

Script PowerShell d’installation

On ne dispose pour l'instant pas de .msi et ce script est un peu simpliste (il en existe pour d'autres O/S ici). Pour faire simple je conseille d’ouvrir une session PS en mode admin. Mais il est également possible de faire une élévation dans le script (voir à la fin). Pour l’instant attention à indiquer la version de l'exe sur la bonne ligne…

Version client isolé

$rustdesk_pw="mot_de_passe_permanent"
$ErrorActionPreference= 'silentlycontinue'

################################### Please Do Not Edit Below This Line #########################################

If (!(Test-Path C:\Temp))
{
    New-Item -ItemType Directory -Force -Path C:\Temp > null
}

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

cd C:\Temp
Invoke-WebRequest "https://github.com/rustdesk/rustdesk/releases/download/1.2.3/rustdesk-1.2.3-x86_64.exe" -Outfile "rustdesk.exe"
Start-Process .\rustdesk.exe --silent-install # -wait
$ServiceName = 'Rustdesk'
$arrService = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue
if ($arrService -eq $null)
{
    Start-Sleep -seconds 20
}
cd $env:ProgramFiles\RustDesk\
$rustdesk_id = (.\RustDesk.exe --get-id | out-host)

.\RustDesk.exe --password $rustdesk_pw | out-host

Version "mes machines"

################################# VARIABLES #######################################
$rustdesk_pw="PasswordPermanent"  # Celui du device distant
$rustdesk_token="MonTocken"
$rustdesk_cfg="Qfi0TWlxxxxxxxxxxxxxxxxxxxxxxxxxxN3boJye" # Clé de configuration
$ErrorActionPreference= 'silentlycontinue'
################################### SCRIPT ########################################

If (!(Test-Path C:\Temp))
{
    New-Item -ItemType Directory -Force -Path C:\Temp > null
}
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
cd C:\Temp
Invoke-WebRequest "https://github.com/rustdesk/rustdesk/releases/download/1.2.3/rustdesk-1.2.3-x86_64.exe" -Outfile "rustdesk.exe" # Changer la version le cas échéant

Start-Process .\rustdesk.exe --silent-install # -wait
$ServiceName = 'Rustdesk'
$arrService = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue

if ($arrService -eq $null)
{
    Start-Sleep -seconds 20
}
cd $env:ProgramFiles\RustDesk\
$rustdesk_id = (.\RustDesk.exe --get-id | out-host)

.\RustDesk.exe --config $rustdesk_cfg | out-host
.\RustDesk.exe --password $rustdesk_pw | out-host
Start-Sleep -Seconds 5
.\RustDesk.exe --assign --token $rustdesk_token --user_name manu | out-host

Elévation (le cas échéant à ajouter au début du script)

if (-Not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    if ([int](Get-CimInstance -Class Win32_OperatingSystem | Select-Object -ExpandProperty BuildNumber) -ge 6000) {
        Start-Process PowerShell -Verb RunAs -ArgumentList "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`"";
        Exit;
    }
}

Le cas des serveurs Windows et du RDP

Si on installe RustDesk sur un serveur Windows va se retrouver face à deux possibilités, activer ou pas le partage de session RDP (une problématique identique existe avec TeamViewer qui a choisit de fournir deux ID, cela concerne principalement les administrateurs de serveurs, qu’ils soient premise ou cloud) :

  • Non activé : RustDesk va proposer une ouverture de session, il est possible d’enregistrer le mot de passe dans le client, et cette ouverture de session déconnectera l’éventuel utilisateur connecté en RDP.
  • Activé : Dans ce cas RustDesk partage la connexion RDP active et si on déconnecte la session RDP ça déconnecte la session RustDesk (qui peut toutefois se reconnecter s’il dispose des identifiants Windows.
    • Il existe toutefois un problème, dans ce mode rien ne permet actuellement de choisir la session sur laquelle va s’opérer le partage, il y a donc un risque de se concerter sur la session d’un utilisateur actif dans le cas d’un serveur de bureaux virtuels. (ticket ouvert en cours).

Conclusion

RustDesk est constante évolution et j'y reviendrait certainement ici. En attendant j'ai déployé une trentaine de devices sans observer de problèmes particulier si je compare à mon classique TeamViewer.

EDIT 10/12/2023

J'avais demandé une option afin de simplifier la mise en œuvre et ne pas associer des installations distantes et non contrôlées de façon permanentent à mon serveur. Sur le client on installe simplement Rustdesk de façon interactive, ou on l'installer avec le script simplifié qui permet seulement de définir un mot de passe permanent.

Il est maintenait possible, dans une infrastructure avec un serveur Pro de se connecter à un client isolé tout en bénéficiant du chiffrage du serveur en saisissant son ID@public :

Ainsi la machine sera contrôlée et chiffrée de façon temporaire par le serveur, sans pour autant l'enregistrer de faon permanente dans celui ci. Il sera toutefois possible de l'ajouter à son carnet d'adresse et de lui affecter une étiquette, mais pas de la partager avec d'autres utilisateurs du serveur. Autre avantage, s'autres intervenant pourront se connecter à cette machine, même s'ils ne fort pas partie du périmètre du serveur.

 

 

RDP & Guacamole

Et non, je ne suis hélas pas parti en vacances au Mexique déguster du guacamole arrosé de téquila ! Mais j'ai trouvé la solution que je cherchait depuis longtemps pour sécuriser les accès RDP. Comme chacun le sait il n'est vraiment pas conseillé de laisser ouvert sur internet le port RDP qui est plutôt vulnérable. Hélas pensant le confinement beaucoup de clients ont du mettre en place des solutions dans l'urgence et dans bien des cas il était impossible de verrouiller au minimum ce port sur une IP fixe....

Bien sur Microsoft a une solution (RDP Gateway), couteuse et complexe, donc pas adaptée à de petites entreprises dont les couts IT explosent déjà. Je restait donc en éveil à la recherche d'une solution quand je suis tombé sur le projet open-source Guacamole en HTML5. Et surprise, celui ci fonctionne vraiment bien ! Le principe est simple et reprends celui des autres projets, une machine va servir de proxy afin d'exposer le RDP (mais aussi SSH, Telnet et VNC).

Installation

S'il est possible d'installer Guacamole en natif comme c'est très bien expliqué ici, après avoir testé différentes options, par facilité je vais faire ça sous Docker en utilisant ce projet.

Je vais donc monter une VM Linux Ubuntu et y configurer Docker et Docker Compose. Pour cette partie je vous laisse chercher, d'autres expliquent mieux que moi.

Pour déployer Guacamole on a besoin de 3 services :

  • GUACD : Le cœur de Guacamole qui va servir à connecter les différents services (RDP, SSH, etc...)
  • PostgreSQL : Une base de donnée (qui peut être également MySQL ou encore l'utilisation d'une base externe)
  • Guacamole : Le composant FrontEnd qui va gérer les connections, les services et les utilisateurs.

Docker Compose

L'auteur de l'intégration a eu la bonne idée de nous fournir un script d'installation. On va donc l'utiliser et on se servira de Docker Compose plus tard afin d'ajuster la configuration.

sudo git clone "https://github.com/boschkundendienst/guacamole-docker-compose.git"
cd guacamole-docker-compose
./prepare.sh
sudo docker-compose up -d

Si tout se passe bien on peut se connecter sur https://ip_serveur:8443/guacamole. Le nom d'utilisateur par défaut est guacadmin avec mot de passe guacadmin. La première chose à faire est bien sur de le changer.

On pourra facilement configurer un serveur RDP et s'y connecter pour avoir les premières impressions. Je trouve que le rendu RDP en HTML5 est fluide, même en regardant des vidéos sur YouTube à une bonne résolution. Attention à ne pas perdre de vue que c'est le serveur Guacamole qui doit encaisser le trafic entrant et sortant. Selon l'usage et le nombre de clients il faudra donc le dimensionner correctement.

Je ne vais pas m'étendre sur les différentes options, l'interface et claire, la documentation également et d'autres en parlent très bien.

Sécurisation

Il n'est bien sur pas question d'exposer ce serveur directement sur internet et je vais tester deux solutions de reverse proxy, je commence par éditer le fichier docker-compose.yml afin de supprimer le proxy Nginx préinstallé histoire de ne pas empiler les proxys. J'ajuste également en 8080:8080 pour une utilisation en direct et REMOTE_IP_VALVE_ENABLED: 'true'  pour activer le proxy externe et WEBAPP_CONTEXT: 'ROOT' afin que Guacamole soit accessible en racine :

version: '2.0'
networks:
  guacnetwork_compose:
    driver: bridge

services:
  # guacd
  guacd:
    container_name: guacd_compose
    image: guacamole/guacd
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./drive:/drive:rw
    - ./record:/record:rw
  # postgres
  postgres:
    container_name: postgres_guacamole_compose
    environment:
      PGDATA: /var/lib/postgresql/data/guacamole
      POSTGRES_DB: guacamole_db
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: postgres:15.2-alpine
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./init:/docker-entrypoint-initdb.d:z
    - ./data:/var/lib/postgresql/data:Z

  guacamole:
    container_name: guacamole_compose
    depends_on:
    - guacd
    - postgres
    environment:
      REMOTE_IP_VALVE_ENABLED: 'true'   # On active ici l'utilisation via un proxy externe
      WEBAPP_CONTEXT: 'ROOT'
      GUACD_HOSTNAME: guacd
      POSTGRES_DATABASE: guacamole_db
      POSTGRES_HOSTNAME: postgres
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: guacamole/guacamole
    volumes:
    - ./custom/server.xml:/home/administrator/guacamole-docker-compose/server.xml
    links:
    - guacd
    networks:
      guacnetwork_compose:
    ports:
    - 8080:8080
    restart: always

Je relance docker :

administrator@guacamole:~/guacamole-docker-compose$ sudo docker-compose up -d

En local je me connecte maintenant en http://ip_serveur:8080 sans SSL car le SSL sera géré par le proxy.

Option 1 : pfsense

J'ai un pfsense installé avec HAProxy et Acme pour gérer les certificats Lets'Encrypt, je vais donc me servir de ca pour publier le service. Sur HAProxy on configure le BackEnd et le FronteEnd qui lui utilisera le certificat préalablement créé avec Acme. Dans ma configuration je partage l'IP avec plusieurs sites et ce qui est important c'est d'activer l'option forwardfor qui permettra de transférer les adresses sources à Guacamole.

Je mets ici le code de configuration qui sera utile à ceux qui n'utilisent pas HAProxy sous pfsense qui lui dispose d'une interface graphique. Comme on peut le constater le HTTP to HTTPS se fait au niveau du HAProxy et c'est lui également qui redirigera les requetés HTTTP vers HTTPS et mon serveur sera accessible sur https://guacamole.mondomaine.tld :

global
  maxconn     10000
  stats socket /tmp/haproxy.socket level admin  expose-fd listeners
  uid     80
  gid     80
  nbproc      1
  nbthread      1
  hard-stop-after   15m
  chroot        /tmp/haproxy_chroot
  daemon
  tune.ssl.default-dh-param 1024
  server-state-file /tmp/haproxy_server_state

listen HAProxyLocalStats
  bind 127.0.0.1:2200 name localstats
  mode http
  stats enable
  stats admin if TRUE
  stats show-legends
  stats uri /haproxy/haproxy_stats.php?haproxystats=1
  timeout client 5000
  timeout connect 5000
  timeout server 5000

frontend Shared_WAN-merged
  bind      x.x.x.x:443 (IP WAN) name x.x.x.x:443 (IP WAN)   ssl crt-list /var/etc/haproxy/Shared_WAN.crt_list  
  mode      http
  log       global
  option    http-keep-alive
  option    forwardfor
  acl https ssl_fc
  http-request set-header   X-Forwarded-Proto http if !https
  http-request set-header   X-Forwarded-Proto https if https
  timeout client    30000
  acl     Admin var(txn.txnhost)      -m str -i admin.domain.tld
  acl     guacamole var(txn.txnhost)  -m str -i guacamole.domain.tld
  http-request set-var(txn.txnhost) hdr(host)
  use_backend Admin_ipvANY  if  Admin 
  use_backend Guacamole_8443_ipvANY  if  guacamole 

frontend http-to-https
  bind            x.x.x.x:80 (IP WAN) name x.x.x.x:80 (IP WAN)
  mode            http
  log             global
  option          http-keep-alive
  timeout client  30000
  http-request redirect code 301 location https://%[hdr(host)]%[path]  

backend Admin_ipvANY
  mode     http
  id       100
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   admin 192.168.55.44:80 id 101  

backend Guacamole_8443_ipvANY
  mode     http
  id       102
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   guacamole 192.168.66.55:8080 id 101

Option 2 : CloudFlared

Cette option est encore plus simple pour ceux qui disposent d'un domaine chez Cloudflare. On va utiliser les possibilités offertes gratuitement par Cloudflared et ajouter une couche de sécurité supplémentaire.

On commence par créer un tunnel CloudFlared avec une instance Docker supplémentaire (le code est fournit par le site de configuration Zero Trust de Cloudflare)

docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJhIjoiZjk0YjdkZTBiMzFmYWNkNjZlshhsgfhsfghsgfhgfhssgfhsfgzRiMC00MmNlLWJjMghsfghsghsgfhsgfhsgfhsgmpaR00tyyretu(-yenebybvewWXpGaUxUazVNell0TnpRek56WXhNMlkxWXpFeiJ9

Ensuite une fois que le tunnel est monté

On va publier et pointant sur l'ip privée et le port de notre serveur, cela va automatiquement créer l'entrée DNS dans CloudFlare et gérer la problématique du certificat. Ll sera accessible en SSL. :

Ensuite on va ajouter une couche de sécurité supplémentaire en créant une application de type SelfHosted à laquelle on affecte une policie qui impose un code supplémentaire lors d'une connexion. Ce code sera envoyé sur le mail de l'utilisateur sur une adresse individuelle ou un domaine spécifique. Ce n'est pas tout à fait du MFA, mais on considère que si l'utilisateur reçoit bien le code sur son mail professionnel, il s'agit bien de lui et on peut lui permettre de saisir son login / password pour accéder au service :

C'est la méthode la plus simple et de nombreuses option sont exploitables, de même qu'il est possible d'utiliser de nombreux providers externes d'authentification :

Lorsqu'il souhaite se connecter, l'utilisateur tombe sur un portail que l'on peu personnaliser aux couleurs de l'entreprise.

Voilà, et surtout maintenant on retrouve bien les IP publiques dans le log de Guacamole :

Il n'y a plus qu'a ajuster les différentes options de Guacamole et pour ça la documentation est très bien faite. Et bien sur si on se sert de Guacamole pour exposer des serveurs RDP accessibles sur l'internet on prendra soin de restreindre leur usage à l'IP publique du serveur Guacamole, ou mieux de faire transiter ce flux par un tunnel (Wireguard, Tailscale ou Zerotier par exemple que l'on peu facilement installer sur les deux serveurs).

Tailscale Access Controls

J'ai souvent parlé de Zerotier que j'utilise au quotidien, mais qui dans sa version gratuite comporte quelques limitations en terme de contrôle d'accès dans un environnement mixant du site-to-site et des clients isolés. J'ai donc voulut voir ce que proposait Tailscale, qui est un VPN managé relativement similaire reposant sur Wireguard. Tous deux offrent des fonctionnalités gratuites et payantes. Si payer ne doit pas être un problème dans un environnement de production, c'est un peu différent en mode home lab.... d'autant plus que certaines fonctionnalités de la version gratuite ne se retrouvent que dans la version Premium à $18 /mois/utilisateur.

La version gratuite des Tailscale est plutôt généreuse, elle propose 100 nodes et 3 utilisateurs (à condition de disposer d'un "custom domain" (je vais utiliser des comptes Microsoft 365, mais plusieurs autres possibilités sont disponibles : SSO Identity Providers). On peut donc disposer de 3 comptes sur un même domaine. Je parle de comptes car nativement (et normalement) le contrôle d'accès se fait sur l'utilisateur. Manque de chance j'ai besoin de gérer 4 utilisateurs, et je ne suis pas prêt à payer 4 x $18, ce qui me ferait plus de $ 800 par an !

J'ai donc cherché à contourner et je vais finalement gérer mes autorisations à partir des machines Tailscale que j'ai approuvées (mode NFS pour ceux qui se souviennent). Dans cet usage je ne cherche pas faire communiquer les clients Tailscale entre eux mais à leur permettre d'accéder à des ressources situées sur différents subnets sur lesquels je souhaite restreindre les possibilités.

Pour la suite on considère que le réseaux Tailscale est configuré avec les nodes qui servent à joindre les subnets.

Je vais créer deux utilisateurs :

[email protected]
[email protected]

Le premier compte qui sera également le mien va également me permettre de configurer et approuver les machines clientes.

Le second servira à connecter mes utilisateurs et je pourrais approuver leurs machines. Ce compte étant protégé en MFA, il nécessitera une validation de ma part. Une fois la machine connectée, je désactive l'expiration de la clé et on passe au contrôle s'accès :

{
  "acls": [
    {"action": "accept", "src": ["[email protected]"], "dst": ["*:*"]}, // Ici l'admin dispose de tous les droits
    
    // Autorisation par machines
    {
      "action": "accept",
      "src": ["azura", "lydia"],      // Ici deux clients Tailscale
      "dst": [
        "pipa:25,53",                 // On autorise le host qui supporte le DNS si on veut utiliser les noms courts...
        "mixa:80,443,445,3389",
        "nona:80,443,445,1443,3389",  // Ports autorisés

        "lab-1:*",

        "192.168.2.12:80,443,9100,5001,3389", // Par IP + ports
        "192.168.6.0/24:*",                   // Par subnet
      ],
    },
  ],
  "hosts": {
    "azura": "100.1.2.3",        // Client Tailscale
    "lydia": "100.5.2.3",        // Client Tailscale

    "mixa":  "192.168.1.4",      // Host on subnet
    "nona":  "192.168.2.8",      // Host on subnet
    "pipa":  "192.168.2.1",      // Host on subnet

    "lab-1": "192.168.6.0/24", // subnet
  },

}

Dans l'ordre :

  1. J'autorise l'admin à tout voir.
  2. Ensuite j'autorise les machines azura et lydia à accéder uniquement aux hosts que j'aurais défini avec une restriction sur certains ports. C'est possible en définissant les hosts plus loin ou en se servant directement des adresses IP. L'ICMP (ping) est ouvert automatiquement vers les destinations autorisées.
  3. Je défini les clients et serveurs.

Voilà. Je n'ai pas creusé toutes les possibilité offertes par le contrôle d'accès proposé par Tailscale, la liste est longue et le documentation plutôt bien faire. Idées bienvenues !

Sony mon amour !

Amour déçu comme on le verra plus loin ! Depuis très jeune j'ai toujours été un afficionado de la marque Sony. Et si d'aucune pourraient trouver cela déplacé, il est des domaines ou je suis fidèle ! Coté TV après avoir eu quelques Trinitrons cathodiques célèbres tel le Profeel, je me suis offert jadis le premier moniteur plasma pro de la marque, qui avait du me couter un an de salaire et que je me suis résolu récemment à le porter à la déchetterie, le pauvre il trainait dans le garage depuis bientôt 20 ans !

Je ne vais pas vous faire la liste des écrans Sony que j'ai eu successivement, ni leur cout car ça me déprimerait, mais juste vous parler des déboires de mon dernier TV. Il y a un an j'ai craqué pour le A80J, un Oled ! Un TV intelligent sous Google TV, même si d'intelligence il n'a que la pub et les traqueurs que cela induit !

Je considère Google TV / Android TV comme étant le meilleur choix car il me permet d'installer les application qui me sont utiles, en opposition aux écosystèmes fragmentés de la concurrence qui ne proposent que l'essentiel bien commercial ! C'est du business, on le sait et on l'accepte car ça nous apporte du confort.

Autres points que les pseudo journalistes testeurs oublient souvent, c'est la télécommande et l'implémentation du CEC. Celles de Sony m'ont toujours satisfait alors que je déteste certaines d'autres marques. Mais Sony est radin, et sur le A80J la télécommande n'est pas même rétroéclairée ! Qu'à cela ne tienne il suffit de commander sur Amazon celle du A90J qui elle est premium et rétro éclairée... Quant au CEC il a toujours été très bien chez Sony.

Je ne vais pas vous raconter ce que vaut cette TV, plusieurs sites l'ont déjà fait plus ou moins bien. Enfin, je parle de TV, mais je ne regarde même pas la télé et aucune antenne n'y est raccordée. Je rêve d'une version moniteur !

Domotique

Oh le gros mot ! Encore un client qui veut faire des choses louches ! Louches car je ne me plie pas à la domotique commerciale et forcément limitative (Amazon, Google, Apple, Tuya, etc...) mais que ma domotique est libre, Home Assistant.

Et pourquoi faire ? Pas grand chose, juste inclure ce TV dans me scénarios (scènes). Et on va faire simple !

  • Play / Pause : on éteint et on rallume progressivement les éclairages comme au cinéma.
  • On / Off : on mets sur pause la musique qui était diffusée.

Ce n'est pas sorcier et très simple à faire. Mais pour ca il faut pouvoir extraire les informations du TV. Ca tombe bien ce TV est reconnu sous Home Assistant par l'intégration Bravia ou HomeKit. Dès lors on dispose des information idoines et ça fonctionne très bien, il suffit d'agir en fonction de l'état remonté.

Mais alors il se plaint de quoi le râleur ? Et oui il y a un "mais" !

Consommation

Pour accéder à ces fonctions il faut que le contrôle à distance ou / et HomeKit soit activé. C'est d'ailleurs le cas par défaut. Et les ingés de chez Sony, dont je ne doute pas des prouesses en audio / vidéo s'avèrent des brèles en réseau ! Pour que ces fonctions soient accessibles ils laissent simplement la partie réseau allumée quand le téléviseur est en veille. Et comme leur carte réseau doit dater du siècle dernier (elle a du mal à accrocher le réseau et est limitée à du 10/100 en 2022 ou on est censés passer de la full 4K !), elle consomme en veille pas moins de 26/28 W alors que si ces fonctions sont désactivées la veille est à seulement 0.9 W.

Cela pose deux constats :

  • Il est inacceptable qu'un TV en veille consomme 27 W en 2022 (c-a-d + ou - 50 € / an).
  • Il est inacceptable que ces fonctionnalités soient activées par défaut et induisent cette surconsommation ! Et certainement contraire aux directives européennes en la matière. Il est en effet peu probable qu'un consommateur lambda ne pense à mesurer et désactiver ces fonctions.

En l'état il est donc inenvisageable d'utiliser ces fonctionnalités qui ajoutent un plus au téléviseur. Et il faut noter que tout pilotage par les applis standard, Chromecast, Alexa, etc pose le même problème...

Le pire étant que si on désactive ces fonctions, quand on allume le téléviseur il mets bien trop longtemps pour accrocher le réseau, que ce soit en Ethernet ou en WI-FI. Je sais c'est fait pour regarder la télé avec un râteau sur la toiture !

Alternative

Avant j'utilisait un LCD Sony bien plus bête et une NVidia Shield que je pilotait très bien sans que cela ne grève mon budget. Le Shield allumait le TV en CEC et tout était parfait. Je vais peut être en racheter un, encore que mon Shield de 2015 fonctionne encore très bien dans ma chambre. Un bel exemple de non obsolescence qui mérite d'être signalé !

Et les autres ?

Je ne sais pas comment ça se passe chez les autres constructeurs de TV car je ne suis pas client. On me remonte 1 à 2 W avec les options de pilotage activées chez Samsung ou Panasonic, mais je n'ai pas vérifié. Par contre j'ai un bel élevage de Sonos, et là non plus ce n'est pas très joli à voir : aucun progrès depuis le début, conso identique en veille sur les anciens Play 1 et 3 et les nouveaux One (gen 1 et 2), entre 3 et 4 W voire plus de 8 à 11 W sur un AMP ou 6 W pour une Beam !

Moralité

La domotique n'est pas vraiment écologique, elle crée un énorme talon de consommation de part son infrastructure (caméras, nvr, switches, micro modules et autres prise connectées). Elle apporte plus de confort qu’elle ne fait réaliser des économies (les économies c’est le bobard que racontent certains à leur compagne quand c’est elle qui tiens les cordons de la bourse, car, hélas, la domotique reste un truc de mec, comme le BBQ, n’en déplaise à Sandrine).

Un panneau solaire va devoir s'imposer à moi !

Sources

 

 

Home Assistant & Wake on Lan

L'heure est aux économies d'énergies et il parait qu'il faut éteindre "la" Wi-Fi ! Ce n'est peut être pas ce qui consomme le plus et notre domotique fait certainement mieux.... Par contre nombre d'entre nous ont des PC énergivores qui mériteraient de passer en veille. Sauf que dans la pratique on laisse souvent ce PC allumé en se disant que l'on pourra en avoir besoin depuis l'extérieur... Ce que j'ai longtemps fait !

Un PC moderne avec un SSD sait sortir de veille en quelques secondes. Alors pourquoi ne pas ressortit une vieille fonctionnalité très peu utilisée, le Wake on Lan.

Sous Linux, Windows, voire même les mobiles il existe des application GUI ou CLI. Il faut tout de même savoir que Wake on Lan n'a pas été conçu à l'époque pour fonctionner à distance, et même s'il existe des possibilités ça reste compliqué. Alors pourquoi ne pas simplement utiliser Home Assistant qui lui sera toujours disponible, voire même simplement ajouter ça à un ESP existant, sous ESP Home par exemple..

La première chose pour vos tests sera de vérifier en local que le Wake on Lan fonctionne (il y a pas mal d'utilitaires et d'explications sur ce site).

Avec Home Assistant

On commence par ajouter l'intégration au fichier de configuration et on redémarre :

wake_on_lan:

Ensuite on peur créer un switch: , mais aujourd'hui on préfèrera un button: dans Lovelace qui actionnera le service correspondant :

  - action_name: 'Sleep/UnSleep'
    double_tap_action:
      action: call-service
      service: button.press
      target:
        entity_id: button.lia_monitors_off
      action: call-service
      confirmation:
        text: Etes vous sur ?
    tap_action:
      action: call-service
      service: wake_on_lan.send_magic_packet
      data:
        mac: 00-0C-29-FB-77-97
    icon: mdi:microsoft-windows
    name: 'Windows 10 PC'
    type: button

Vous remarquerez que j'ai configuré ça sur le tap_action:, le double_tap_action: étant lui configuré pour la commande de mise en veille via Home Assistant Agent.

Avec ESP Home

J'ai un client full cloud qui dispose d'une douzaine de PC, mais pas de serveur et encore moins de Home Assistant. La première solution était de laisser un PC allumé et y installer de quoi faire du Wake on Lan en remote. Il y a également des possibilités via TeamViewer et hélas pas de base dans l'UDM Pro d'Ubiquiti. On verra ce l'on utilisera mais j'ai également pensé faire ça via un simple ESP qui lui pourrait resté allumé...

Dans ESP Home on va éditer la config et simplement ajouter (attention, ici les séparateurs ne sont pas des "-" mais ":") :

web_server:    

button:
- platform: wake_on_lan
  name: "VM Annia"
  target_mac_address: 00:0C:29:FB:77:97

A partir de là il est possible de presser notre button: qui remonte dans Home Assistant, sur la page web de l'Esp, mais également via la commande curl (la doc est ici) :

curl -X POST http://192.168.210.153/button/vm_annia/press

Et comme on ne va pas demander à l'utilisateur final de faire un "curl" on va lui emballer tout ça dans une page web accessible que l'on sécurisera afin que lui seul puisse y accéder, en partant de cette base :

<HTML>
<center>

	<form name="myform" action="http://192.168.210.153/button/vm_annia/press" method="post">
  	<button>PC Annia ON</button>
	</form>

</center>
</HTML>

Variante avec un WebHook

L'ESP remonte sur Home Assistant via ESPHome. De fait on peu presser un bouton pour réveiller le PC distant, voire même intégrer ce bouton sur un autre Home Assistant en remote. Mais il est également possible de créer un WebHook et de déclencher avec un raccourcis depuis le PC de l'utilisateur distant :

- alias: Réveil PC Carole (WebHook)
  description: ""
  trigger:
    - platform: webhook
      webhook_id: "secret-id"
  condition: []
  action:
    - service: button.press
      data: {}
      target:
        entity_id: button.reveil_pc_carole
  mode: single

Et le raccourcis à créer sur le PC de l'utilisateur qui doit réveiller son PC de bureau...

curl -X POST https://ha-online.suptel.org/api/webhook/<secret-id>

Infos

  • Attention, Microsoft a introduit un concept de veille moderne qui souvent demandera à être désactivé. Des infos ici et .
  • Il n'est pas possible de réveiller un PC connecté en Wi-Fi ou en Ethernet via USB.
  • A noter que la Freebox dispose d'une option permettant de laisser passer du Wake on Lan. Ce n'est pas le cas pour tous les routeurs et il faut parfois ruser avec le port 9.

Sources

 

Home Assistant & Cloudflare Zero Trust

Une fois de plus on va parler de VPN. J'avais ici évoqué Zerotier (gratuit pour 25 nodes) que j'utilise toujours notamment pour interconnecter plusieurs sites entre eux en remplacement d'IPSEC. Ca fonctionne très bien et ça se fait oublier. Entre temps on a découvert Wireguard qui est très performant et peut être utilisé en natif (faut faire le taff) ou via des intégrations comme Tailsacle (entre autres) dont la version gratuite sera suffisante pour bien des usages.

Aujourd'hui on va parler de Cloudflare Zero Trust. Au départ je voulais juste tester sous Home Assistant car cela permet de publier son Home Assistant sans ouvrir de ports sur le routeur, de la même façon que l'on peut le faire si l'on dispose d'un abonnement Nabu Casa. J'ai cet abonnement, mais je ne veux pas l'imposer aux utilisateurs que j'aide.

Si Zero Trust est basé sur Wireguard il n'a rien d'open source. Certains n'aimeront pas quelque chose qui passe par Cloudflare qui comme beaucoup d'acteurs du marché pratique la collecte de donnée. C'est le business de l'époque, d'autres font pire mais ce n'est pas le débat ici, alors épargnez moi vos digressions sur ce sujet, ce n'est pas l'objet. Si vous choisissez cette solution c'est en connaissance de cause. Il existe des alternatives, moins simples à mettre en œuvre.

Zero Trust est un VPN orienté client qui permet notamment deux approches :

  • Publier et sécuriser, sans ouvrir de ports, un (ou plusieurs) site hébergés en premise (premise = chez vous, dans votre entreprise) et le rendre accessible publiquement avec des restrictions qui assureront sa sécurité (MFA) et surtout des restrictions géographiques qui sont quasi impossibles avec les autres solutions, notamment à cause de Let'Encrypt.
  • Rendre accessible des réseaux privés (VPN) en passant par le client Warp de Cloudflare) et ainsi accéder à toutes les machines du réseau (RDP, SMB, SSH, etc...).

Ce qui fait la force de cette solution ce sont les policies qui permettent une très grande granularité. Cloudflare Zero Trust est gratuit jusqu'à 50 utilisateurs. Et dans l'absolu pour sécuriser Home Assistant on a même pas besoin du moindre utilisateur.

Home Assistant

Un Add-on est disponible ici et sa mise œuvre est 'une simplicité enfantine mais il y a une petite subtilité. En effet il y a deux façons pour gérer un tunnel :

  • En local et en CLI
  • Depuis le dashboard de Zero Trust

On part du principe que vous avez un compte Cloudflare et qu'un de vos domaines y est géré. Vous avez également activé Zero Trust. A faire avant toute chose.

Dans les deux cas on ajoute ou modifie le fichier de configuration de Home Assistant ainci :

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.0/24

Option 1, gestion en local

On installe l'add-on sur Home Assistant, on choisit un host pour Home Assistant, ha.domaine.com par exemple et on lance l'add-on. Il suffit simplement ensuite d'aller copier dans le log l'url de validation et de la copier dans votre navigateur.

Et ça fonctionne, installation du certificat intermédiaire comprise. On pourra ensuite sécuriser et jouer avec les options, la doc de l'add-on est ici et cette  de Zero Trust . Si vous ne pensez pas utiliser Zero Trust pour autre chose c'est la solution la plus simple.

Option 2, gestion en remote

Vu que je compte utiliser Zero Trust à d'autres fin, c'est l'option que j'ai choisit.

  • Dans la console (Access/Tunnels) je crée un nouveau tunnel que ne configure pas.
  • Je copie le token que je viens reporter dans l'add-on et je lance l'add-on
  • Je vais dans le log et je copie l'url de validation que je colle dans le navigateur afin de finaliser l'installation et valider le certificat. 
  • Dans la gestion du tunnel je vais créer un Public Hots Name qui va correspondre à mon serveur et sera exposé avec le nom de domaine choisit :

Votre Home Assistant est maintenant accessible, ici https://test-ha.canaletto.fr (sans le port).

Aller plus loin...

En premier lieu je vous conseille de définir une policie dans Access/Applications afin que votre serveur ne soit accessible que depuis votre pays et surtout pas depuis des états plein de black hat's ...

Ensuite il faut savoir que vous avez installé sur votre serveur une passerelle VPN qui va vous permettre d'accéder à tout votre réseau local en passant par le client Warp. Pour cela il faut dans la configuration du tunnel déclarer un Private Network.

Ensuite dans les SettingsGeneral on va définir le nom de (Team) :

Dans Settings/Network on va changer le mode des tunnels. De base, dès lors que le client Warp est activé, Zero Trust va faire passer tout ce qui ne ressemble pas à une adresse privée dans ses tuyaux, c-a-d tout votre trafic, probablement à des fins de collecte de donnée... On va donc remplacer le mode Exclude par le mode Include et y déclarer uniquement notre réseau privé. Ainsi seul le trafic tunnelisé transitera par Cloudflare, et comme il est dans un tunnel ce sera théoriquement incognito. Je dis théoriquement car dans cette solution ce n'est pas vous mais Cloudflare qui a les clés... Mais nous sommes dans le cadre d'un service de classe entreprise et les CGU garantissent la confidentialité des données...

Dernier point, déclarer une méthode d'authentification. De base une authentification par code PIN est proposée, vous déclarez un domaine ou une adresse mail et vous revenez un code PIN à 6 chiffres qu'il suffit de rentrer... En option il est possible de configurer un SSO en utilisant une authentification que l'on exploite déjà (Azure AD, Centrify, Facebook, GitHub, Google Workspace, Google, LinkedIn, Okta, OneLogin, Saml, OpenID Connect, etc...). Plus complet, mais ça peut répondre à certains besoins en entreprise.

A partir de la on installe le client et on se connecte avec le nom que l'on a défini plus haut. On teste un RDP, SMB ou SSH sur une IP du réseau privé, et ça marche. Ca veut dire qu'à ce stade tout est ouvert dès lors que l'on a connecté le client, pourquoi pas dans le cadre d'une utilisation personnelle, mais je ne saurait trop vous conseiller de tout interdire et de n'autoriser que ce qui est utile (Gateway/Policies/Network).

Cet outil étant avant tout destiné à une utilisation en entreprise les possibilités sont immenses. Pour autant l'administration n'est pas très compliquée, avec quelques connaissance de base dans la gestion des réseaux.

Echanger

J'ai créé un sujet sur HACF, plus pratique qu'ici pour échanger.