Exception d'un chemin http dans HA Proxy sous pfSense

J'utilise HAProxy sous pfSense pour publier divers sites. Outre l'économie d'adresses IP, j'augmente la sécurité, je peux faire de la répartition de charge et je profite des certificats Let's Encrypt via le plugin Acme.

Tout fonctionne très bien, sauf sur un site ou pour lequel une URL en http a été codée en dur dans un logiciel distribué aux quatre coins du monde, logiciel que les utilisateurs rechignent à mettre à jour. Ce process http fait du GET et du POST et après avoir testé une redirection http vers https de type 308 au lieu de 301 sans grand succès, je me suis dit que la seule solution consisterait à contourner le problème... en faisant une exception pour l'url du formulaire.

Explications (en partant du principe que le lecteur connait un peu le couple pfSense / HAProxy)

  1. Je crée un SharedFrontEnd HTTPS sur une IP publique de type http / https (OffLoading) en SSL OffLoading sur le port 443
  2. Je crée un premier FrontEnd qui s'appuie sur le SharedFrontEnd HTTPS avec le certificat qui va bien, cela qui va faire transiter le flux HTTPS vers mon BackEnd. On vérifie le bon fonctionnement depuis un navigateur avec https://www.domain.tld. OK.
  3. Je crée un SharedFrontEnd HTTP sur la même IP publique de type http / https (OffLoading) sans SSL OffLoading sur le port 80
  4. Je crée un second FrontEnd qui s'appuie sur le SharedFrontEnd HTTP qui lui va faire transiter en HTTP mon exception via deux ACL (hostname + path) vers mon Backend avec ces deux conditions (au sens HAProxy) et redirigera tout le reste vers le premier FrontEnd en HTTPS grâce à une règle qui exclut mon exception.

 

Voici le règle de redirection que l'on peut également placer en custom rule.

http-request redirect code 301 location https://%[hdr(host)]%[path] unless REG_PATH

