Unifi Dream Machine Pro

Chez les afficionados de la marque on a généralement tous commencé par un AP WI-FI. Et puis comme ça fonctionnait bien et que c'était beau on s'est laissé aller pour un USG, et là c'était beau, mais pas exempt de bugs et surtout limité en CPU pour exploiter une fibre ou DPI/IPS. Il y a bien eu l'USG Pro, pas vraiment beaucoup plus puissant. Sur tous ces modèles le VPN n'a jamais été le point fort et quant à faire de la publication il n'y a rien d'autre qu'une possible translation de ports entrants comme sur un vulgaire routeur grand public, si cela pouvais se comprendre sur les modèles précédents, on aurait aimé un reverse proxy sur la machine censée nous faire rêver !


(source Unifi)

Mais il n'en est rien, il faut considérer l'UDM Pro, et c'est son positionnement marketing, comme un routeur d'accès avec des services (Contrôleur Unifi, Unifi Protect, contrôle d'accès, téléphonie IP, etc..). Si l'on souhaite publier des services on regardera plutôt du coté de pfsense ou autres Appliance qui font ça très bien. Et si on veut faire du VPN,  ce qui est par contre dans la cible du produit, ce sera IPSEC ou OpenVPN. Zerotier ayant été porté sur la gamme Edge, il y a des chances que quelqu'un fasse le portage sur l'UDM Pro, voire qu'Unifi le fasse, à moins qu'ils ne se laissent tenter par WireGuard...

A 319 € (HT) l'UDM est un produit intéressant qui combine donc plusieurs fonctions : 

  • un USG performant avec fonctionnalités de firewall avancées (IPS/IDS, DPI)
  • un switch 8-port Gigabit et un port 10G SFP+, un port WAN Gigabit et un second port WAN en 10G SFP+ (de quoi y raccorder les nouveaux produits en 2.5 GB et 10 GB actuellement en Early accès et profiter des offre fibre en 2.5 GB ou 10 GB proposées par certains FAI).
  • un contrôleur UniFi (= CloudKey ou CloudKey Gen2+).
  • un NVR UniFi Video avec emplacement disque dur 3.5″ ou 2.5".
  • d'autres contrôleurs à venir (contrôle d'accès, téléphonie IP, et certainement quelques autres projets dans les cartons...).
  • et enfin comme tous les Gen2 de la marque on est en présence d'un petit écran de contrôle en face avant. Petit gadget pour doigts de fée !

Si le contrôleur Unifi intégré pourrait très bien trouver sa place ailleurs (VM, Cloud, ...), l'enregistreur vidéo (Unifi Protect), qui est identique, mais plus puissant que celui que l'on trouve sur le CloudKey 2+, constitue un vrai plus si on veut gérer un grand nombre de caméras et stocker jusque à 14 TB de vidéos de surveillance. A noter qu'il existe chez Unifi un autre NVR plus puissant avec le support de 4 disques.

Le NVR

Ca c'était le bla bla marketing annoncé. Dans la pratique Unifi Protect sur l'UDM Pro me semble bien bogué pour un produit sorti il y plus de six mois. Ca commence avec le disque dur, quelque soit le modèle installé parfois il le voit, parfois pas, et quand il le voit il ne l'exploite pas (impossibilité d'enregistrer). Certains conseillent de le retirer et de le formater en ext4, pas mieux, de juste supprimer les partitions, là il est visible mais non exploitable. Pas très normal qu'on ne puisse pas lancer l'initialisation/formatage depuis l'interface. Et je passe sur les paramètres des caméras qui sont pris en compte depuis l'application mobile mais impossible depuis le portail web qui lui répond que la caméra n'est pas reconnue, alors qu'elle l'est bien sur... A cette heure je regrette ma CloudKey 2+ !

Le routeur

Le routeur d'accès qui lui remplacera l'USG reste à apprécier à l'usage, Ca remplace mais ça reste un USG dont je ne vais pas reprendre le détail ici, un une partie qui mériterais de la part d'Unifi quelques évolutions, avec notamment l'intégration à l'interface de tout ce qui n'apparait pas mais reste faisable en CLI.

2 ports WAN, mais un seul en 10 G !

