De base l'UDM / UDM Pro en mode bridge sur une Freebox fonctionne en IPV4. Ca fait le job, mais parfois on peut avoir besoin d'un adressage en IPV6. J'ai lu pas mal de choses sur ce sujet, plus ou moins précises, notamment sur ce fil et sur ce site, j'ai eu quelques difficultés de mise en œuvre et je vais essayer de faire une synthèse simple.

EDIT 15/03/2024 : Lors de mon passage de la Freebox Delta à Ultra je me suis aperçu que l'on peut maintenant sur l'UDM utiliser SLAAC sur la config coté UDM. Cela simplifie grandement l'utilisation de l'IPv6 sur le LAN et évite tout ce qui suit, dès lors que l'on a pas besoin de fixer les IP (fonctionne très bien pour le player POP et OQEE).

Pour faire simple (Unifi Network 8.1.113)

La configuration IPv6 sur INTERNET/FREE :

La configuration IPv6 sur le LAN :

EDIT 02/04/2024 : Problème dans un réseau ActiveDirectory ou le routage site to site n'est pas effectif en IPv6 et ou les serveurs AD ne répondent pas en IPv6. Sur les clients le DNS IPv6 prends le dessus, et donc on n'a plus la résolution AD. Il est possible de forcer les clients à utiliser un DNS spécifique pour le domaine AD. Mais ce que la doc MS ne dit pas, c'est qu'il faut ajouter un point avant le nom de domaine pour que cela fonctionne :

Add-DnsClientNrptRule -Namespace ".domain.tld" -NameServers "192.168.x.x"

Ainsi la résolution du domaine AD passera par le DNS local et tout le reste par le DNS défini sur l'UDM. On doit pouvoir faire ça avec les policy du serveur AD.

La version plus complexe avec plusieurs réseaux en délégation

La première chose à faire est de récupérer l'IPV6 du port WAN actif de l'UDM en s'y connectant en SSH avec la commande ip addr | grep "global dynamic" -B2 -A3 :

# ip addr | grep "global dynamic" -B2 -A3
3: eth9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 10000
    link/ether 74:ac:b9:14:2d:e2 brd ff:ff:ff:ff:ff:ff
    inet 86.66.125.69/24 scope global dynamic eth9
       valid_lft 602510sec preferred_lft 602510sec
    inet6 fe80::76ec:b9xx:fe15:2df2/64 scope link
       valid_lft forever preferred_lft forever

L'IPV6 de notre port WAN est donc : fe80::76ec:b9xx:fe15:2df2/64

On va ensuite sur la page de configuration de la Freebox, dans mon cas une Delta S connectée à l'UDM avec un câble SFP+ dans l'espoir (vain) d'obtenir les 8 Gbit/s promis en 10G EPON. Donc sur http://mafreebox.freebox.fr (Paramètres de la Freebox / Configuration IPV6) et on reporte cette adresse dans le second Next Hop (et pas le premier hein !) afin de déléguer un préfixe. Et on note le préfixe associé.

On configure le port WAN de l'UDM en client DHCPv6 avec une taille de délégation de 64 :

Maintenant on va aller configurer le LAN de l'UDM. On reporte le préfixe précédemment noté au niveau IPV6 Gateway/Subnet et si on souhaite activer le serveur DHCP on défini une IP de départ et une IP de fin. Je ne l'ai pas fait car je souhaitait utiliser le DHCP de mon contrôleur de domaine Windows (pourquoi faire simple... mais idée abandonnée.). Pensez à cocher l'option RA.

A partir de là en SSH sur l'UDM on doit pouvoir pinguer en IPV6 :

# ping6 www.ibm.com
PING www.ibm.com (2a02:26f0:2b00:383::1e89): 56 data bytes
64 bytes from 2a02:26f0:2b00:383::1e89: seq=0 ttl=52 time=11.222 ms
64 bytes from 2a02:26f0:2b00:383::1e89: seq=1 ttl=52 time=11.307 ms
64 bytes from 2a02:26f0:2b00:383::1e89: seq=2 ttl=52 time=11.511 ms