J'avoue que j'en ai un peu bavé (avec l'aide de Victor), mais ça prouve une fois de plus qu'il y a peu de choses en la matière que l'on ne peut faire avec le couple pfSense / HAProxy. D'ailleurs, je ne vais pas l'expliquer ici car je n'ai fait que suivre un bon tuto, mais il est parfaitement possible de publier ainsi un serveur Exchange avec répartition de charge et éviter de coûteux répartiteurs de charge.

Sources :

 

Exploiter un serveur dédié chez Online

Je dispose depuis des années, entre autres, d’un serveur dédié sur Online / Scaleway. Pourquoi eux ? Pour le service toujours très réactif, ils répondent au téléphone tout de suite, et par exemple hier soir j’ouvre un ticket à 3 heures du matin et en 5 minutes j’avais ma réponse. Bref, on n’est pas chez OVH ! A l’occasion d’une promo je commande un nouveau serveur avec une belle remise, je me trompe en en choisissant un sans RAID hardware, un coup de fil et c’est réglé et remboursé et je n’ai plus qu’à recommander le bon serveur, avec du RAID car je veux faire de l’ESX.

Vous allez me demander pourquoi je ne prends pas simplement des instance cloud, simplement parce que c'est bien plus coûteux et surtout j'aime bien avoir la main sur toute la chaîne.

Installer un hyperviseur sur ce genre de serveur permet de mutualiser plusieurs VM dont j’aurais besoin. Pour accéder à ces VM Online propose des IP Failover facturées en sus, que l’on affecte généralement à chaque VM, qui seront de fait exposée sur le net avec leur IP. Cela pose deux problèmes, outre le coût (1.99 € / mois par IP) qui n’est pas le plus important, la sécurité du serveur hébergé sur la VM n’est assurée que par le firewall de l’O/S, ce qui reste léger et potentiellement vulnérable.

J’ai donc fait le choix cette fois de ne pas exposer mes VM et d’installer une VM frontale qui servira de reverse proxy et qui sera la seule vue de l’extérieur, donc je n’aurais besoin que d’une seule IP Failover. Il existe plusieurs solutions pour faire ça, Traefik, Ngnix par exemple, j’ai choisi pfSense avec le plugin HAProxy qui est simple à déployer et qui en plus gère très bien les certificats Lets Encrypt via le plugin Acme.

Dans la pratique on installe ESX en quelques clics via la console Online, ensuite on crée sur ESX un LAN qui n’est connecté à aucune carte réseau (on doit pouvoir utiliser le même swich virtuel que pour le WAN avec un VLAN, mais ce serait se compliquer la vie). Dans la console Online on achète une IP Failover, on l’associe au serveur dédié et on lui attribue une adresse MAC que l’on reportera sur le WAN de la VM pfSense. (je trouve le client vSphère plus intuitif que la version web pour faire ce genre de réglages).

On installe pfSense à partir d’une ISO dans une VM avec une patte WAN (sans oublier d'y reporter la MAC adresse de l'IP Faiover), et une patte LAN. Pour ces deux interfaces on prend une carte réseau VMXNet3 pour de meilleures performances.

Une fois l’installation terminée, depuis la console ont défini VMX0 sur le WAN et VMX1 sur le LAN et on configure les adresses IP correspondantes, l’IP Failover sur le WAN (SANS GATEWAY, c’est important) et une IP LAN, 192.168.x.1 par exemple et sans passerelle puisque c’est le LAN. On n’active pas le serveur DHCP.

Ensuite on passe dans le shell de la console (ce n’est pas du Linux mais du FreeBSD) et c’est là qu’il y a une particularité qui est propre à certains hébergeurs, ici pour Online, mais il y a une variante OVH par exemple. pfSense ne permet pas d’avoir une passerelle en dehors du masque de son IP WAN, il va donc falloir ruser en la définissant via le shell :

route del default (pour retirer les passerelles existantes)
route add -net 62.210.0.1/32 -iface vmx0
route add default 62.210.0.1

A partir de là on peut se connecter à pfSense avec un navigateur et se laisser guider par le wizard. On confirmera l’IP Failover mais toujours sans passerelle (ni MAC). On teste avec les diag en faisant un ping vers 1.1.1.1 et on crée une règle pour autoriser le trafic sortant depuis notre LAN. Pour la suite de la configuration cherchez vous un tuto sur pfSense !

Voilà, il ne reste plus qu’à installer nos VM et les publier via HAProxy dans pfSense.

Bonus

  • Mettre des ACL sur le firewall d’ESX pour limiter l’admin uniquement depuis certaines IP
  • Rendre l'accès à la configuration pfSense accessible uniquement depuis le LAN
  • Installer une VM Zerotier site-to-site afin de pouvoir accéder aux VM (en RDP ou SSH par exemple) ainsi qu'à l’admin de pfSense qui ne sera exposée que sur le LAN.
  • Sur pfSense installer le package Open-VM-Tools
  • Sur pfSense installer le package Shellcmd afin de figer les routes spécifiques exposées ci-dessus.

J’ai fait ça sur un serveur un peu costaud, mais c’est jouable sur les petits serveurs Avoton d'entrée de gamme qui étaient soldés à 4 € avec 16 GO…

Sources 

 

Zerotier site to site

Pour faire suite aux articles sur Zerotier (1 | 2), voici un résumé de la méthode rapide pour produire un routeur / passerelle afin de mettre en place une infrastructure site to site, et dans mon cas remplacer des routeurs IPSec vieillissants (séries Cisco RV devenus des passoires au fil du temps) pour interconnecter 4 sites. Mon choix s’est porté sur des VM ESXi car j’ai des serveurs VMWare sur chaque site, sauf un ou la VM est sur un Hyper-V, mais on peut également le faire sur un petit PC ou Raspberry Pi auquel cas il faudra faire attention aux débits possibles, le modèle 4 devrait toutefois convenir. 

On installe Debian Stretch ou Raspbian Stretch (pour l’instant je conseille de rester sur Stretch car mes tentatives avec Buster n’étaient pas très stables). Je ne vais pas vous expliquer comment installer Debian, il y a plein de tutos, mais n'oubliez pas de choisir pas d'interface + SSH + Net Tools. On va toutefois éditer l’interface afin de lui donner une IP fixe avec nano /etc/network/interfaces (attention au nom des interfaces qui peuvent parfois différer et qu’il faudra adapter dans la suite, par exemple enp0s3 à la place de eth0) (on passe en root avec su si on ne veut pas jouer avec sudo…).

source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.216.16
netmask 255.255.255.0
gateway 192.168.216.254
nameserver 192.168.216.10
nameserver 8.8.8.8

On installe quelques outils utiles...

apt-get install sudo
apt-get install bash
apt-get install open-vm-tools (uniquement si on est dans un contexte VM)
apt-get install iperf (optionnel, mais ça permettra de faire des tests de performances)

Un petit reboot et on passe à Zerotier, En partant du principe que vous avez déjà un compte et une configuration sur my.zerotier.com.

curl -s https://install.zerotier.com | sudo bash
/usr/sbin/zerotier-cli join 35c145cf9bcc75ab

Ou une variante si on veut installer une version particulière de Zerotier, ici une 1.2.12 sur Rasbian

curl -O http://download.zerotier.com/RELEASES/1.2.12/dist/debian/stretch/pool/main/z/zerotier-one/zerotier-one_1.2.12_armhf.deb
sudo dpkg -i zerotier-one_1.2.12_armhf.deb
sudo systemctl enable zerotier-one
sudo systemctl start zerotier-one
/usr/sbin/zerotier-cli join 35c145cf9bcc75ab

Un petit reboot et on active le routage IPV4  avec sudo nano /etc/sysctl.conf en supprimant le # qui le mettait en commentaire)

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

On vérifie avec sudo sysctl net.ipv4.ip_forward et on récupère le nom du réseau Zerotier avec ip link show et on active les règles suivantes :

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i zt7nndoyds -o eth0 -j ACCEPT (En changeant le nom du réseau Zerotier que l’on a récupéré avec ip link show)

On rend le tout persistant et on fait un redémarrage :

sudo apt-get install iptables-persistent
sudo netfilter-persistent save
reboot

Ensuite on se rend sur my.zerotier.com pour ajouter les routes managées. Vous allez me demander pourquoi certaines sont en /23 et non /24. Simplement parce que si on les laisse en /24, ce qui semble logique, une machine cliente Zerotier (typiquement un PC portable) connectée sur un de ces réseaux ne pourra pas voir le réseau local sans ça.

Autre remarque, si vous avez configuré des règles de flux afin de restreindre certains clients Zerotier, n’oubliez pas de créer une capacité superuser et de l’appliquer aux machines qui servent de passerelle afin d’autoriser tout le trafic entre vos sites.

cap superuser
  id 2000 accept;

Pour mettre à jour Zerotier :

apt-get update
apt-get install zerotier-one

Voilà de quoi remplacer IPSec afin autant de sécurité et d’efficacité pour peu que le tout soit bien configuré et géré. N’oubliez pas non plus de changer les routes, soit en ajoutant une route statique vers la passerelle sur les routeurs de chaque site, soit via le DHCP (celui de Windows le permet avec l’option 121, mais n’est pas reconnue par tous les clients, ou encore avec un route add (sous Windows 10 il faut le faire en mode admin).

Enfin, Iperf va vous permettre de tester le débit utile. On voit sur la capture suivante une différence significative entre deux tests, sur le second j’ai passé la ram de la VM de 1 GB à 2 GB et de 1 vCPU à 2 vCPU. A vous d’ajuster, mais il ne faut pas perdre de vue que VPN = Crypto et que cela nécessite un peu de ressources…

Bonus

DNS

Pour les machines itinérantes se posera la question de la résolution des noms. Ce n’est théoriquement pas compatible RFC, mais rien ne vous empêche dans la pratique de renseigner dans un DNS public des enregistrements de type A associés à des IP privées et ainsi pouvoir joindre facilement les machines du réseau local via une machine ZT…

Netbios

L'accès aux partages SMB passera par le port 445, par contre si vous ne voulez pas que le Netbios bave entre les sites et vous retrouver avec des machines clientes Zerotier dans votre explorateur Windows, je vous conseille de bloquer les ports suivants :

drop
dport 137,138,139
;

Sources

https://mangolassi.it/topic/19493/zerotier-site-to-site 
https://www.digitalocean.com/community/tutorials/getting-started-software-defined-networking-creating-vpn-zerotier-one

Surveiller et redémarrer une Freebox à distance

Il existe un bugg (https://dev.freebox.fr/bugs/task/22818) bien gênant sur la Freebox (Révolution et 4K) en mode bridge, toujours pas résolu par Free au fil du temps. Pour faire court, en cas de déconnexion FTTH/xDSL, le routeur qui lui est adossé ne voit plus la box qui joue ici un rôle de modem. Redémarrer le routeur ne sert à rien, c’est la Freebox qu’il faut redémarrer.

Redémarrer une Freebox peut se faire en coupant sauvagement l’alimentation, depuis la face avant avec le petit afficheur (quant il n’est pas HS) ou via Freebox OS (auquel dans ce vas on n’aura pas accès localement). Il existe une autre option avec l’API Freebox OS qui prend tout son sens si l’on supervise la Freebox à distance, dans notre cas avec PRTG Network Monitor installé dans un VPS et qui est gratuit jusqu’à 100 sensors (il existe bien d’autres solutions). PRTG envoie des notifications, mais permet également de lancer des scripts PowerShell, et c’est l’objet de cet article.

Script PowerShell permettant de rebooter une Freebox

Petit didacticiel aussi simple que couper une tomate mûre en tranches avec une sandale...

L'application PS dont ce didacticiel traite s'appelle "Remote Control". Elle permet de rebooter une Freebox depuis un script PowerShell et/ou de récupérer un flux JSON avec les informations temps réel de la Freebox, par exemple pour disposer d'un monitoring depuis une page HTML (il peut être modifié afin d'obtenir d'autres informations disponibles via l'API).

  1. Fichiers accompagnant ce didacticiel

L'archive ZIP dans laquelle se trouve ce didacticiel contient les fichiers suivants :

  • Adresse_Freebox_Locale.ps1 est un script PowerShell qui retourne l'URI de la Freebox installée sur le réseau local. Cet URI est utilisable depuis un navigateur internet situé dans ou hors du réseau local, si elle est autorisée.
  • Autoriser_Remote_Control.ps1 est un script PowerShell à lancer sur un PC du réseau local, attribuant une autorisation à l'application "Remote Control" afin qu'elle puisse contrôler la Freebox locale.
  • Freebox ECC Root CA.cer est l'un des deux certificats requis pour accéder à la Freebox en HTTPS.
  • Freebox Root CA.cer est l'autre certificat.
  • Remote_Control.ps1 est le script PowerShell qui servira à faire rebooter la Freebox ou à récupérer ses informations.
  1. Principe de fonctionnement

La Freebox peut être contrôlée de manière locale ou distante via une API pouvant être appelée en respectant l'architecture REST. Afin d'éviter que des commandes permettent la prise de contrôle d'une box par un tiers malintentionné, un ensemble de sécurités est mis en œuvre :

  1. Attribution d'un droit à prendre le contrôle, requérant une action physique sur la box,
  2. Attribution d'autorisations quant aux actions possibles lors de la prise de contrôle,
  3. Fourniture d'un jeton lors de cette attribution, lequel ne sera jamais transmis lors des appels à l'API, mais remplacé par une donnée cryptée.

L'API de la box peut être appelée en HTTP ou en HTTPS. Cependant la documentation indique que la possibilité d'utiliser HTTP sera retirée dans une version prochaine, et qu'il est fortement conseillé de n'utiliser que HTTPS. Afin de respecter cette consigne, "Remote Control" fonctionne par défaut en HTTPS, même s'il est possible de le faire fonctionner en HTTP moyennant une ou deux modifications du script et pas mal de simplifications dans le processus indiqué ci-dessous.

Afin de pouvoir utiliser "Remote Control" pour dialoguer avec une Freebox locale ou distante, il faut donc réaliser les opérations suivantes :

  1. Installer les certificats nécessaires pour pouvoir causer HTTPS.
  2. Autoriser l'application "Remote Control" sur la Freebox
  3. Installer "Remote Control" sur une machine du réseau local ou sur une machine distante (non testé), et le paramétrer correctement pour qu'il puisse interagir avec la Freebox.

L'installation et l'utilisation de "Remote Control" nécessite l'utilisation d'un PC situé sur le réseau local derrière la Freebox, un opérateur capable d'appuyer sur un bouton de la Freebox, et un PC de contrôle situé sur le réseau local derrière la Freebox ou distant via l'internet.

  1. Installation des certificats

Lorsqu'une connexion HTTPS est réalisée avec la Freebox, cette dernière nécessite un certificat attribué à Freebox ECC Root CA ou Freebox Root CA. Les fichiers correspondants sont fournis dans le zip. Il faut les installer sur le PC qui va permettre d'autoriser l'application "Remote Control" sur le réseau local derrière la Freebox ET sur le PC qui va prendre le contrôle de la Freebox.

Pour les installer, double-cliquer sur les fichiers dans l'explorateur Windows, demander à installer les certificats dans le dépôt des certificats racine. Afin de tester la bonne mise en place des certificats, ouvrez un navigateur internet et entrez dans la zone d'adresse https://mafreebox.freebox.fr, si vous accédez à l'interface de Freebox OS, c'est OK. Conservez le navigateur ouvert, on en aura besoin au point numéro 6 de ce didacticiel.

Si vous avez une page d'erreur ou une indication SEC_ERROR_UNKNOWN_ISSUER, c'est raté. Lancez MMC et le plug-in Certificats, cherchez dans le bazar les deux certificats Freebox, supprimez-les et recommencez tout depuis le début en maudissant l'auteur de ce didacticiel pour son manque de précision.

  1. Autoriser l'application "Remote Control"

Cette opération doit être réalisée depuis un PC situé dans le réseau local derrière la Freebox, selon la documentation du SDK. Il n'est pas possible d'autoriser une application depuis un PC extérieur. Dixit la doc. Il faut aussi avoir sous la main une personne physique capable d'appuyer sur un bouton sur la Freebox.

Double cliquez sur le script PowerShell Autoriser_Remote_Control.ps1 puis suivez les indications à l'écran, vous demandant d'appuyer sur le bouton "Flèche vers la droite" sur la façade de la Freebox alors que cette dernière demande si elle doit autoriser l'application "Remote Control". Appelez la personne physique devant la Freebox et expliquez-lui ce qu'elle doit faire. Une fois le bouton de la Freebox appuyé, le script devrait afficher que l'autorisation a été donnée, accompagné de l'URI de la Freebox et d'un identifiant d'application (de la bouillie en Base64). Copiez-coller l'URI de la Freebox et l'identifiant d'application dans un coin.

Nous n'aurons désormais plus besoin du fichier Autoriser_Remote_Control.ps1. L'autorisation a été donnée à l'application et sauvée dans la Freebox ad vitam aeternam, sauf :

  • Si vous supprimez l'autorisation depuis les paramètres de la Freebox (voir point 6)
  • Si vous faites une réinitialisation usine de la Freebox,
  • En cas d'échange de la Freebox, par exemple si elle venait à tomber en panne,
  • En cas d'erreur non répertoriée dans les documentations,
  • Ou si vous passez chez Bouygues et renvoyez la box chez Free.
  1. Attribuer les droits nécessaires à l'application "Remote Control"

Toujours depuis le PC situé dans le réseau local, reprenez le navigateur internet que vous aviez utilisé pour le point numéro 3, qui doit toujours afficher la page d'accueil de Freebox OS de la Freebox qui vous intéresse. Si vous l'avez bêtement fermé, collez-vous une baffe, puis relancez un navigateur internet et allez sur https://mafreebox.freebox.fr

Identifiez-vous, puis sélectionnez successivement :

  • "Paramètres de la Freebox",
  • "Gestion des accès",
  • "Applications" (en haut de la fenêtre).

Recherchez dans la longue liste des applications autorisées celle que vous venez d'ajouter : "Remote Control (demande)". Cliquer sur le bouton "Editer" à droite et modifiez les autorisations pour activer "Modification des réglages de la Freebox". Vous pouvez d'ailleurs désactiver tout le reste qui a été activé par défaut mais qui n'est pas utile. Évitez de cliquer sur la dernière icône, en forme de poubelle, qui retire l'autorisation de l'application et vous forcerait à tout recommencer depuis l'étape 4 ci-dessus.

  1. Paramétrer le script de contrôle à distance

Nous allons maintenant modifier le contenu du fichier Remote_Control.ps1 pour y insérer les paramètres de fonctionnement correspondant à la Freebox qui nous intéresse. Si vous souhaitez contrôler plusieurs Freebox, vous pouvez bien entendu copier le fichier, renommer sa copie comme vous l'entendez et la modifier. Cette opération doit être réalisée sur le PC local ou distant qui devra prendre le contrôle de la Freebox pour la rebooter. Ce PC devant de plus disposer des certificats racine, installés comme décrit au point 3 de ce didacticiel.

Il faut modifier deux lignes dans le script :

  • Ligne 43, remplacer [Insérer l'URI ici] par l'URI retournée par le script d'autorisation de l'application Autoriser_Remote_Control.ps1, URI que vous avez copié dans le bloc-notes, un email ou taggué en fin du point n°4 de ce didacticiel :

Avant :

$AdresseFreebox = "[Insérer l'URI ici]"

Après (par exemple) :

$AdresseFreebox = "https://vivalasvegas.fbxos.fr:12345"

Faites gaffe avec les guillemets, ils doivent être présents après modification de la ligne.

  • Ligne 46, remplacer [Insérer l'identifiant d'application ici] par le jeton de l'application, noté avec l'URI de la Freebox au point 4 :

Avant :

$JetonAppli = "[Insérer l'identifiant d'application ici]"

Après (par exemple) :

$JetonAppli = "M0nqsaiDup0ul3tMfgtyhbut0risaTi0nTyT0uch3pa5"

Faites gaffe avec les guillemets, comme précédemment. Sauvez le script, fermez l'éditeur, c'est prêt.

  1. Tester l'installation

Ouvrez une ligne de commande PowerShell sur le PC qui doit prendre le contrôle, PC local sur le réseau local ou PC distant (non testé) puis entrez la commande suivante sans oublier le ./ :

./Remote_Control.ps1 –Info

Bien entendu, il faut être dans le dossier contenant le fichier, sinon vous aurez une erreur indiquant que la commande est inconnue, mais bon, je suppose que vous ne vous ferez avoir qu'une seule fois. Si tout va bien, la fenêtre de PowerShell va vous afficher une longue liste d'informations sous la forme d'un flux JSON avec en vrac la température du CPU, la vitesse du ventilo, la durée de fonctionnement depuis le dernier reboot, l'âge du capitaine, toussa-toussa.

Dans la fenêtre PowerShell, entrez maintenant :

./Remote_Control.ps1 –Reboot

Ça devrait vous répondre que la Freebox est en train de rebooter, et là, paf, plus d'internet si vous êtes en local. Tout qui s'allume en rouge dans les superviseurs de tous poils, les utilisateurs du réseau local qui gueulent, le drame quoi.

Patientez quelques minutes puis rafraîchissez la fenêtre de votre navigateur internet qui était toujours en train d'afficher les infos de la box. Vous devrez sûrement retaper le mot de passe. Rendez-vous dans "État de la Freebox" et normalement, si tout va bien, derrière "allumée depuis", il devrait y avoir une valeur en secondes ou en minutes, preuve que votre Freebox a bien redémarré, que le script PowerShell a bien fait son boulot et que l'auteur de ces lignes n'est pas si con que ça.

  1. Conclusion

Il ne vous reste plus qu'à entourer tout ça d'un ruban rose, de mettre en place tout ce qu'il faut pour que ça bosse automatiquement sans vous faire ch... à chaque fois que la Freebox décroche, puis il vous faudra penser à reprendre ce didacticiel pour renuméroter les titres car le crétin qui a écrit ce document a sauté le point 5.

Lequel crétin remercie Emin, auteur de l'article Piloter sa freebox, disponible ici : ainsi que Mika-NT28 auteur du plugin Freebox OS pour Jeedom qui permet de superviser la box depuis Jeedom, lequel a également été une source d'inspiration. Et moi je remercie mon collègue FredV qui a passé une nuit sur ce petit projet !

Download

https://github.com/mycanaletto/Reboot-Freebox

Release : Reboot_Freebox_01.zip

Bonus

Comme indiqué dans le bug la collection de buggs de la Freebox, la nouvelle version du Compagnon Freebox, mais également tout ce qui accède localement à l'url sécurisée de la Freebox, ne parvient plus à trouver la Freebox en mode bridge et donc à générer une nouvelle association. Il existe une solution ici.

Sources 

https://lafibre.info/routeur/free-usg-mode-bridge-down-apres-desync/ 
https://dev.freebox.fr/bugs/task/22818 
https://kb.paessler.com/en/topic/18963-how-can-i-use-powershell-scripts-with-prtg-s-execute-program-notification 
https://p0w3rsh3ll.wordpress.com/2013/07/04/piloter-sa-freebox/ 
https://github.com/DjMomo/ClassePhpFreebox 
https://wiki.deimos.fr/Rebooter_sa_Freebox_Server_6_en_ligne_de_commande.html 
https://forum.universfreebox.com/viewtopic.php?t=55120 
https://dev.freebox.fr/bugs/task/12939 
https://dev.freebox.fr/sdk/os/

Sonos or not Sonos...

Depuis plus d’une décennie je suis un grand fan des produits Sonos, que je conseille à qui veut bien m'écouter. A l’opposé des enceintes Bluetooth, le système Sonos à démocratisé le multi-room en Ethernet et WI-FI à un coût abordable face aux systèmes multi-room coûteux proposés par les intégrateurs pour résidences de luxe, type Crestron et autres. Du coup j’en ai dans toutes les pièces, des Play 1 et Play 3 et j’ai récemment fait l’acquisition d’un Sonos AMP pour le séjour, c’est fabuleux tant en musique qu’en vidéo. Je ne vais pas vous faire l’article, il y en a pas mal sur la toile, mais j’ai vraiment redécouvert certains enregistrements de façon bien plus agréable qu’avec mon ancien Connect associé à un ampli basic, tout en conservant les mêmes enceintes Amadeus, associées avec un bon sub, qui sont alors pleinement exploitées.

EDIT du 6 septembre 2019

Hier, Sonos a annoncé 3 nouveau produits.

  • Une enceinte portable, la Play Move est une sorte de Play One avec une très lourde batterie et du Bluetooth à 400 €. Trop chère et trop lourde pour être emmenée partout, je ne suis pas convaincu par la pertinence de ce produit. J’ai déjà une Play 1 sur la terrasse ou il y a déjà une prise électrique.
  • Une enceinte sans micros, la Play One SL une Play One allégée, moins chère elle sera parfaite pour qui ne veut pas d’assistants vocaux ou en complément home cinéma, encore qu’elle soit en concurrence avec l’enceinte étagère proposée par Ikea à 99 €.
  • Et enfin le Port qui remplace le Connect et se trouve être un AMP sans ampli destiné à être connecté à une installation HI-FI classique, plutôt haut de gamme, sans quoi il existe pas mal d’accessoires qui feront le job, comme le ChromeCast audio sans dépenser 450 €. Et tout comme sur le AMP, toujours pas d'entée RIAA pour y connecter une platine vinyle sans ajouter un pré-ampli.

Tout cela pose une fois de plus une question, utilisons-nous réellement du multi-room ou voulons-nous simplement de la musique dans chaque pièce ? Dans la pratique je constate, que tant moi que mes enfants, utilisons de plus en plus l’application Spotify et que dans ce cas il faut juste pouvoir se connecter à une pièce compatible Spotify Connect… Pas forcément sur un Sonos…

Dans la salle de bain j’avais un Connect AMP, un peu poussif, associé à des enceintes encastrées dans le plafond de qualité moyenne. Hélas le Connect AMP a fait son temps (2005) et j’ai découvert à cette occasion que le SAV Sonos en France ne répare pas ses produits. Sous garantie ils les échangent, et hors garantie ils proposent un échange standard à 80% du prix du neuf (Lire 1 2) (soit environ 450 € pour un Connect AMP obsolète). Bref, il faut le savoir, et même si je n’ai vu qu’une panne en 15 ans, les produits Sonos ne sont pas réparables, sauf peut être par de bons bricoleurs !

Soit, je me suis donc dit qu’une petite Play One dans la salle de bain ferait largement l’affaire. Il n’en reste pas moins que voir ces deux enceintes encastrée inutilisées me chagrinait. Avec un peu réflexion je me suis dit qu’un petit ampli avec un Chromecast Audio que j’avais sous le coude ferait l’affaire, car plus que du multi-room, là ce sont surtout mes enfants qui envoient leur flux Spotify quand ils vont se doucher. En cherchant un peu je suis tombé sur des amplis classe T à un tarif dérisoire pour la puissance annoncée (30 € pour 2 x 50 W, Bluetooth inside !)

A ce tarif je me suis offert le NS-10G de NobSound sur Amazon mais on peut en trouver d’autres moins coûteux sur AliExpress, je l’ai raccordé au ChromeCast Audio (Google ne le propose plus mais ça se trouve facilement pour une trentaine d’Euros) qui est compatible directement avec Spotify. Il est également possible de recycler un utiliser un Raspberry avec un peu de logiciel (1|2|3), ou un adaptateur comme ceux d'Arylic (sur AliExpress en morceaux 1|2) et que l'on trouve également monté sur Amazon, le A50 semble très bien...

Alors me direz-vous, quelle différence entre un vieux Sonos Connect AMP à 550 € et un bricolage à base de chinoiserie à 60 € ? Et bien c’est quasiment pareil, en tous cas avec ces enceintes moyennes et une source Spotify, on ne sent pas vraiment de différence, si tant est qu'on ne pousse pas trop la puissance. Attention à ne pas confondre avec le Sonos AMP qui lui est juste fabuleux, il est vrai associé à des enceintes Amadeus d’un autre calibre, avec lesquelles le Connect AMP ou Connect ne donnaient pourtant pas grand-chose…

Bref, il est temps de s’intéresser aux amplis de classe D et pourquoi pas classe T.

Alternatives et liens connexes

http://www.doukaudio.com
http://www.smsl-audio.com des choses sérieuses… 

https://www.amazon.fr/gp/product/B07GB6H9B1/ref=as_li_tl?ie=UTF8&tag=canaletto-21&camp=1642&creative=6746&linkCode=as2&creativeASIN=B07GB6H9B1&linkId=055d0ce2444f8d60788d2c4886dc340d 
https://www.amazon.fr/gp/product/B07KX3MHLV/ref=as_li_tl?ie=UTF8&tag=canaletto-21&camp=1642&creative=6746&linkCode=as2&creativeASIN=B07KX3MHLV&linkId=c26908559bdc1fee991df4bf2a6a672d 
https://www.ebay.com/b/Nobsound-Mini-Amplifiers/14970/bn_89892901

Bonus

Pas de lien direct, mais une lecture amusante, j’aime ces amateurs qui poussent très loin… Je n’ai pas testé mais ça va dans le sens où j’affirme depuis des lustres qu’il ne faut pas se faire enfler par les vendeurs de HIFI et leurs câbles à 100 € le mètre !

https://www.homecinema-fr.com/forum/diy-cables/cable-hp-viablue-sc-4-vs-ethernet-ou-ptt-la-claque-t29933292.html 
http://petoindominique.fr/php/cablehp.php 
http://g.dubuc.free.fr/CableRJ.html 
https://www.touslescables.com/cordon-rj45-enceinte-H9AL-2098.html

 

Cloud Storage

Mise à jour août 2019

Les NAS c’est bien, mais ça reste faillible et ce n’est pas extensible à l’infini. Donc on finit par acheter un second NAS pour faire la sauvegarde du premier, ou de nouveaux disques. C'est sans fin. Plutôt que d’entretenir des NAS de prod et des NAS de sauvegarde et continuer à acheter des disques regardons le cloud. Il s’agit de stocker des fichiers exploitables ou des sauvegardes. Mais on verra que l’on peut aussi s’en servir de disque. Je vais vous livrer mes réflexions, dans un cadre DIY adaptable en mode professionnel. Ce sont des notes, donc c’est un peu en vrac et je vous invite à commenter vos expériences.

Les fournisseurs possibles

  • OneDrive Business. Ils peuvent les offrir leurs 5 TO, car ce n’est pas très rapide et surtout le débit est très aléatoire,
  • Même réflexion pour OneDrive, Dropbox, ce n’est pas vraiment fait pour ça. Amazon Drive était intéressant en illimité, mais c’est terminé. Et ne me parlez pas de Hubic ou je vois rouge !
  • Google Drive. C'est la bonne surprise. Les débits sont bons, voire très bons et en prenant une GSuite Business on se retrouve avec un stockage illimité (théoriquement à partir de 5 users, mais dans la pratique c'est OK avec un seul).
    • Attention, il existe une limite de 750 GO en upload, mais il est possible de la contourner en partageant un "Drive partagé" avec d'autres comptes Google
    • Google Drive est reconnu par Synology Hyper Backup et Cloud Sync ce qui offre des perspectives.
    • Attention lors des scan avec Plex ou Emby qui peuvent conduire à des ban temporaires. Il existe des contournements et astuces avec PlexDrive et autres astuces (1 | 2 | 3 | 4)
    • Attention à localiser dès le départ les données en Europe afin de limiter la latence. Il est possible de le faire plus tard mais le processus sera alors très long s'il y a beaucoup de données.
  • Online c’est coûteux et techniquement pas adapté (iSCSI par exemple), Depuis 2019 il existe une offre S3 hébergée en France pour 10 € le TO.
  • OVH en OpenStack Swift revient à 10 € / le TO + le trafic sortant au même prix, en espérant que ça ne ressemble pas à Hubic… Ça peut être intéressant car c’est en France si on veut être full RGPD.
  • Azure Storage on n’en parle même pas dans ce cadre car trop coûteux.
  • Amazon S3 est top et plus abordable pour de la sauvegarde avec Glacier, mais ça reste coûteux.
  • C’est Wasabi qui m’a poussé vers le Storage cloud. C’est très abordable. Il n’y a pas de frais de de transfert, c’est donc le plus intéressant. Leurs Data center sont aux Etats-Unis, mais l’ouverture en 2019 d’un site aux Pays Bas les rends conformes RGPD. Et rien n’empêche un petit chiffrage à la volée… Leur tarification est très simple : 1 TO c’est $ 4.99 / mois, sans frais annexes.

J'avais donc le choix Wasabi, puis GSuite Business en 2019. il faut maintenant tester et trouver les bonnes solutions logicielles pour y transférer les différents types de données et les utiliser. Il existe plusieurs usages possibles, de la sauvegarde pure s’un serveur ou d’un NAS, voire d’une sauvegarde secondaire hors site pour des questions de sécurité ou de données qu’il faudra pouvoir exploiter en direct. Pour une reprise après incident il faudra prendre en compte le temps de téléchargement pour rapatrier rapidement un gros volume de données. Ce temps est bien sur étroitement lié à la bande passante disponible sur le site. Donc oubliez ces solutions si vous devez vous contenter d’une ligne internet famélique et que vous avez un gros volume à traiter.

Comme Wasabi est compatible S3 on peut jouer avec tous les outils initialement proposés pour AWS S3, j’en ai testé des douzaines mais je n’en citerais ici que quelques un.

Transfert et exploration de fichiers

  • RClone : C'est le couteau suisse. Et combiné à RClone Explorer c'est la solution idéale qui répond à quasiment tous les besoins en ligne de commande.
  • Synology Cloud Sync : Idéal avec un NAS de la marque. Sauf qu'il oublie parfois des fichier, notament sur OneDrive.
  • DragonDisk : Un explorateur gratuit mais lent qui peut dépanner.
  • CyberDuck : Un peu plus rapide mais impose un MD5 lent. Evolutions à évaluer.
  • Filezilla Pro : Compatible S3 et autres clouds c’est une bonne solution qui ne changera pas les habitudes.
  • Bvckup : le must pour de la synchronisation locale n’est pas adapté à ce genre de situation (uniquement SMB et pour l’instant mais des évolutions sont prévues).
  • CloudBerry Explorer : Ça c’est la bonne surprise : 30/70 MB/sec en up sur Wasabi en S3, un peu moins sous OVH en OpenStack, et encore moins sur OneDrive Business mais ça reste le plus rapide. Autant dire que ça change tout car dans tous les cas c’est la solution la plus rapide pour faire du UP, quel que soit la destination !

Sauvegardes

Plusieurs combinaisons existent et si l’on dispose d’un NAS Synology on peut sauvegarder les serveurs et PC avec Active Backup, ou Veeam et ensuite uploader tout ça vers le cloud avec Cloud Sync ou Hyper Backup…

  • Pour sauvegarder directement un PC, un Mac ou un serveur vers du S3 j’ai trouvé ARQ Backup particulièrement efficace et simple. Mais il existe plein solutions comparables.
  • Pour sauvegarder des NAS Synology j’avais testé Synology C2. C’est bien emballé et pas très cher avec historisation, cryptage et déduplication. Si on cherche à restaurer sur un nouveau Synology c’est très bien et on peut restaurer avec une bonne granularité (fichier, ou arbo, ou sous arbo à une date donnée. Sauf qu’en cas de crash on a rarement un second NAS sous la main avec les bons disques et on peut avoir besoin rapidement de certains fichiers. Synology à donc prévu une interface web de restauration qui hélas ne permet que de restaurer individuellement les fichiers, et d’après leur support ils n’ont pas de plans à court terme pour faire mieux. Et ça se comprend, leur recommandation étant d’acheter un nouveau NAS, d’en avoir deux et surtout d’utiliser C2 Disaster Recovery qui permettra de virtualiser le NAS sauvegardé dans leur DC. C’est top mais là on ne joue plus dans la même cour coté tarifs. Mon alternative consiste à sauvegarder vers Wasabi avec HyperBackup. En cas de besoin on peut restaurer avec Hyperbackup et si ce n’est pas possible on peut toujours accéder aux données via un CloudDrive et de lancer HyperBackup Explorer sur PC pour restaurer et décrypter ce que l’on veut depuis Windows, MacOS ou Linux.

Synchronisation

La synchronisation va permettre de disposer sur le cloud de données directement exploitables, contrairement à la sauvegarde qui chiffre et historise les données. C’est un usage différent pour des données bien souvent différentes. Si certaines solutions comme CloudBerry sont utilisables de façon interactive, CloudSync sur Synology est ce que j’ai trouvé de plus efficace pour maintenir un volume de données conséquent synchronisé entre un NAS et S3. CloudSync sait utiliser pratiquement tous les fournisseurs. On peut également s’en servir en mode transfert pour uploader des répertoires que l’on supprimera ensuite, il y a beaucoup d’options possibles. Et bien sur il ne faut pas oublier RClone !

Utilisation en direct

Au-delà des sauvegardes dont la restauration est ponctuelle et des transferts de fichiers que l’on pourra effectuer avec les logiciels vus plus haut, il peut être intéressant d’accéder directement aux fichiers comme s’il s’agissait d’un simple volume sur le réseau local. Et c’est là qu’interviennent les « cloud drive ». Contrairement aux clients OneDrive, Google drive ou Dropbox, les « cloud drive » ne font pas de synchronisation locale mais rendent disponible directement les fichiers distants.

  • ExpandDrive : des gens du Mac qui font du Windows, joli mais ça déconnecte, la fille du support est très gentille et doit savoir faire du bon café…
  • NetDrive : j’avais acheté et eu des résultats mitigés. La mise à jour coûte le prix de ce que j’avais alors payé.
  • StableBit : je le cite car parfait et très intéressant pour créer un volume sécurisé dans un cloud, mais ça ne correspond pas au besoin.
  • MountainDuck : c’est ce que j’ai trouvé de plus solide en S3 sur Wasabi,  OpenStack Swift, mais aussi en WebDav. En plus on peut facilement partager des liens de fichiers depuis l’explorateur Windows qui seront téléchargeables depuis la source en https sur un temps limité.  La licence est abordable et permissive, elle permet d’utiliser le logiciel sur plusieurs machines des lors que c’est le même utilisateur.
  • CloudBerry Drive S3 : à tester, mais il n’est compatible que S3 ce qui peut être restrictif. Si les performances sont aussi bonnes que CloudBerry Explorer les 79$ de la version serveur peuvent être un bon investissement pour utiliser Veeam sur Wasabi en attendant une solution intégrée.
  • RClone : Il permet de monter un volume distant directement sur Linux, sous Windows il faudra ajouter WinFSP et on pourra également servir de RClone Tray.
  • Pour Google Drive le plus simple, efficace et gratuit consiste à utiliser Google File Stream qui travaille online / offline et conserve un cache et un index. 

Je ne conseille pas trop de faire des travaux complexe directement sur les fichiers ainsi accessible. Mais en lecture ou en streaming direct ou via Emby ou Plex c’est parfait.

Débits

J’ai fait quelques tests ponctuels en upload pour me donner une idée (CloudSync, CloudBerry, etc.). En download les débits sont à minima identiques mais bien souvent plus importants.

  • Up Online DC vers Wasabi S3 : 30/90 MB/sec
  • Up Online DC vers OVH OpenStack : 30/40 MB/sec
  • Up Online DC vers Google Drive : 80/100 MB/sec (RClone)
  • Up Online DC vers OneDrive Business : 3/30 MB/sec (par beau temps) ce n’est pas non plus sur le papier une solution comparable, juste un détournement.

Réflexions

  • SMB 3. On n’y pense pas toujours, mais on peut utiliser SMB 3 via Internet afin de permettre à un PC ou serveur d’accéder à un NAS avec d’excellents résultats entre un NAS (j’ouvre le port 445 sur le NAS et via le firewall je limite la connexion à l’IP de la machine cliente). Ça peut aussi être une bonne solution pour du backup.
  • Cloudberry Labs à des solutions de sauvegarde Cloud qui peuvent être intéressantes car ils savent très bien gérer le débit sur le cloud.
  • Veeam propose une solution packagée nec plus ultra de sauvegardes de VM. OVH est partenaire. C’est très bien, mais rapidement coûteux. (15 € VM à 1 TO max). Depuis le 9.5 U4 on peut également exporter les anciennes sauvegarde vers du S3.
  • Veeam (9.5 update 4) est en 2019 compatible S3 et OpenStack ce qui va changer la donne…
  • NetBalancer est une découverte intéressante pour voir ce qui se passe sur un serveur exposé. La version freeware est suffisante.
  • Google Drive comme OneDrive convertissent les vidéos de façon à ce qu'elles soient lisibles sur les clients web, sans altérer les originaux (à vérifier).
  • De façon générale je recommande RClone pour transférer de gros volumes...

Voilà, vos réflexions et observations sont bienvenues...

Surtension POE sur AP Unifi

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

SSL mi amor… & pfSense

On ne vantera jamais assez les mérites d’un reverse proxy en termes de sécurité. Mais au-delà de la sécurité, un reverse proxy peut aussi nous faciliter la vie pour la publication de services web en mode sécurisé, et donc la gestion des certificats.

Si selon le niveau de protection et d’assurance il faudra continuer à acheter des certificats hors de prix, dont la sécurité a parfois été corrompue même chez les soi-disant plus sérieux fournisseurs, pour bien des services l’utilisation de certificats Let’s Encrypt fera parfaitement l’affaire.

Au passage vous noterez que si j’étais fan de Sophos XG, je suis en train de m’orienter vers pfSense que je trouve bien plus simple et mieux documenté par la communauté.

Il y a plusieurs façons d’utiliser Let’s Encrypt :

  • Via un script ou un logiciel installé sur le backend (le serveur web) qui génère le certificat, il faudra ensuite l’exporter manuellement ou via un script vers le reverse proxy si on en utilise un en frontal, mais on peu aussi passer en direct, en NAT ou une simple redirection de ports.
  • Via un script géré par le firewall / reverse proxy. C’est ce que je vais décrire ici en utilisant pfSense ou j’installerais les paquets Acme et HAProxy.

Acme

Automated Certificate Management Environment, for automated use of LetsEncrypt certificates.

Cette implémentation très complète va nous permettre de générer et renouveler automatiquement des certificats Lets’s Encrypt (Standard, Wilcard ou San) et de les installer dans pfSense. Cette implémentation sait s’appuyer sur les API des principaux DNS, ce qui nous évitera d’avoir à ouvrir un port 80 comme cela était nécessaire auparavant. Le plus simple sera de générer un wilcard : *.domaine.tld.

Il sera également possible d’exporter ces certificats, manuellement, ou via un script vers un serveur web si nécessaire (par exemple, un script PowerShell sur un serveur Exchange pour récupérer les certificats, les installer et les activer).

Dans notre exemple on n’exporte rien car on va se servir de HA Proxy comme Frontend, c’est à lui qu’incombera la gestion du SSL (le SSL Offloading consiste à déporter la gestion du SSL sur le reverse proxy / load balancer, et donc sur le serveur web on ne laisse que le service HTTP, les sessions HTTPS n'étant cryptées qu'entre l'internaute et le reverse proxy qui peut également jouer un rôle d’équilibreur de charge si nécessaire).

HA Proxy

The Reliable, High Performance TCP/HTTP(S) Load Balancer.

Il s’agit ici d’un reverse proxy moderne qui permet également d’équilibrer la charge vers plusieurs Backends.

On aurait pu utiliser le paquet Squid, mais je lui reproche de ne pas gérer SNI (à vérifier) et donc de ne pouvoir servir plusieurs domaines en SSL. Squid est toutefois plus simple et fera l’affaire pour une installation simple ou domestique. A noter également que tant HA Proxy que Squid permettent de publier un serveur Exchange, et donc de remplacer avantageusement de vieux ISA ou TMG que Microsoft nous a tant vanté avant de les oublier…

Je ne vais pas reprendre un fastidieux steep by steep de publication il y en a de très bien faits… mais juste résumer :

  1. Installation de pfSense (il y a des VM toutes prêtes) avec un lien WAN et un lien LAN. On peut éventuellement ajouter des IP virtuelles (VIP) coté WAN si on en dispose.
  2. On crée une règle sur le firewall ou on autorise le port 443 (HTTPS) en entrant sur le WAN.
  3. Sur HA Proxy on crée un Backend avec l’IP interne sur le port 80 (ou autre) et sans SSL (sans car on pourrait également sécuriser le flux interne). Dans les options de LoadBalancing on choisit None si on a qu’un Backend, et dans ce cas on n’oublie pas de choisir également None au niveau Health checking. Et c’est tout, le reste si on ne sait pas, on ne touche pas.
  4. Sur HA Proxy on crée un Frontend qui écoute sur le port WAN (ou VIP), on coche SSL Offloading et plus bas dans SSL Offloading on choisit le certificat lié au domaine que l’on va utiliser (une règle Frontend par domaine géré). Dans Default backend, access control lists and actions on va gérer nos serveurs en utilisant l’expression Host Matches et la valeur, par exemple canaletto.fr que l’on nomme www (inutile si on n’a qu’un seul serveur à sécuriser). Ensuite plus bas dans Actions on va dire que la condition www est redirigée vers le Backend idoine. Ici aussi, c’est tout, le reste si on ne sait pas, on ne touche pas, car comme vous pourrez l’observer HA Proxy dispose d’une multitude d’options qui ne seront utiles que dans certains cas.

Test

Pour tester ce genre de configuration l’idéal est de disposer une machine connectée sur l’internet en dehors de votre réseau. La machine d’un ami en remote (TS, TeamViewer, NoMachine ou AnyDesk) ou encore une machine connectée en 4G.

Comme à ce stade on n’a probablement pas encore renseigné le DNS public, le plus simple est de créer une entrée dans le fichier hosts (sous Windows le plus simple est d’utiliser HostMan). 

Ensuite on lance une session dans le navigateur et on vérifie que c’est vert et que le certificat est valide et correspond bien à celui utilisé. Si c’est le cas il n’y a plus qu’à s’occuper du DNS public.

Info

Vous imaginez bien que je n’ai pas creusé ce sujet uniquement pour publier un Jeedom. Au départ il s’agissait de publier des serveurs Microsoft Exchange avec des certificats SAN classiques et couteux, et quand on publie de l’Exchange on peut faire à peu près tout. Ensuite j’ai trouvé la gestion Let’s Encrypt tellement simple dans pfSense que je me suis dit que finalement cet outil embarqué dans une VM ou un petit Appliance pouvait d’adapter à toutes les situations, même les plus simples. Du coup je vais probablement remplacer Sophos XG et pourquoi pas également chez moi à la place ou à côté de l’USG qui est très bien pour le trafic sortant mais n’évolue pas trop et ne permet pas de faire du reverse proxy.

Sources

https://pixelabs.fr/installation-configuration-pfsense-virtualbox/https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-vmware-vsphere-esxi.html

https://www.aide-sys.fr/exchange-2016-haproxy-pfsense/
https://pixelabs.fr/installation-role-transport-edge-2016-partie-2/
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://www.supinfo.com/articles/single/6326-mise-place-serveurs-web-haute-disponibilite-avec-haproxy-pfsense
https://www.itwriting.com/blog/9592-publishing-exchange-with-pfsense.html
https://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense
https://forum.netgate.com/topic/99804/squid-reverse-proxy-for-multiple-internal-hosts
https://tecattack.ch/index.php/2018/12/10/pfsense-2-4-4-haproxy-reverse-proxy-multiple-http-server-ubuntu-16-04/
https://all-it-network.com/pfsense-reverse-https/
https://blog.devita.co/pfsense-to-proxy-traffic-for-websites-using-pfsense/

Mi Home Security Camera 360°

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…

Jeedom : Shelly

On en découvre tous les jours ! Je vais vous parler des équipements Wi-Fi Shelly. Il s’agit de micro-modules, avec un ou deux contacts, des modules au format DIN à insérer dans un tableau électrique, des contrôleurs RGBW ainsi qu’un capteur de température et d’humidité. Rien de bien neuf sur le soleil me direz-vous, mais contrairement aux équipements asiatiques habituels (Sonoff par exemple) qu’il faut flasher ou hacker en perdant au passage le mode de fonctionnement original, les équipements Shelley sont totalement ouverts, et si on souhaite les flasher en ESP Easy le constructeur fournit tout ce qui est nécessaire pour le faire. 

De base on dispose d’une application mobile qui permet la configuration et le pilotage. Un cloud (optionnel) pour un pilotage à distance sans box, la comptabilité MQTT, une API REST et il est bien sur possible de les piloter avec Google Home ou Alexa. Cerise sur le gâteau, ces produits fabriqués en Roumanie sont vraiment certifiés CE et les tarifs sont très attractifs (10 € le relais simple). 

Attention, c’est du Wi-Fi, donc il est impératif d’avoir un réseau Wi-Fi stable.

L’appairage se fait en quelques secondes avec l’application idoine, et des lors que les modules sont reconnus sur le réseau il est possible de terminer la configuration sur le serveur web intégré à ceux-ci. Etant donné que l’on va les exploiter avec une solution domotique externe, Jeedom en l’occurrence, je ne saurais trop conseiller de leur attribuer une IP fixe. Si cela est possible dans la configuration web de chaque module, personnellement je préfère me servir de mon serveur DHCP.

Pour exploiter ces modules en domotique il y a la possibilité MQTT, il doit être également possible de passer des commandes http aux modules, mais je n’ai pas testé car il y a un plugin qui fait très bien le job et qui permet de conserver la compatibilité avec l’application mobile du constructeur. Ce plugin est simple et efficace, pour chaque équipement il suffit de renseigner l’adresse IP et ensuite d’utiliser l’équipement.

Attention toutefois au module capteur de température et humidité, il fonctionne sur pile et se mets en veille, le plugin n'est de ce fait pas toujours capable de récupérer les valeurs et les relevés sont donc trop espacés.

Je trouve ces modules intéressants à plusieurs titres. La simplicité, des tarifs attractifs pour un matériel de qualité, le format DIN et une puissance admissible compatible avec la plupart des radiateurs. A prendre en compte pour remplacer par exemple des équipements Chacon au comportement parfois aléatoire, bref un pas de plus pour l’élimination du RFPLayer…

Sources :

https://lunarok-domotique.com/2019/01/shelly-1-domotiser-prise-10-euros/