A noter que le WAN1 qui est en 1 GB est toujours le port principal WAN et que si on souhaite faire du failover on le fera avec le WAN 2 qui lui est en 10 GB (SFP+) ou en 1 GB en utilisant un adaptateur UF-RJ45-1G. C'est d'autant plus bête qu'en utilisation normale on peut imagine une grosse fibre sur le WAN principal et un xDSL en secours. Ca reste du soft, et on peut imaginer une évolution du firmware, et pourquoi ne pas banaliser tous les ports en WAN/LAN comme le fait Cisco depuis plus de 10 ans sur des produits SMB de la gamme RV.

Dans tous les cas, sur le papier, on reste sur de l'agrégation ou du failover utilisable en sortie, et pour l'instant c'est failover only (La seule solution intégrale d'agrégation via un tunnel restant l'OTB d'OVH ou sa version open source openMPTCP).

Quand au WI-FI contrairement à l'UDM, l'UDM Pro qui se place dans un rack n'intègre logiquement pas d'AP. Alors on est tout de même en droit de se demander pourquoi sur un produit qui est censé gérer des AP et des caméras en POE, on ne trouve aucun ports POE ? Je pense simplement qu'à la conception la question a bien du se poser, le marketing l'a emporté en argumentant que cela ferait vendre des commutateurs POE, produits sur lesquels la marge est certainement bien plus importante. C'est dommage car avec quelques ports POE l'UDM Pro aurait été presque parfait ! Business is business !

Un firmware intégré...

Contrairement aux habitudes prises avec Unifi, ici le firmware intègre tout, le firmware de la machine de base proprement dite (USG), le contrôleur Unfi Network, le contrôleur Unifi Protect et les autres applications... Si la bonne idée est de simplifier, on va voir que dans la pratique ce n'est pas si simple tant les versions sont évolutives chez eux...

Coïncidence, mon UDM Pro est arrivé le lendemain du jour ou j'ai mis à jour (par erreur) ma CloudKey 2+ avec le contrôleur avec 6.0.20. Mal m'en a pris car cette version, tout comme la suivante en 6.0.22 est tellement buggées qu'on peut aisément penser qu'elle a été lâchée en release par erreur (un stagiaire ?). Problème, la 6.0.x n'existe pas sur l'UDM Pro qui est en firmware 1.8 qui intègre le contrôleur en 5.x. Dès lors impossible de migrer une installation en 6.x vers du 5.x ! (il ne s'agit pas vraiment d'un process de migration mais une simple opération de backup/restaure, il faut donc que la source ait un niveau de release inférieur ou égal au contrôleur de destination).

Alors j'ai cherché, j'ai fini par installer la 1.8.1 RC3 qui n'apporte hélas pas de contrôleur en 6.x ... et pour finalement découvrir qu'il était possible de mettre à jour le contrôleur d'UDM Pro en SSH. Et pourquoi pas avec un bouton upload ? On a parfois l'impression qu'il y a chez Unifi pas mal d'ingés de l'ancien monde, ceux pour qui le CLI est et reste la seule option possible... Ce qui n'est pas très logique pour un constructeur qui se démarque avant tout par ses magnifiques interfaces !

ssh udm ...
unifi-os shell
cd /tmp
curl -o "unifi_sysvinit_all.deb" https://dl.ui.com/unifi/x.xx.xx_version/unifi_sysvinit_all.deb
dpkg -i unifi_sysvinit_all.deb 
rm unifi_sysvinit_all.deb 

Et comme je n'ai pas reçu ce produit du service de presse pour le tester, mais que je l'ai acheté pour l'utiliser, me voilà donc en principe dans la possibilité de migrer. Je fait un export du contrôleur et un export du NVR depuis la CK 2+ (je ne me pose pas la question d'exporter les vidéos de la CK 2+, mais il parait que c'est possible...). Ensuite je débranche l'USG et la CK 2+, c'est important. A partir de la il me suffira en principe d'importer le backup du contrôleur sur l'UDM Pro et ensuite le backup du NVR.