Si on a pas configuré le serveur DHCP, on peut également rapidement configurer un client Windows en statique :

PS C:\Users\Lionel.SUPTEL> ping www.google.com -6
Pinging www.google.com [2a00:1450:4007:819::2004] with 32 bytes of data:
Reply from 2a00:1450:4007:819::2004: time=11ms
Reply from 2a00:1450:4007:819::2004: time=11ms
Reply from 2a00:1450:4007:819::2004: time=11ms
Reply from 2a00:1450:4007:819::2004: time=12ms

DHCP et résilience

Il me reste à configurer le serveur DHCP v6 sous Windows Serveur. Enfin, là se pose une vrai question sur les avantages et inconvénients. Actuellement j'ai un serveur Windows (VM dans un ESXi) dans une infrastructure Active Directory répartie sur plusieurs sites. Donc ça se justifie, et c'est même obligatoire au niveau du DNS.

Par contre, imaginons que demain je ne soit plus là ou dans l'incapacité de maintenir tout ça (infra IP et IoT). Il faut que l'accès internet soit résilient et puisse se passer du host ESXi . Mon idée est donc de basculer le DHCP sur l'UDM, de faire pointer les deux premiers DNS vers des serveurs AD et les deux suivants vers des DNS publics.

Mais pour cela il faut que le DHCP de l'UDM fasse aussi bien que celui de Windows. Et là ce n'est pas gagné. La lacune principale est qu'il n'y a rient pour facilement lister les baux. Sérieux ! Un jour surement dans une nouvelle interface encore plus design. A faire du beau ils en oublient souvent le fonctionnel chez Ubiquiti.

Par contre sur le DHCP WIndows j'utilise l'option 121 (Classless Static Route Option, RFC3442) qui se configure très facilement sur Windows. Sur l'UDM c'est un peu plus compliqué (mais pas plus que sur OpenSense ou Mikrotik). Heureusement il y a ici un calculateur qui va nous permettre de créer la chaine hexa que l'on va va pouvoir entrer dans les options personnalisées dans un champ texte des paramètres DHCP de l'UDM. Pourquoi faire simple !

Bien sur il est impossible d'importer les réservations DHCP de Windows vers l'UDM. Il va donc falloir se les faire à la main en cliquant sur chaque objet. Dans cette interface on peut également figer l'AP utilisé.

Il est intéressant de noter la possibilité d'affecter une IP réservée en dehors de la plage déclarée dans le DHCP. Et ça c'est intéressant. Dans un premier temps je crée un DHCP sur l'UDM avec uniquement une IP disponible et je laisse le DHCP Windows actif qui continuera à affecter les baux. Je fige les IP sur l'UDM et quand c'est terminé je peux arrêter le DHCP Windows et élargir la plage sur l'UDM, et accessoirement faire marche arrière au besoin.

Par contre coté IPv6 il n'est pas possible à ce jour de figer les IP. Ca viendra, peut-être...

Sources

• https://www.nboquestal.fr/outils/route-calculator
• https://github.com/boostchicken-dev/udm-utilities
• https://github.com/Art-of-WiFi/UniFi-API-browser
• https://hub.docker.com/r/scyto/unifibrowser
• https://github.com/scyto/docker-UnifiBrowser
• https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options

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.

Accéder au contrôleur depuis l'extérieur

Le plus simple pour administrer le contrôleur intégré à l'UDM est bien sur de passer par le cloud Unifi et l'application. Mais on peu vouloir y accéder directement depuis le port WAN. Pour cela on va commencer par suivre ces recommandations et ainsi créer une règle WAN Local :

Action : Accept
IPv4 Protocol : TCP
Rule Applied : Before pre-defined rules
Destination : Create a new port group with port 443 in the group

A partir de là on peut accéder au contrôleur sur son port par défaut (443) depuis l'extérieur. Sauf que le port par défaut n'est pas une bonne idée et on peut vouloir en faire autre chose. On va donc créer une règle dans Port Forwarding qui redirigera par exemple le port 8443 sur l'IP LAN du contrôleur, et ainsi on y accède via ce port. Au même endroit on peut créer une autre règle pour rediriger le port 443 vers une autre IP du LAN, et si on en a pas besoin on la redirige sur 127.0.0.1 afin de bloquer l'accès externe via le 443... Je sais c'est un peu tordu par les cheveux mais je n'ai pas trouvé mieux ! En ce qui me concerne j'en ai eu besoin pour cette solution de backup. Attention toutefois à verrouiller cet accès sur des IP sources pour plus de sécurité.

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. Nouvelles déconnexions sur les ampoules Xiaomi.
• EDIT 29/09/2020 17:17 : S'agissant des ampoules Xiaomi, j'ai essayé tous les paramètres possibles et imaginable ainsi que les version beta de firmware sans obtenir de résultat. J'en conclu que quelque chose a vraiment changé dans cette version qui a plus une allure de beta que de release. J'ai donc honteusement ressorti un vieil AP Netgear...
• EDIT 29/09/2020 17:17 : A la version 1.8.4 du firmware les choses sont rentrées dans l'ordre.
• EDIT 26/01/2022 16:16 : Au fil du temps et des firmwares successifs, parfois chaotiques, les choses sont rentrées dans l'ordre et maintenant l'UDMP fonctionne très bien. Pour Unifi Protect un SSD augmentera nettement les performances.

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.

Bonus

Quand on accède en local à l'UDM via son IP on a bien sur une erreur SSL. Pour remédier à ça :

1. On exporte le certificat autosigné unifi.local depuis Chrome vers un fichier .CER (un simple clic sur copier dans un fichier quand on visualise le certificat).
2. Avec une console MMC on importe ce certificat dans "Trusted Root Certification Authorities" store.
3. On édite C:\Windows\System32\drivers\etc\hosts et on ajoute IP_de_l'UDM > unifi.local (éventuellement avec HostMan).
4. Après avoir relancé le navigateur on accès de à https://unifi.local

Sources

• https://ubntwiki.com/products/unifi/unifi_dream_machine_pro