Dans la pratique c'est un peu plus compliqué. Si l'importation se passe bien le redémarrage annoncé ne s'opère pas. Je le fais manuellement au bout d'une heure. Mais au retour je ne peux me connecter localement, ni sur l'ancienne l'IP (192.168.1.1), ni sur l'IP de configuration importée (192.168.210.1). Par contre je peux le faire à distance (à noter que c'est un nouveau portail d'administration). Et là en fouillant je constate deux choses :

  • Le port 11 (SFP) qui assure la liaison avec mon USW-48 a perdu sa configuration en 1 GB FDX (et non il n'est pas auto sense...)
  • Que si l'IP LAN a bien été importée dans la configuration, c'est toujours l'ancienne IP qui répond, et de fait le système ne voit pas les autres équipements importés (SW, AP).

Réactiver le port SFP en FDX est facile, pour que l'IP LAN soit bien prise en compte j'ai finalement rentré l'ancienne à la place de la nouvelle, appliqué la configuration, et ensuite remis la nouvelle, et oh merveille ça fonctionne. Oh merveille mon cul, car c'est vraiment n'importe quoi.

A ce stade tout semble fonctionner, bien que dans cette version non finalisée (6.0.22) certaines choses sont à faire dans la nouvelle admin (VPN) tandis que pour d'autres actions il faudra revenir à l'ancienne interface. beta bug beta bug ! Enfin, tout sauf que si le WAN2 sait bien fonctionner en failover, contrairement à l'USG il est ici impossible de la basculer en agrégation (pas de réponse à ce sujet pour l'instant).

Il y a également depuis le 6.0.x des équipements WI-FI qui décrochent. C'est par exemple systématique sur les ampoules Xiaomi/Yeelight, j'ai tout retourner sans trouver de contournement. Et pour mémoire, quand on migre d'une 5.x vers une 6.0.20 il y a un Vlan only network - 0 qui se crée, je pense que c'est lié à la nouvelle façon de gérer le WI-FI Guest, en attendant il empêche toute connexion WIFI normale et il faut donc l'effacer ou le le changer d'ID (en 100 par exemple). Sur le 6.0 le WI-FI est géré différemment et on peu créer plus de 4 SSID, ce qui est par exemple plus souple pour les différencier en 2 ou 5 Ghz. et en isoler certains (IoT par exemple).

Domotique

Pour information les intégrations Unifi et Unifi Protect que l'on utilise dans Home Assistant fonctionnent et reconnaissent bien l'UDM. Petit hic il faut les réinstaller car je n'ai pas trouvé (pas trop cherché non plus) la façon de changer l'IP du contrôleur et du NVR (dans HA). Le résultat est que certaine entités peuvent changer de nom et qu'il faudra s'adapter.

Conclusion

Par la force des choses je me retrouve :

  • en prod avec du matériel qui tourne intégralement sur des versions beta. Une pratique à éviter.
  • avec un enregistreur qui n'enregistre plus rien...
  • des équipements WI-FI qui décrochent.
  • avec une foule de bugs dont une agrégation de ports inopérante.

Vous l'aurez compris, la machine à rêver ne m'a pas fait rêver mais perdre beaucoup de temps et me retrouver dans une situation très instable !

  • EDIT 22/09/2020 14:00 : la v6.0.23 du contrôleur est sortie et ça règle bien plus de choses qu'annoncé. Dont mes déconnections avec les ampoules Xiaomi/Yeelight. En fait non, mais ça tient quelques heures au lieu de 5 minutes...
  • EDIT 22/09/2020 17:30 : S'agissant de l'enregistrement sur détection de présence (Protect) et de l'enregistrement il semblerait qu'un paramètre n'ait pas été pris en compte lors de la migration ou qu'il soit nouveau (sur chaque caméra, Recording/Motion Events/Motion Algorithm), il faut faire un choix et aucun des deux n'était sélectionné. Dès lors qu'un disque dur est bien reconnu on a donc bien les enregistrements.
  • EDIT 23/09/2020 04:37 : Il est possible d'intervertir WAN1/WAN2 afin que WAN1 (le principal) profite de l'interface 10 GB sur WAN1 (et sans passer par SSH). Par contre pour l'instant seul le support du mode Failover, pour le Load Balancing (supporté sur l'USG) il faudra repasser plus tard.
  • EDIT 23/09/2020 18:22 : En parlant de plus tard, le SNMP, un peu la base sur un routeur, est caché (New Seetings + search snmp), mais pour autant il ne fonctionne pas. Il parait que apt-get ... etc... On se marre !
  • EDIT 23/09/2020 19:30 : Passage de la 6.0.23 en release et sortie de la 6.0.24 en beta. Ca turbine chez Uniquiti, il faut dire que ça grogne partout ! Nouveaux firmwares UAP/USW.
  •  