Le POE c’est très pratique, mais il ne faut pas perdre du vu qu’il y a plusieurs normes, actif et passif, 24 V et 48 V, pour faire simple (plus d'infos ici). Si certains switches peuvent détecter l’équipement et son besoin en alimentation, certains plus anciens ont juste une config 24 V ou 48 V, et ne conviendront pas à certains équipements récents.

Donc si comme j’en ai fait l’expérience vous branchez un AP Unifi LR conçu pour fonctionner en 24 V sur un POE 48 V, c’est le drame. Ensuite il clignotera rapidement et le code d’erreur correspondant (A12) indique un retour SAV, ce qui équivaut à la corbeille pour cet équipement un peu ancien.

Heureusement il y a Internet et en cherchant un peu on découvre que cet équipement (comme bien d’autres) et pourvu d’une diode Zener de protection contre les surtensions qui jouera un rôle de fusible (en fait ce n’est pas vraiment le même principe). Et l’on apprend qu’en supprimant cette diode notre équipement redevient fonctionnel ! L’idéal serait bien sûr de la remplacer par une équivalence du genre 1N4749A (1W, 24V). On peut aussi uniquement la dessouder, n’étant pas un as du fer à souder je me suis contenté de dessouder une patte afin de ne pas créer de surchauffe, mais dans ce cas je n’aurais pas droit à une seconde chance !

Sources :

_{https://elio3c.wordpress.com/reparar-ubiquiti-nanostation-picostation-bullet-m-y-mas/
https://community.ubnt.com/t5/UniFi-Wireless/AP-broken-by-owerpowering-with-48V/td-p/1734879}

Il y a quelques semaines j’ai installé dans le studio d’un ami un ensemble de caméras Unifi. Au départ j’étais tenté par piloter l’ensemble avec une Cloud Key II+ ou pour 200 € on dispose d’un contrôleur Unifi et d’un NVR avec 1TO de disque. Problème, ce produit n’est pas vraiment disponible en France et je n’avais aucun recul sur la chose. Finalement j’ai recyclé un DL360G5 que j’avais déposé il y a quelques mois, même pas eu besoin de le réinstaller car son ESX 5.5U3 tournait comme une horloge, très largement suffisant pour faire tourner une VM Windows qui supporte le NVR soft d’Unifi. On est face à une installation professionnelle, la qualité est au rendez-vous, notamment le retour audio qui est assez bluffant, et l’ensemble est cohérent pour un coût contenu.

Bref, si je vous raconte ma life c’est pour introduire un petit jouet que j’avais commandé en parallèle pour tester, la Mi Home Security Camera 360°. En fait je ne pensais même pas que c’était une caméra motorisée, mais c’est le cas et la qualité Xiaomi est au rendez-vous. Et Xiaomi, je suis plutôt fan. Elle pivote donc de haut en bas, du sol au plafond et sur 360°, c’est du full HD 1080p avec un zoom numérique 16x acceptable et une vision nocturne donnée pour 9 mètres. Elle dispose d’une détection de mouvement dopée à l’IA et il est possible d’enregistrer les séquences en local sur une SD ou encore sur un NAS.

Que dire d’autre sur ce gadget ? Ah si, il y a un truc qui est bluffant et que d’aucuns trouveront restreignant. Ici pas de serveur web embarqué chip comme sur la plupart des caméras asiatiques, tout se passe uniquement via l’application Mi Home sous Android ou IOS. Et ce qui est bluffant c’est que l’installation se fait en deux minutes chrono. On lance l’application Mi Home, on choisit le SSID de son réseau Wi-Fi ainsi que le mot de passe et on place son smartphone sur lequel s’affiche un QR Code face à la caméra. Et basta, la petite caméra est configurée. Pas besoin de jouer avec des ports et des IP, c’est out of the box, mais il faudra cependant il faudra toujours passer par l’application du constructeur.

Ah si un dernier truc pour se laisser tenter, le prix c’est 39,99 € et sur Amazon on trouve même des modèles de démo reconditionnées pour moins cher. Autre option, l’Asie en direct chez Gearbest ou AliExpress, mais c’est à peine moins cher et bien plus long…

L’USG d'Ubiquiti est un routeur qui offre de nombreuses possibilités. De versions en versions il se bonifie, mais il reste encore pas mal de choses à faire à la main. Si le Dual WAN en sortie répartit bien la charge entre les deux ports ou utilise le second en secours, il reste encore des choses simples, qui se font par l’interface de gestion sur la plupart des routeurs, mais qui nécessiteront ici de se plonger dans Linux comme on le ferait sur un vieux gros Cisco… Tant qu’à se plonger dans le CLI, il serait peut-être temps d’en finir avec les techniques de Dual WAN et de s’orienter vers des implémentations libres de MPTCP (et je ne parle pas de l’OTB d’OVH qui s’avère au final une solution commerciale coûteuse, bugs compris !). De par son architecture il y a d’ailleurs plus de chances que cette technologie intéresse d’autres opérateurs que des constructeurs.

Mais revenons à l’USG. Les développeurs avancent mais il reste pas mal de choses qui ne sont pas implémentées dans leur magnifique interface. C’est le cas par exemple si l’on veut qu’un trafic spécifique (ports, ip, source, destination) passe par une liaison spécifique, comme par exemple forcer le flux TV vers le port WAN sur lequel est installée la ligne Free, alors qu’au premier abord on aurait pu penser qu’une simple route statique dans cette magnifique interface de gestion aurait suffit, et bien non :

configure
set protocols static table 5 route 0.0.0.0/0 next-hop WANx_IP_Gateway
set firewall modify LOAD_BALANCE rule 2500 action modify
set firewall modify LOAD_BALANCE rule 2500 modify table 5
set firewall modify LOAD_BALANCE rule 2500 destination address 212.27.38.0/24
set firewall modify LOAD_BALANCE rule 2500 protocol all
commit;exit

Un autre "piège" se situe au niveau de port forwarding. Dans l’interface on configure cela facilement et ça crée automatiquement les règles de firewall associés. Normal, sauf qu’à l’utilisation on s’aperçoit que ça ne fonctionne que pour le WAN1. Et c’est repartit pour un peu de SSH… Attention toutefois, l’interface WAN2 peut aussi être PPPOE1 selon votre connexion…

configure
set service nat rule 4000 description "WAN2 tcp 80"
set service nat rule 4000 destination address WAN2_IP
set service nat rule 4000 destination port 80
set service nat rule 4000 inbound-interface pppoe1
set service nat rule 4000 inside-address address 192.168.210.18
set service nat rule 4000 inside-address port 80
set service nat rule 4000 protocol tcp
set service nat rule 4000 type destination
commit;exit

Pensez aussi à noter les règles ainsi crées (on peut aussi les retrouver avec un show service nat et les effacer avec un delete service nat rule RULE_NUMBER). Il va falloir rendre cette configuration pérenne au reboot grâce à un fichier config.gateway.json, le sujet a été largement abordé dans la communauté Unifi et ailleurs (voir les liens ci-dessous).

Il me reste à explorer le comportement des liens VPN IPSEC en cas de passage en mode secours sur le WAN2, mais ça sera pour une autre fois, à moins que vous ayez des idées et astuces, elles sont bienvenues dans les commentaires !

Sources

_{https://help.ubnt.com/hc/en-us/articles/235723207-UniFi-USG-Port-Forwarding-Configuration-and-Troubleshooting
https://help.ubnt.com/hc/en-us/articles/215458888-UniFi-How-to-further-customize-USG-configuration-with-config-gateway-json
https://help.ubnt.com/hc/en-us/articles/360005460813-UniFi-USG-Advanced-Policy-Based-Routing
https://help.ubnt.com/hc/en-us/articles/360002668854-UniFi-Verifying-and-Troubleshooting-IPsec-VPN-on-USG}

La qualité du WI-FI revient souvent sur la table et on me demande souvent ce qu’il faut changer pour améliorer la situation. 

Un WI-FI de qualité devient la base de toute installation. Pour les équipements mobiles (smartphone, tablettes, laptops), multimédia (Apple TV, Android TV) mais également les objets connectés ou certains utilisent le WI-FI. D’aucuns parlent de routeurs de plus en plus puissants et évolués, mais il ne faut pas perdre de vue que le routeur (ou la box) n’est généralement pas placé au meilleur endroit pour assurer une couverture optimale des lieux, simplement parce que la ligne n’arrive généralement pas au bon endroit. Bref, la box au fond du garage ne couvre pas toute la maison, et si je la remplace par un routeur avec douze antennes mais toujours au fond du garage ça ne changera pas grand-chose. C’est pourquoi je dénigre généralement cette approche. 

Voyons les options possibles

• Pour les petites surfaces et un usage modéré, généralement les dernières générations des box proposées par les fournisseurs suffisent. Les Freebox Révolution et 4K dont l’électronique est similaire assurent toutes les fonctions utiles. Si les autres box sont un peu moins geek, elles font pour autant ce qu’on attend d’elles.
• Si on est un peu geek un bon routeur WIFI bien placé peut être une alternative intéressante, dans ce cas on passe la box en mode bridge (on perd souvent la TV, mais pas toujours). On peut aussi envisager un modem / routeur. Dans tous les cas cette solution sera équivalente à la box des FAI avec plus ou moins de fonctionnalités et parfois des régressions (TV, téléphone).
• Une solution professionnelle du genre routeur / firewall et des bornes WI-FI indépendantes. C’est une configuration de type entreprise que j’ai déployée dans mon home lab. Ca nécessite quelques connaissances de base, mais c’est illimité en termes de possibilités. Après avoir longtemps travaillé avec des routeurs de la gamme RV de Cisco j’ai basculé vers de l’Unifi avec un USG à la place du routeur et des bornes WI-FI de la même marque. L’USG gère deux accès ADSL en mode répartition de charge ce qui assure également une tolérance aux pannes et j’envisage une option 4G. La Freebox et le modem du second opérateur sont en mode bridge. Si j’avais de la fibre je pourrais me passer du modem en connectant directement le port WAN sur l’ONT. Et pour revenir au WI-FI, si une seule borne AC Pro placée au centre de la maison assure une bonne couverture, je pourrais en chainer plusieurs, ce que l’on fait aisément sur de plus grandes surfaces.
• Enfin, les solutions de maillage pour le grand public avec plusieurs bornes WI-FI. C’est la solution à la mode proposée par plusieurs constructeurs dans des packs avec généralement 3 bornes. Personnellement je conseillerais Google WI-FI ou Amplifi d’Unifi qui se configurent en quelques minutes avec un simple smartphone. Mais les Netgear & co ont aussi les leurs. Dans ce cas on ne fait qu’étendre le WI-FI sans toucher au routage. On désactivera donc la fonction WI-FI de la box ou du routeur pour configurer à la place la solution maillée. Si on avait déjà un SSID personnalisé, autant reprendre la même configuration et mot de passe afin de ne pas avoir à ré authentifier tous les équipements. On peut également en profiter pour créer un réseau pour les invités qui n’auront accès qu’a Internet et non aux équipements locaux.

Le réglage des canaux

Dans un contexte saturé on évitera les canaux encombrés. Les équipements disposent généralement de réglages automatiques mais on pourra affiner avec une application sur smartphone qui permettra de visualiser la situation avec les équipements des voisins sur lesquels on ne pourra pas agir. Dans une maison isolée il peut y avoir d’autres équipements à contourner qui ont leur propre WI-FI direct (TV, imprimantes) ou des réseaux cachés comme celui de Sonos. Pour améliorer le débit on choisir une largeur de bande de 40 Mhz pour peu qu’il y ait de la place… 

Les normes

Ces normes sont définies par l’IEEE. Actuellement on parle de 802.11n et 802.11ac. Pour faire simple la plus répandue est le 802.11n ou les appareils assurent également la compatibilité b et g. Le 802.11ac travaille sur des fréquences plus hautes, sa portée est moindre mais son débit est plus important. Le minimum à ce jour est de disposer de 802.11bgn et un nouvel investissement devra inclure le 802.11ac. Le 802.11ax arrive mais il n’y a pas d’urgence car peu d’équipements terminaux sont disponibles. Enfin, le marketing s’empare de la chose et pour plus de clarté ces normes vont être renommées WI-FI 1 2 3 4 5… Pour comprendre tout ça il y a plein d’articles sur la toile, comme ici par exemple.

Enfin, n’oubliez jamais que le WI-FI ne remplacera jamais le câble Ethernet. D’ailleurs pour brancher des bornes aux bons endroits il faut du câble. Donc dans une construction ou un contexte de rénovation il ne faut pas hésiter à passer des câbles dans tous les sens et les ramener vers un point central (câblage en étoile). Ne pas perdre de vue que l’endroit idéal pour poser un point d’accès se situe généralement en hauteur, un peu comme un détecteur de fumée dont la forme est souvent reprise.