J'espère pouvoir échanger avec Unifi et qu'ils sauront m'apporter des réponse satisfaisantes à tous ces problèmes. Je mettrais bien sur à jour cet article énervé en fonction de.

Sources

 

Unifi Protect & Alexa

Unifi Protect pour gérer ses caméras (Unifi) de surveillance c'est top. Sauf qu'on est face à une solution professionnelle et qu'en se sens ils ne se préoccupent pas de l'intégration avec Alexa. J'ai récemment acheté un Alexa Echo Show 5 pour remplacer mon radio réveil et je me disait que ce serait bien que je puisse lui demander de voir le flux vidéo de mes caméras, fonctionnalité non proposée de base par Unifi Protect.

En cherchant un peu j'ai trouvé un service qui pourrait m'aider, service par ailleurs pas réservé aux caméras Unifi puisque basé sur le protocole RSTP. Et cerise sur le gâteau Monocle va me permettre de demander à Alexa de voir le flux de mes caméras, sans pour autant que ce flux circule à l'extérieur de mon réseau local. Pour y parvenir il faut faire tourner localement un petit service (Linux, Windows, OSX, Docker, Synology) à caser sur une machine existante qui servira de relais, Monocle ne servant alors qu'çà aiguiller les requêtes et les flux entre les serveurs et devices Alexa et les caméras locales (via le NVR pour Unifi Protect).

On part bien sur du principe que les caméras sont installées, et fonctionnent correctement avec Unifi Protect dans notre cas. 

La première chose à faire sera de se créer un compte sur le site https://www.monoclecam.com. Ensuite on va sur la page de configuration d'Unifi Protect activer le flux RSTP (le medium me semble suffisant) et on copie le lien correspondant, que l'on pourra au passage tester en se servant de VLC.

Lien que l'on reportera sur le dasboard Monocle lors de la création de la caméra, avec simplement son adresse IP locale (rien à faire coté routeur puisque la passerelle Monocle servira de relais) et dans notre cas le TAG @tunnel, cette balise sera utilisée pour demander à Monocle de transférer les connexions d'un appareil Alexa vers la caméra de votre réseau local. Cela indique à Monocole de créer une connexion tunnel sécurisée directement entre la caméra et l'appareil Alexa sans faire transiter le flux à l'extérieur.

Il va maintenant falloir configurer la passerelle locale. Cette passerelle communique avec le Skill Alexa hébergé dans le cloud Monocle et qui utilise les détails configurés dans les étapes ci-dessus pour dire à mon Echo Show comment communiquer avec ma caméra locale. La documentation fournie par Monocle contient d'excellentes instructions sur la façon de configurer la passerelle sur différents systèmes différents, mais dans mon exemple, je vais simplement la configurer sur une VM Windows Server disponible pour ce test.

J'ai donc simplement téléchargé la version x64 de la passerelle, que j'ai décompressée dans le répertoire c:\monocle, ensuite je suis allé créé et télécharger la clé API sur mon compte Monocle et je l'ai copiée dans ce même répertoire. Il suffit ensuite de lancer monocle-gateway.exe en ligne de commande. Et voilà ! (en mode production on pourra bien sur installer cette passerelle en tant que service Windows comme décrit dans la documentation).

Coté Alexa on installe le Skill Monocle depuis l'application mobile, ce qui permettra de faire remonter les cameras dans Alexa et de les affecter à des pièces, et ensuite on demande à Alexa sur l'Echo Show de vous montrer la caméra, et miracle ça marche du premier coup !

Sources

Unifi Protect avec un RPI

La solution Unifi Protect fonctionne bien mieux que l’ancienne version Unifi Video. Sauf qu’un client vous demandera toujours ce qui n’existe pas… Si on peut très facilement visionner ses cameras sur un navigateur (astuces inside : 1 - 2) ou un application mobile, mais rien n’est prévu sur un TV isolé, sauf à connecter un PC. Et un PC n’est pas franchement ce qui sera le plus fiable sur la durée. Je suis donc allé chercher du coté de chez Raspberry, le nano ordinateur à tout faire et on y trouve un petit projet simplement nommé DisplayCameras

L’installation devait être simple mais m’a tout de même un peu cassé la tête, en fait simplement parce que j’ai pris une image Raspbian trop récente pour que tout se déroule normalement, donc voici : 

  1. On télécharge une image Raspbian, la Buster lite fera très bien l’affaire (Ou simplement une Stretch ici qui sera compatible avec le script). Avec Etcher (ou autre chose) on prépare la carte µSD
  2. Une fois terminé, on insère la carte dans le RPI et on y connecte un clavier et le réseau
  3. Une fois qu’il a démarré on lance sudo raspi-config et on configure ces options :

(3) Boot Options > Wait For Network at Boot
(4) Localisation Options > Change Timezone > (tant qu’à y être aussi votre langue et clavier…)
(5) Interfacing Options >  SSH >  Yes
(7) Advanced Options > Expand File System
(7) Advanced Options > Memory Split > 256

  1. On en profite pour faire une petite mise à jour
    sudo apt-get update && sudo apt-get upgrade -y && sudo reboot
  2. A ce stade je recommande de passer l’IP en statique avec sudo nano /etc/dhcpcd.conf (on enlève les # et on complete). Mais avant allez repérer le nom de votre interface avec un ip a car eth0 ça devait trop simple… Et ensuite on redémarre avec un sudo reboot.

# Example static IP configuration:
interface enxb827eb1aa100
static ip_address=192.168.210.35/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
static routers=192.168.210.1
static domain_name_servers=192.168.210.12 8.8.8.8

  1. A partir de là on oublie le clavier du RPI et on passe en SSH, avec Teminus par exemple. C’est plus pratique pour la copié / collé. On se connecte avec le username / password par defaut si on ne l’a pas changé plus haut (ce serait bien de le faire…) :
    Username = pi / Password = raspberry 
  1. Une fois connecté on va télécharger le code qui nous intéresse, le décompresser et enfin l’installer...

wget https://github.com/Anonymousdog/displaycameras/archive/0.8.3.3.zip
unzip 0.8.3.3.zip
cd displaycameras-0.8.3.3
chmod +x install.sh
sudo ./install.sh

Sauf que comme le script d’installation n’est pas fait pour l'ultime version de Rasbian, il en oublie l'essentiel. Il va falloir ruser un peu :

sudo apt-get update
sudo apt-get install omxplayer

Maintenant on va configurer le flux de nos caméras avec sudo /etc/displaycameras/layout.conf. Ce fichier contient également tous les réglages possibles de positionnement, mais par défaut il est configuré pour 4 caméras sur un écran HD. La principale partie qui nous intéresse est celle-ci :

camera_feeds=( \
"rtsp://192.168.1.2:7447/i6m4f1act8nwtp4bg0veqw4u_1" \
"rtsp://192.168.1.2:7447/ifkjakg27dboh5ho6ull349u_1" \
"rtsp://192.168.1.2:7447/n7jt8fimlqvm6o0a0nwjdal6_1" \
"rtsp://192.168.1.2:7447/9lqpgwvrusvk8u0br7n3t2ki_1" \

CameraDisplay ne s’appuie pas sur Unifi Protect mais sur les flux RTSP qui sont configurables en option dans Unifi Protect au niveau des réglages de chaque caméras et ce en différentes résolutions. J’ai fait mes tests sur un RPI2, je me suis donc abstenu de passer en full HD, mais c’est jouable sur un RPI3. Dans les liens ci dessous vous trouverez d’autres réglages, tel que la rotation d’images si on dispose de plus de 4 caméras par exemple…

A ce stade on est pressé de voir le résultat, alors on lance sudo systemctl restart displaycameras.service. On peut aller brancher le RPI au dos de la TV sans clavier, il redémarrera tout seul avec la bonne config. Voilà !

EDIT

Il y a des choses qui se préparent chez Unifi...

Sources