Redirection de port sous Linux : 2/2

Dans la partie précédente, en bon béotien, j'ai exploré pas mal de techniques de redirection de port, mais j'aurais du commencer par l'exploitation de ce qui est depuis un certain temps de base sans Linux, à savoir IPTables.

Pour cette manipulation on va utiliser un routeur Ubiquiti ER-X avec la dernière version de EdgeOS (2.0.9-hotfix.2). Et sur ce routeur on va commencer par y installer Wireguard (pour changer un peu, mais Zerotier ou les VPN disponibles de base auraient pu faire l'affaire).

On va se rendre compte que la philosophie de WireGuard est bien différente de Zerotier (ou même de TailScale). Ici il faut tout borner, c'est la version barbus et les ACL ne se gèrent pas sur une console d'admin, il faudra pour ça utiliser le firewall du point d'entrée, ce qui à mon gout est bien moins souple et rend impossible certaines restrictions plus granulaires au niveau de l'utilisateur client...

Je ne suis pas expert, mais contrairement à Zerotier ou le client génère un ID propre à la machine, sous WireGuard un simple copié collé suffit à exporter et utiliser la configuration ailleurs... On peut certes utiliser une clé supplémentaire (PresharedKey), mais ça ne changera rien. Un mot de passe qui se transmet vocalement aurait été préférable. Cela ne sera pas trop gênant dans une configuration fermée (la mienne, un serveur verrouillé vers un routeur qui sera tout autant), par contre dans le cadre de l'utilisation pour un utilisateur lambda itinérant et souvent inconscient cela pose question, tout comme le non support apparent d'une clé physique...

WireGuard coté serveur :

On se connecter en SSH et on installer la dernière version que l'on va trouver ici avec les commandes suivantes :

curl -OL https://github.com/WireGuard/wireguard-vyatta-ubnt/releases/download/1.0.20210606-1/e50-v2-v1.0.20210606-v1.0.20210424.deb
sudo dpkg -i e50-v2-v1.0.20210606-v1.0.20210424.deb

Attention à bien remplacer par la dernière version et faire attention car il existe des versions spécifiques à chaque modèle de routeur et pour chaque version de EdgeOS (v1 et v2).

Si on manque de place (df) on fait un show system image et on efface celle qui ne sert à rien après une mise à jour avec un delete system image. Et oui il y a du vécu.

Quand WireGuard est installé on va générer nos clés :

sudo wg genkey | tee /dev/tty | wg pubkey

Ce qui va nous donner deux clés, la première est la clé privée, la seconde la clé publique.

0GbmWkPkYB9y2s5aIaAxUrAPoSnsDFnuhHjRnujEsm8=
KsVzrtWPGWDbuCLPUyTsTL6pQOfiS+96VOXsMnPo+SI=

On sauvegarde ces clés au chaud et on passe à la configuration de l'interface CLI propre à EdgeOS (configure, commit, save et exit)

configure

On y associe un subnet privé, un port UDP et la clé privée :

set interfaces wireguard wg0 address 192.168.33.1/24 # Ici on choisit l'IP de notre serveur WireGuard
set interfaces wireguard wg0 listen-port 51833       # Ici le port UDP qu'il conviendra de redirigier si on est pas en Bridge ou DMZ...
set interfaces wireguard wg0 route-allowed-ips true  # Pour sortir de ce subnet....
set interfaces wireguard wg0 private-key 0GbmWkPkYB9y2s5aIaAxUrAPoSnsDFnuhHjRnujEsm8=

On va ensuite déclarer les pairs (peers) autorisés en associant notre interface à leur clé publique et une IP autorisée. 

set interfaces wireguard wg0 peer N4cuA0WPkMt+3hfidlemsI/VGcupv96NtrkwA/esf2E= allowed-ips 192.168.33.2/32
set interfaces wireguard wg0 peer u2w/+ZNI2RwbYTdft9yggPGnff8QexY9UjjvdvVf0gM= allowed-ips 192.168.33.3/32

On ajoute une règle sur le firewall (Il est également possible aussi de faire ça depuis l'interface du routeur)

set firewall name WAN_LOCAL rule 20 action accept
set firewall name WAN_LOCAL rule 20 protocol udp
set firewall name WAN_LOCAL rule 20 description 'WireGuard'
set firewall name WAN_LOCAL rule 20 destination port 51833

Et on termine par :

commit
save
exit

Il est bien sur possible de faire ça en plusieurs fois, mais dans ce cas là il ne faudra pas oublier de rentrer dans le CLI propre à EdgeOS (configure, commit, save et exit).

Si je fais un scan des ports coté WAN, je ne dois rien voir le seul port ouvert étant le 51833 en UDP.

WireGuard coté client

Le client peut être sous n'importe quel OS, dans mon cas ce sera Windows et on va faire la configuration manuellement (il y a moyen de préparer des fichiers de configuration à importer pour un déploiement conséquent). Plus haut on a ajouté la clé publique fournie par le client dans les pairs autorisés. Cette clé est propre à chaque tunnel défini coté client. Idem pour la clé privée du client que l'on reporte ci dessous, elle est crée lors de l'ajout d'un tunnel sur le client. Ensuite on renseigne le pair du client, c-a-d le serveur que l'on a créé plus haut, sa clé publique, les IP autorisées pour ce tunnel ainsi que l'IP ou le TLD du serveur.

[Interface]
PrivateKey = IIczTA5sdrdcg4+VQNnudslgnveoR5ZDD3ZyL0ZXonU=
ListenPort = 15092
Address = 192.168.33.2/32

[Peer]
PublicKey = KsVzrtWPGWDbuCLPUyTsTL6pQOfiS+96VOXsMnPo+SI=
AllowedIPs = 192.168.33.0/24
Endpoint = 69.69.69.69:51833
PersistentKeepalive = 25

Ensuite on active le tunnel et normalement à ce stade on doit pouvoir faire un ping sur l'IP LAN du routeur distant (notre serveur WireGuard) ainsi que les IP de son subnet pour peu que les routes inverses soient configurées.

Si sous Linux l'activation / désactivation d'un tunnel en CLI coule de source, il m'a fallut un peu chercher pour Windows. Mon but étant de permettre à une application de supervision d'éventuellement réactiver un tunnel cas de défaillance.

Donc pour activer un tunnel,  CMD en mode admin... (-h pour en savoir plus..) :

C:\>"C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice "C:\Program Files\WireGuard\Data\Configurations\Nom du Tunnel.conf.dpapi"

Et pour le désactiver :

C:\>"C:\Program Files\WireGuard\wireguard.exe" /uninstalltunnelservice "Nom du Tunnel"

Pour information et pour les afficionados, on peut très bien installer un serveur WireGuard sous Windows, les explications sont ici, ce n'est pas officiellement supporté et ça a l'air bien plus compliqué.

Sauf que dans le cas qui me préoccupe je ne peux justement pas disposer des routes inverses pour une question de sécurité chez mon client. La seule IP autorisée sera l'IP LAN du routeur. Il faut donc que les services que je doit joindre me reconnaissent avec cette IP. Et c'ets ici qu'interviennent les IPTables.

IPTables

Pour utiliser les IPTables il n'y a rien à installer car cela fait partie de l'O/S. Ca tombe bien car sur ce routeur la place est limitée. Par contre il faut que l'IP Forwarding soit activé, on peut vérifier avec sysctl net.ipv4.ip_forward qui va nous répondre net.ipv4.ip_forward = 0 ou 1 si c'est activé.

Ensuite, toujours en SSH : 

sudo iptables -F
sudo iptables -F -t nat
sudo echo 1 >| /proc/sys/net/ipv4/ip_forward  # En cas de besoin....
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to 192.168.169.22:25
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 8080 -j DNAT --to 192.168.150.20:80
sudo iptables -t nat  -A POSTROUTING -j MASQUERADE

Depuis le client on va faire pointer nos requetés sur la première IP de WireGuard à laquelle j'ai associé un serveur web sur 192.168.150.20 et un serveur SMTP sur 192.168.169.22. A noter que si le port de destination est bien sur le port sur lequel répond le service, le port source peut lui être identique ou défini différemment (surtout qu'en 80 on a l'interface du routeur...).

Maintenant, depuis mon client, le serveur web de destination répondra sur http://192.168.33.1:8080 et si je fais un telnet 192.168.33.1 25 j'obtiendrait la mire de mon serveur SMTP. Et ces deux derniers ne verront en IP source que l'IP LAN de mon routeur, donc une IP autorisée.

Mais on ne peut pas tout à fait aller dîner... En effet ces IPTables vont disparaitres  au premier redémarrage !

Persistance

Mon premier réflexe était d'utiliser le paquet iptables-persistent. Sauf que j'ai remarqué, que pour une raison que je n'explique pas, mais qui a certainement sa logique, il est impossible d'ajouter une règle au firewall (tout au moins depuis l'interface du routeur) dès lors que ces IPTables sont activées. Je vais donc créer un script qui se lancera au démarrage du routeur et que je pourrais désactiver au besoin... (si un barbu passe par la merci de me dire sil y a mieux à faire) :

sudo vi /etc/init.d/myfwd

Et dans ce fichier on va nos commande comme précédemment :

sudo iptables -F
sudo iptables -F -t nat
sudo echo 1 >| /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to 192.168.169.22:25
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 8080 -j DNAT --to 192.168.150.20:80
sudo iptables -t nat  -A POSTROUTING -j MASQUERADE

Mais, car il y a toujours un mais. Il se peut que la résolution DNS ne se fasse pas au lancement. Donc si vous devez obtenir l’adresse IP à partir d’un nom de domaine, vous devez utiliser dig que vous obtiendrez avec :

sudo apt-get install dnsutils

Ensuite il faudra modifier légèrement le script...

sudo IP_ADDR=$(dig +short smtp.mondomaine.com| awk 'NR==1') 
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to $IP_ADDR::25

Voilà !

EDIT 25/09/2021: La bonne nouvelle c'es que Free a ajouté WireGuard dans ses Freebox et que ça fait tout le travail... Quand on a une Freebox bien sûr !

Unifi UDM Pro, ZT, encore...

Longtemps j'ai disposé de deux lignes vDSL à 90 MB en étant proche du DSLAM. Il y avait un peu de bricolage, la Freebox en bridge sur le WAN1 de l'UDMP et Nerim en NAT entre le WAN2 (secours) de l'UDM Pro et vie le LAN sur un subnet différent sur MPTCP et OTB. Je sais, pas très propre, mais c'est juste un labo... Et c'est pourquoi on va optimiser un peu, d'autant plus qu'entre temps je me retrouve avec une fibre SFR et ma Freebox Révolution migrée elle aussi en fibre.

Versions utilisées, relativement stable par rapport à ces derniers mois :

  • UDMP : 1.10.0
  • Network : 6.4.47

Swap des ports WAN de l'UDM Pro

Avec l'idée migrer la Freebox Révolution vers une Delta S afin de profiter d'un lien à 8 GB, j'ai commencé par swapper la logique des deux ports Wan de l'UDMP. De base le port 9 en 1 GB (RJ45) correspond à WAN1 et le port 10 en 10 GB (SFP+) à WAN2. On peut se demander ou est leur logique tant il est évident que le lien principal sera plus performant que le lien de secours. Depuis je ne sais plus quelle beta il est possible d'inverser cette logique, mais attention il reste un bug de taille, le nom du provider (probablement lié à l'ASN) ne sera pas mis à jour et on reste avec ceux de base, et ça peut être déroutant. Comme on le voit ci dessous le port WAN1 avec la Freebox remonte OwCloud (anciennement Nerim racheté par BT), alors que le WAN2 est maintenant branché sur du SFR...). Ce bug est connu, mais comme d'autres il ne semble pas être dans les priorités des équipes Unifi qui préfèrent surement se concentrer sur une nouvelle version de l'interface...

Passer mon mélange de subnets en VLAN

C'est logique, il faut juste trouver un peu de temps. Et on va voir que du temps j'en ai perdu.

Pour créer un VLAN sur Unifi c'est dans l'absolu très simple. On crée un nouveau réseau et dans les paramètres avancés on choisit un VLAN ID et éventuellement le subnet et le mode DHCP, mais on peut faire sans et dans certains cas laisser faire l'Auto Scale Network. Ensuite on associe ce réseau à un port du switch. Sauf que j'ai passé des heures à chercher à faire compliqué car ça ne fonctionnait pas. Et finalement je me suis résolut à un reboot et là ça passe tout seul. Allez donc savoir...

Dans mon cas je voulait un VLAN sur un subnet particulier avec DHCP. Mon objectif étant d'y coller la box SFR qui sera branchée sur le WAN2 et sur ce VLAN et ainsi sera utilisable par mon fils pour ses jeux qui disposera ainsi d'une fibre rien que pour lui et sans aucune restrictions (il est grand !) et sans venir perturber la QoS du réseau principal, même si l'impact sera moindre via que fibre qu'il ne l'était en xDSL.

Sur le subnet de ce VLAN, la passerelle par défaut est donc la box SFR, comme c'est le cas sur le WAN2 de l'UDM. Les deux usages cohabitent, et la box de secours sert à quelque chose...

On peu ensuite créer un réseau WI-FI sur ce VLAN ou taguer des ports sur les switch (port profile) pour qu'ils l'utilisent.

On verra plus tard comment créer un VLAN dédié à l'IoT et surtout comment ouvrir ou bloquer le trafic entre les VLAN.

UPnP mon amour !

Toute cette partie fonctionnelle, je me suis aperçu que mon routeur VPN/SDN Zerotier (un Linux dans une VM) avait un peu de mal à sortir. Dans la configuration précédente il sortait en NAT via ma ligne de secours. Dans ma nouvelle configuration il doit sortir via l'UDMP, et le vas échéant profiter du secours. Curieusement j'ai remarqué que le passage en mode secours était lent et qu'au retour certaine destinations n'étaient pas joignables, bizzarement celles situées sur le réseau Free, Online Sacaleway pour être précis, alors que d'autres distants passaient. Et c'est critique.

On lance la commande :

[email protected]:~# zerotier-cli peers

Et l'on obtient la liste des clients distants :

1d20dgr3f3 1.6.5  LEAF      -1 RELAY
2533gtdaef 1.6.5  LEAF      -1 RELAY
338fgte636 1.4.6  LEAF      13 DIRECT 7131     2944

Si DIRECT veut dire que tout va bien, RELAY indique que le distant est injoignable directement, que le trafic va transiter par les serveurs Zerotier. Et que quand le trafic passe, ce qui n'est pas toujours le cas, cela va induire une latence aléatoirement plus importante, au minimum 35 ms. là ou en direct on passera à 12 ms. Et justement, au delà de remplir les poches des Telcos, l'un des objectifs de la fibre est de réduire la latence (même si avec le l'IPV4 encapsulée dans de l'IPV6 on en perd un peu, mais c'est un autre problème et il faudra se pencher sur du full IPV6).

Après moultes recherches j'ai trouvé que 

  1. Que l'UDMP bloquait peut être certains ports en sortie, même si on désactive toute la partie sécurité et que tout est autorisé sur le firewall (pas clair !)
  2. Qu'il est possible de configurer des ports UDP secondaires sur un client (en plus du port UDP natif 9993.

On commence donc par configurer un port secondaire (on ne touche surtout pas au primary (voir ce fil vers la fin) sur le client qui me sert de routeur ZT en créant un fichier local.conf dans le bon répertoire (détails ici) :

{
  "settings": {
    "secondaryPort": 21234
  }
}

Mais visiblement ça ne suffit pas et il va falloir activer l'UPnP pour que tout passe en direct avec un minimum de latence :

Je ne suis pas fan de l'UPnP/NAT-PMP car ce protocole d'automatisation ouvre par définition les ports à la demandes des applications. Applications qui sur un réseau peuvent êtres malveillantes. Pourtant à la maison ce service est très utilisé et quasiment indispensable. Par contre hors de question d'utiliser cette méthode en entreprise ou une règle WAN_LOCAL avec la destination UDP 9993 devrait faire l'affaire (pas clair et à creuser). (ici pour pfsense avec ACL en prime, ce qui va aider en entreprise).

ZT Failover ?

Alors là on rentre dans le coté obscur. Tant qu'à avoir deux fibres autant qu'elles servent à quelque chose. Visiblement l'UPnP de l'UDM Pro est archi buggé. Je me suis donc dit que j'allais faire le failover directement dans le routeur Zerotier. J'ai donc ajouté une carte réseau virtuelle à ma VM ZT qui me sert au routage Lan to Lan (ici et pour monter ça) sur le VLAN 110 qui correspond à la box SFR. Les deux interfaces ont une passerelle par défaut avec le même poids. 

Ensuite on édite le fichier local.conf et on ajoute et on ajoute ces paramètres : 

{
  "settings":
  {
    "defaultBondingPolicy": "active-backup",
    "peerSpecificBonds":
    {
      "f6dd3a2db3":"active-backup",
      "1d20ff53f3":"balance-xor",
      "a92cbsd6fa":"broadcast"
    }
  }
}

Pour comprendre les différentes possibilités on ne trouve pas beaucoup d'information si ce ne sont deux docs officielles ici et ! A croire que ce sujet intéresse peu. Attention, j'ai eu pas mal de difficultés en éditant avec Nano ce fichier avec un copié / collé. Peut être une question de formatage qui m'aurait échappé. Par contre je n'ai pas réussit à associer dans ces paramètres le port secondaire.

Toujours est-il que si je débranche un interface l'autre prend le relais en mode active-backup avec une légère interruption que quelque secondes ou encore plus rapidement en mode broadcast. Mais ce dernier mode semble déconseillé car il génère pas mal de garbage...

Design

Si j'étais un cador en Visio ou d'autres outils en ligne comme draw.io ou autres, je pourrais vous faire un joli dessin, mais ce n'est pas le cas. Donc :

  • WAN1 : Freebox en mode bridge (je voulais tester la Freebox Pro mais elle n'a pas ce mode).
  • WAN2: Secours en NAT sur une box SFR. NAT également accessible sur les ports tagués en VLAN 110 sur un subnet dédié et isolé. Cela permet à mon fils de jouer et faire ses bricolages sans impact sur la sécurité du LAN principal.
  • VPN vers les sites distants accessible depuis le LAN principal. On verra plus tard comment profiter des fonctionnalités Multipath / Bonding de Zerotier qui vont nous permettre d'utiliser le lien de secours sans passer par celui de l'UDM.

Vieilleries...

Et dans tout ça que devient mon installation openMPTCP ? L'objectif de cette installation était d'agréger plusieurs lignes afin de fiabiliser et d'augmenter le débit disponible. Si la question du débit se pose en en xDSL elle ne se pose plus avec une fibre. Quant à la fiabilité il faudrait pour que ça ait du sens disposer d'un VPS puissant avec un lien 10 GB. Et encore on aurait malgré tout une latence dégradée. 

Mais je vais tout de même tenter la chose pour le sport. Pour ca il faut que je crée sur mon ESXi une nouvelle interface sur le VLAN 110 afin d'accéder au NAT de la ligne de secours et éventuellement le modem 4G. L'objectif n'est pas la performance, je ne toucherait donc rien coté VPS, mais juste d'éviter le lag qui se produit quand l'UDMP passe sur le lien de secours. Mais ça reste très rare et je ne sais pas si le jeu en vaut la chandelle. Peyt être pour l'IoT.

 

 

TailScale, VPN/SDN simplifié

Avant, il y avait les VPN (PPTP, IPSec, OpenVPN, etc...) qui ne sont pas toujours très simple à implémenter. Et puis arrivent les SDN, qui dans l'absolu sont des VPN, orientés réseaux étendus et très simples à mettre en œuvre. D'aucun le savent, je sus un fan de Zerotier que j'utilise au quotidien, tant pour interconnecter 4 sites à la place d'IPSec, que pour des machines distantes ou quand je suis en déplacement.

Entre temps les barbus nous ont beaucoup parlé de Wireguard, qui peu ou prou fait la même chose en un peu plus compliqué avec de soit disant meilleures performances. Et puis arrive TailScale qui lui est basé sur Wireguard et lui apporte la simplicité. Une sorte de Wireguard pour les nuls, enfin, pas que, car TailScale apporte à WireGuard la notion d'annuaire qui lui manque (WG-Dynamic en cours de dev.). Comme pour Zerotier, au delà d'un certain nombre de nodes il faudra passer à la caisse, mais les tarifs sont comparables, tout comme les possibilités offertes par la version gratuite suffisante pour un usage home.

Comme pour Zerotier, il est possible :

  1. D'accéder depuis internet à une machine particulière avec un client dédié (MacOS, Windows, Linux, IOS, Android).
  2. D'accéder depuis internet à un sous réseau dès lors que l'on installe un node Linux qui servira de routeur
  3. D'accéder depuis internet à internet de façon sécurisée en passant par un node Linux installé en mode Exit-Node, chez vous ou sur un VPS.
  4. D'accéder depuis chez vous à d'autres sous réseaux, bon là c'est plus compliqué et il faudra passer à la caisse et avantage à Zerotier (ou Wireguard, mais je n'ai pas testé).

Le gros avantage de Zerotier est que l'on travaille en Layer-2 sur un subnet dédié avec la possibilité de figer des IP là ou TailScale affecte des IP aléatoires et travaille en Layer-3. Mais les deux peuvent cohabiter, et ça peut être intéressant dans certains cas. Vous trouverez ici un comparatif des deux solutions.

Ce qui est certain, c'est que si moi j'y trouve des limitations, TailScale a pour lui une simplicité qui en fera un bon choix pour ceux qui débutent et veulent juste un usage limité. On va donc se consacrer aux trois premiers points d'usage.

Accéder depuis internet à une machine distante

Je ne vais pas vous expliquer comment créer un compte (il suffit d'aller sur leur site), ou comment se faire coucou entre deux machines clic clic (MacOS, Windows, IOS ou Android), il suffit de lancer l'installation et de faire un ping. Par contre je vais le faire pour la machine Linux qui nous servira dans les deux cas qui suivent.

On part du principe que la machine existe dans sa config minimale et qu'elle communique avec Internet. On en fait un client Tailsacle, ça se passe ici et c'est un peu différent selon les distributions. J'utilise Ubuntu et on commence par ajouter les clés et le repository :

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.gpg | sudo apt-key add -
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.list | sudo tee /etc/apt/sources.list.d/tailscale.list

On fait les mise à jour et on installe :

sudo apt-get update
sudo apt-get install tailscale

On lance le client et on copie l'url pour l'autoriser :

sudo tailscale up

Et voici notre IP :

ip addr show tailscale0

A ce stade si on a un autre client TailScale on peu faire un ping... A noter que sur la console d'admin on va pouvoir définir si la clé expire ou pas...

Si votre but est d'accéder à Home Assistant, il existe un addon qui fera le travail pour vous.

Accéder depuis internet à un sous réseau

Afin de ne pas devoir installer TailScale sur toutes vos machines, et surtout accéder à celle ou il n'est pas possible de l'installer (IoT par exemple), on va installer une machine en mode routeur. Pour l'instant ce n'est faisable que sous Linux, avec un petit RPI ou une VM par exemple... On continue sur la même machine.

Première chose on active l'IP Forwarding :

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

Ensuite on active le routage du subnet :

sudo tailscale up --advertise-routes=192.168.210.0/24

Et pour terminer on va dans la console d'admin indiquer que cette machine servira de routeur pour ce subnet (sous réseau) (les ... au bout de la ligne) :

A partir de là un client TailScale pourra accéder à ce sous réseau.

Accéder depuis internet à internet de façon sécurisée

Quand vous vous connectez en WI-FI sur un hotspot public tout le monde vous dira que ce n'est pas très sécure et qu'il faut utiliser un VPN. Ici plutôt que de payer pour un VPN on va utiliser notre propre connexion, à la maison, ou encore dans un VPS. Pour ça on ajoute la fonction Exit-Node à notre machine :

sudo tailscale up --advertise-exit-node

Et on la configure de facon idoine au même endroit

Ensuite dans le client on choisit l'option Exit-Node afin que tout le trafic transite par notre nouveau point de sortie.

A noter que si l'in veut combiner les deux fonctions, subnet + Exit-Node la commande sera plutôt celle ci :

 sudo tailscale up --advertise-routes=192.168.210.0/24 --advertise-exit-node

Voilà, c'est pas plus compliqué, c'est gratuit et c'est sur. En parlant de gratuit sachez que Free a démarré une beta afin d'intégrer Wireguard dans les Freebox et que Wireguard tout comme Zerotier peut être intégré dans certains routeurs (Unifi, Asus, etc...) ce qui vous évitera la petite machine Linux. Mais ce n'est pas forcément aussi simple.

Sources :

 

NextDNS, une bonne alternative

Traditionnellement, et encore aujourd'hui, la grande majorité des utilisateurs se servent du DNS de leur fournisseur d'accès sans vraiment savoir de quoi il s'agit. Certains plus aguerris l'ont changé, enfin ceux qui peuvent car certains fournisseurs comme par Orange (lamentable sur ce point) rendent ce changement impossible sur les LiveBox. Mais il y a toujours moyen de contourner sur les appareils connectés ou mieux les navigateurs. Depuis peu les navigateurs modernes permettent de configurer un DNS sécurisé (DNS over HTTPS, DoH), et d'ailleurs dans les dernières version celui ci est déjà plus ou moins configuré.

Les choix :

  • Google : ça reste le premier choix alternatif que l'on retrouve. Donc au cas ou Google aurait loupé un de vos pas, il se rattrape en fournissant un DNS gratuit.
  • Cloudflare : on ne présente plus, certainement le plus rapide.
  • Quad9 : une autre initiative suisse, plus transparent et qui assure un filtrage de domaines malveillants...
  • La liste est longue et vous la retrouverez ici.

Pour aller un un peu plus loin on peut également utiliser un DNS filtrant à installer (et maintenir) sur son propre réseau. Il en existe principalement deux, Pi Hole et AdGuard Home. Je ne suis pas fan du premier, mais j'aime bien Adguard. L'inconvénient est qu'il faut une infrastructure minimale (VM, Docker, etc..) et que cela ne fonctionnera que sur un site. J'ai longtemps utilisé AdGuard, et comme tous les DNS filtrants on se retrouve parfois avec des faux positifs qui au final peuvent ralentir les flux.

L'intérêt d'utiliser un DNS filtrant réside principalement dans les points suivant :

  • Protection de la vie privée : confidentialité des requêtes, protection contre les trackers, suppression des publicités intrusives,
  • Sécurité : protection contre les menaces qui utilisent le DNS,
  • Contrôle parental,
  • Supervision.

NextDNS

Enfin, si je vous parle de tout ça c'est pour vous présenter NextDNS.

NextDNS est une offre hébergée qui combine les avantages d'un AdGuard Home et d'un DNS rapide accessible partout. L'avantage étant que je vais pouvoir l'utiliser sur plusieurs sites ou je me déplace, mais également en situation de mobilité.

Pour en profiter il est possible de changer (quand on peut) le DNS affecté au DHCP sur le routeur ou la box par ceux proposés par NextDNS. Mais pas que. Il est également possible de configurer DoH sur les navigateurs et les O/S Mobiles de façon très simple afin d'en profiter en situation de mobilité, sans pour autant avoir à modifier la configuration à chaque usage. Et pour ceux qui sont réfractaires à la technique, les service propose des applications pour tous les systèmes avec des guides très clairs proposés sur le panneau de contrôle de NextDNS.

Et oui car panneau de contrôle il y a, et c'est un gros plus offert par NextDNS. Outre les diverses configurations possibles on vas y retrouver des statistiques ainsi que la liste des requêtes que l'on a fait. Bien sur ces options sont facultatives, ces données ne sont présentes que pour vous et si on le souhaite NextDNS n'enregistrera simplement rien. Mais laissez les au moins un temps, histoire de vous faire peur en voyant le nombre de requêtes faites par vos appareils, ainsi que votre dépendance aux GAFAM's, c'est juste effarant ! (le graphique qui suit c'est juste 24 heures chez moi...).

Navigateurs

Si DNS over HTTPS fonctionne très bien sur Opera, Edge (Chromium MS) ou Firefox, la fonctionnalité est par contre bloquée sur ma machine avec Chrome et brave au motif que ces navigateurs seraient managés par une organisation. Ce n'est pas le cas, hormis le fait que ce PC fait partie d'un domaine Active Directory, sans toutefois de policies spécifiques à navigateurs. Pas de problème par contre sur MacOS ou sur d'autres PC hors domaine. Un point à creuser.

Aller plus loin en entreprise

Dans le cas d'un réseau d'entreprise ou d'utilisateur avancé on va donc aller changer le DNS sur le routeur ou le serveur DNS. Et si on est sur un domaine Active Directory, ce qui est mon cas, le DNS Windows est un passage obligatoire. Et là c'est le bug, car si Microsoft commence timidement à introduire DoH sur Windows 10, le DNS de Windows Server sur lequel repose Active Directory n'est toujours pas adapté à DNS over HTTPS ou DNS over TLS au niveau des redirecteurs (forwarders).

La seule solution est donc de passer en clair entre le DNS du serveur Windows et les IP de NextDNS. Et justement passer en clair est une des choses qu'on ne veut pas faire. Pour contourner ça NextDNS propose une sorte de proxy DNS sur lequel on pourrait faire pointer nos forwarders, une version graphique qui installe un driver TAP (en 2021 sérieux ?) et un client CLI qui ferait bien l'affaire mais ne fonctionne pas correctement. Clairement chez NextDNS Windows c'est pas leur truc et les explications et réponses aux questions que l'on trouve sur leur forum ou le GitHub en témoignent.

Pour l'expérience j'ai donc monté un AdGuard transparent dans un Docker qui pointe sur https://dns.nextdns.io/xxxxxx en DoH. Ca fonctionne en faisant pointer dessus le sforwarders de mon serveur DNS sous Windows Server. Je suppose que j'aurais pu faire la même chose avec un petit Linux et le client CLI, mais mon but était démontrer que ça tourne dans un environnement Windows d'entreprise. Après avoir perdu pas mal de temps à chercher des informations je me suis dit que ce CLI n'avait peut être jamais été testé sur Windows Serveur 2016/2019 et qu'il fonctionnerait peut être sur une vieille version de Windows, et banco ça fonctionne sur un Windows 2008R2 vintage... Sérieux ? Donc :

nextdns install -config 71fc72 -report-client-info -listen 0.0.0.0:53

Et ensuite on fait pointer du DNS Windows sur l'IP de ce serveur et c'est transparent pour les utilisateurs.

Une alternative pourrait consister à changer de DNS sur les clients (via le DHCP) et à les faire pointer sur le proxy DNS en précisent que les requêtes du domaine Active directory local pointeront bien sur le DNS AD. C'est possible, mais ce n'est pas ce que je conseillerais.

nextdns install -config 71fc72 -report-client-info -listen 0.0.0.0:53 -forwarder canaletto.fr=192.168.10.10

Dans l'absolu ce petit CLI est très bien fait, il est juste un peu bâclé en ce qui concerne l'environnement Windows. Par contre il s'installe en mode service et sera donc persistant.

Bonus

NextDNS permet de faire de la réécriture de DNS, une fonction qui sera intéressante quand on utilise un VPN/SDN comme Zerotier car cela de permettre de résoudre des nom de hosts internet sur des adresses IP privée, ce qui est théoriquement contraire aux RFC sur un DNS public (bien que certains come CloudFlare l'acceptent, ce n'est jamais une bonne idée de documenter ainsi une architecture interne).

Conclusion

Je ne vais pas détailler tout ce que les autres sites ont pu écrire, pas même insérer un lien d'affiliation qui pourtant existe.

Ce service est un peu jeune, mais il avance rapidement. il est le fruit de deux Français expatriés aux Etats Unis. Personnellement je suis séduit et je vous invite à le prendre en main.

NextDNS est un service qui peut être gratuit pour un usage Soho limité à 300.000 requêtes, ça peut être suffisant dans pas mal de cas, en ce qui me concerne j'en suis à 150.000 en 24 heures, mais il faut dire que j'ai un peu poussé la chose dans ses retranchements. La tarification est très accessible (2 € par mois ou 20 € par an pour l'utilisation que j'en ai) et il existe des offres destinées aux entreprises et à l'enseignement.

Enjoy ;-) (je mettrais à jour cet article au fil du temps... N'hésitez pas à revenir).

Sources

 

Installer Ghost sur aaPanel avec Docker

Il y a quelques semaines je vous avait vaguement expliqué comment installer aaPanel pour gérer un linux. Avec aaPanel on peut installer en quelques clics un site web, un Wordpress ou un autre CMS. Le hic c'est que celui que je veux tester n'est pas dans la liste, mais heureusement aaPanel gère les container Docker et justement Ghost est disponible préinstallé dans ce mode.

Je prends ici l'exemple de Ghost, mais ce qui suit s'applique à n'importe quel container d'application web.

Docker

Dans aaPanel vous pouvez ajouter Docker Manager depuis l'AppStore, celui-ci s'avèrera suffisant pour installer quelques containers, mais trop léger pour faire la majorité des manipulations. L'avantage à l'installer c'est que ça ajoutera au serveur tout ce qui est nécessaire de base pour Docker/

L'alternative consiste à installer Portainer qui lui offre une interface complète pour Docker, dans un container (il existe des alternatives).

docker volume create portainer_data
docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

Mais au final le plus simple est encore Docker Compose ou d'y aller directement en SSH, ou plus simplement avec le terminal intégré à aaPanel.

Il y a plusieurs choses importantes à paramétrer pour utiliser Ghost dans un Docker :

  • Le port que l'on restituera ou pas sur le host (la machine qui supporte Docker). Si on ne le configure pas Ghost sera uniquement accessible en local via l'IP du container (http://172.17.0.2:2368 par exemple) et non sur le réseau local et non sur le réseau local qui héberge le serveur. Sur une machine isolée, un VPS par exemple, ce n'est pas gênant car on servira de NGINX pour accéder au site en reverse proxy au passage gérer le certificat Lets'Encrypt. Par contre si le point d'entrée passe par un firewall sur une autre IP du LAN, il sera important d'exposer un port sur le host afin d'éviter le passage par un NGINX local, inutile dans ce cas.
  • Le second point consiste à paramétrer le répertoire qui contiendra les données (db, images, etc...) de notre site. Si on ne le fait pas Docker va créer un répertoire arbitraire pour y stocker les données du container tel que cela aura été défini par celui qui a créé le Docker (dans l'absolu ces données pourraient très bien rester dans le container, mais ce ne serait pas du tout une bonne idée). Sur un VPS on peut par exemple faire en sorte que les données soient dans un sous répertoire de l'utilisateur.
  • Enfin, et si l'on veut éviter d'avoir à le faire plus tard, il faut définir l'url du site que l'on va créer. C'est un point important car comme dans Wordpress, Ghost à besoin de connaitre l'url sur lequel il tourne pour la navigation. Si on ne le précise pas et que l'on redirige le site via un reverse proxy (par exemple : https://www.domain.tld > http://172.17.0.2:2368) cela semblera fonctionner mais certains liens seront incorrect puisqu'ils pointeront sur l'IP du container.

Mise en pratique

Création du container minimaliste :

docker run -d --name ghost ghost

Création du container avec la gestion des ports et de l'url :

docker run -d --name ghost -e url=https://www.domain.tld -p 3001:2368 ghost

Création du container avec la gestion des ports, de l'url en précisant du répertoire contenant les données, une option de redémarrage et une image particulière (pour l'exemple car idéalement on utilise celle par défaut qui est la dernière :latest) :

docker run --name ghost -p 3001:2368 -e url=https://www.domain.tld -v /home/lionel/ghost/content:/var/lib/ghost/content --restart=always -d ghost:1.21.1-alpine

En fait cette dernière possibilité, bien que proposée ne fonctionne pas, ou plus, au niveau de l'url. Je vais donc créer mon docker sans l'url et en profiter pour mettre mes données dans un répertoire un peu plus parlant. Pour ça je vais au préalable créer un volume.

docker volume create canaletto_data
docker run --name canaletto -p 3001:2368 -v canaletto_data:/var/lib/ghost/content --restart=always -d ghost

Tout ça c'est bien beau si on a qu'un seul container et que l'on ne veut pas exposer les ports. Le problème dans cette configuration c'est que mes containers vont s'attribuer par défaut des IP par ordre de démarrage. Par défaut le host docker à 172.17.0.1 et le premier container à être lancé prendra la suivante et ainsi de suite... Sauf que mon reverse proxy aura besoin de connaitre une IP fixe.  Il me faut donc trouver la solution pour figer leur IP. Simple il dit lui ! J'ai fini par trouver une méthode simple qui semble faire le job :

On crée un nouveau réseau Docker que je vais appeler my_bridge :

docker network create --subnet=172.18.0.0/16 --gateway=172.18.0.1 my_bridge
docker network ls  (ls pour voir les réseaux, rm pour en supprimer un)

Ensuite on crée le container en spécifiant le réseau à utiliser et l'IP à lui affecter et cela permet également d'isoler les container entre eux (entre temps j'ai bien sur crée une image de mon précédent container pour ne pas le perdre) :

docker run --name Ghost-2 --net my_bridge --ip 172.18.0.10 -p 3010:2368 -v canaletto_data:/var/lib/ghost/content --restart=always -d ghost:2

Ensuite je vais aller éditer le fichier de configuration Ghost qui se trouve dans le docker.

docker ps pour repéréer l'ID
docker container exec -it b23f1490ccfb /bin/bash

Et une fois dans le docker

apt-get update
apt-get install nano
nano config.production.json

Et là je vais modifier l'url qui se présente ainsi "url": "http://localhost:2368", en "url": "https://ghost.canaletto.fr",. Attention à bien sortir avec un exit si vous souhaitez y revenir... (ce point sur l'url n'est pas clair dans ma tête).

Une fois notre docker installé on a plusieurs choix possibles pour y accéder

  • En direct si on a exposé le port 80 ou sur le port 2368 qui est le port par défaut de Ghost dans le container, et à condition d'ouvrir le port dans aaPanel. C'est clairement plus que déconseillé car d'une part il n'y aura pas de SSL et d'autre part la sécurité minimale impose un reverse proxy et votre site exposé directement risque de se faire rapidement descendre. De plus ça limiterait à un site par IP.
  • Via le reverse proxy d'un autre firewall sur le LAN. Dans mon cas j'utilise pfsense avec HAProxy et Acme pour gérer les certificats. Je vais donc faire pointer HAProxy sur l'IP et le port exposée sur mon host Docker (https://www.domain.tld > http://192.168.1.10:3001 (IP LAN de mon serveur Docker qui est dans une VM))
  • Enfin si on est par exemple dans un VPS on va y accéder via un site créé avec NGINX, dans lequel on va gérer le certificat via Let's Encrypt et configurer la partie reverse proxy qui va pointer sur l'IP et le port du container. C'ets ce que l'on va voir dans le chapitre suivant.

NIGNX

On va ici faire les choses via aaPanel qui nous sert d'interface. Mais ceux connaissent peuvent bien sur éditer les fichiers de configuration idoines. NIGNX s'installe via l'App Store de aaPanel en un clic. Ensuite on va aller créer un site via le menu Website avec le nom de domaine que l'on souhaite utiliser, ici ghost.canaletto.fr sur le port par defaut qui est le 80. On associe pas de FTP (on pourra le faire plus tard et ainsi le faire pointer sur le répertoire des données Ghost, pas de Database car elle est gérée par Ghost, pas de PHP car c'est ici inutile. Pour le SSL il faudra de toutes façons renseigner plus tard la méthode (vérification par fichier ou par DNS via l'API CloudFlare si le DNS du domaine est géré par eux).

Ensuite on va aller ajouter un reverse proxy dans NIGNX et ainsi rediriger les requêtes vers l'IP et le port du container qui contiens Ghost en n'oubliant pas de préciser le nom du domaine utilisé. Attention, pour je ne sais quelle raison il faut configurer le certificat avant de mettre en place le reverse proxy. C'est probablement une limitation (autre nom pour un bug) liée à aaPanel.

A ce stade Ghost est normalement accessible et on peut commencer à le configurer via l'url https://www.domain.tld/ghost. La suite coule de source et est expliquée dans la documentation Ghost par ailleurs très complète.

Bonus

Le gros avantage de Ghost est que l'on peut lui injecter du code. Soit dans l'admin pour des fonctionnalités globales, soit dans une page ou un article, par exemple pour y ajouter directement un bouton Paypal si l'article présente un produit que vous vendez, ou encore un formulaire ou une vidéo externe.

Au niveau global on peut injecter du code dans deux parties, Site Header et Site Footer.

Zoom

Imaginons que je veuille agrandir les images en cliquant dessus. Je vais alors utiliser ce composant (il en existe d'autres) et ajouter deux scripts dans la partie "footer". Le premier le chargera via un CDN tandis que le second permettra son exécution.

<script async src="https://cdn.jsdelivr.net/gh/coreysnyder04/[email protected]a01/fluidbox-ghost-blog-plugin.min.js"></script>
<script>
    window.fluidboxGhostConfig = {
      theme: 'image-backdrop', // Options: light, dark, image-backdrop, hsla(262, 100%, 82%, 0.6)
      showCaption: true, // Sets whether to capture the caption and show it below the image when expanded
    }
</script>
Le code

Comme je publie régulièrement du code je vais ajouter Prism afin d'obtenir une présentation élégante des différents langages affichés. Je commence par le header et on termine par le footer. Au passage je vais également chercher une police chez Google et j'ajoute des modification de style pour la présentation du code (au début) mais également afin d'utiliser ma nouvelle police à la place de celle proposée par le thème par défaut. Et au passage dans le footer je vais également ajouter de quoi numéroter les lignes de mon code et ouvrir les liens dans une nouvelle fenêtre.

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/themes/prism-okaidia.min.css" integrity="sha256-Ykz0nNWK7w4QWJUYR7OraN4773aMB/11aMt1nZyrhuQ=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/plugins/line-numbers/prism-line-numbers.min.css">

<link href='https://fonts.googleapis.com/css?family=Encode+Sans:300&display=swap' rel='stylesheet'>

	<style type="text/css" media="screen">
        .post-full-content pre strong {
            color: white;
        }
        .post-full-content pre {
            line-height: 0.9;
        }
        .post-full-content pre code {
            white-space: pre-wrap;
            hyphens: auto;
            line-height: 1.6;
            font-size: 0.7em;
        }
        pre[class*=language-] {
        	margin: 1.75em 0;
    	}
        .post-template p {
 			text-align: justify;
		}
  
  		p { 
            font-family: 'Encode Sans', sans-serif; 
        }      
		li { 
            font-family: 'Encode Sans', sans-serif; 
        }      
        blockquote {
            font-family: 'Encode Sans', sans-serif; 
        }      

    </style>
<script>
    window.addEventListener('DOMContentLoaded', (event) => {
        document.querySelectorAll('pre[class*=language-]').forEach(function(node) {
            node.classList.add('line-numbers');
        });
        Prism.highlightAll();
    });
</script>
<script type='text/javascript'>
  $( document ).ready(function() {
  	$(".post-content a").attr("target","moredetail");
  });
</script>

<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/prism.min.js" integrity="sha256-NFZVyNmS1YlmiklazBA+TALYJlJtZj/y/i/oADk6CVE=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-markup-templating.min.js" integrity="sha256-41PtHfb57czcvRtAYtUhYcSaLDZ3ahSDmVZarE0uWPo=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-javascript.min.js" integrity="sha256-KxieZ8/m0L2wDwOE1+F76U3TMFw4wc55EzHvzTC6Ej8=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-css.min.js" integrity="sha256-49Y45o2obU1Yv4zkYDpMDyAa+D9sgKNbNy4ZYGRl/ls=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-php.min.js" integrity="sha256-gJj4RKQeXyXlVFu2I8jQACQZsii/YzVMhcDT99lr45I=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-sql.min.js" integrity="sha256-zgHnuWPEbzVKrT72LUtMObJgbwkv0VESwRfz7jpdsq0=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-yaml.min.js" integrity="sha256-JoqiKM2GipZjbGjNyl62d6qjQY1F9QTLriWOe4N76wE=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-sass.min.js" integrity="sha256-3oigyyaPovKMS9Ktg4ahAD1R6fOSMGASuA03DT8IrvU=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-json.min.js" integrity="sha256-18m89UBQcWGjPHHo64UD+sQx4SpMxiRI1F0MbefKXWw=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-bash.min.js" integrity="sha256-0W9ddRPtgrjvZVUxGhU/ShLxFi3WGNV2T7A7bBTuDWo=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-python.min.js" integrity="sha256-zXSwQE9cCZ8HHjjOoy6sDGyl5/3i2VFAxU8XxJWfhC0=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/components/prism-ruby.min.js" integrity="sha256-SGBXZakPP3Fv0P4U6jksuwZQU5FlC22ZAANstHSSp3k=" crossorigin="anonymous"></script>

<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.16.0/plugins/line-numbers/prism-line-numbers.min.js"></script>
Edition

L'éditeur de Ghost fonctionne en Markdown qui est devenu un standard de fait. Mais il est également possible de créer ses articles avec un éditeur externe comme Zettlr! ou zNote (il en existe plein d'autres). Personnellement je préfère TinyMCE à Markdown, mais c'est surement parce que je suis vieux et que j'ai été lobotomisé par Word...

Traduction

Ghost est livré en anglais. Mais il est prévu pour être traduisible. Pour autant la chose n'est pas forcément simple et va demander un peu de patience. Cela se fait au niveau du thème, et donc chaque traduction est propre à chaque thème. C'est plutôt bien expliqué ici et on trouve des thèmes (payant) qui sont traduits. Dans l'absolu il est même possible de traduire le backoffice, de même qu'il sera possible de configurer Ghost en multi langage (ça c'est plus compliqué).

J'ai commencé à traduire le thème de base, Casper. Donc on commence par faire une copie du thème, on ouvre le .zip et on le renomme. Ensuite il va falloir ajouter une répertoire /locales dans le thème et y ajouter à minima un fichier fr.json (qui suit). Le plus fastidieux sera d'aller dans les templates ajouter {{t à gauche des tous les textes et de terminer par }} (donc Page suivante devient {{t page suivante }}). Fastidieux mais pas énorme non plus.

Explications à venir... (ajout des autres ficjiers)

{
    "Back": "Retour",
    "Newer Posts": "Articles plus récents",
    "Older Posts": "Articles plus anciens",
    "Page {page} of {pages}": "Page {page} sur {pages}",
    "Subscribe": "S’abonner",
    "Subscribe to {blogtitle}": "S’abonner à {blogtitle}",
    "Subscribed!": "Abonné !",
    "with the email address": "avec l’adresse e-mail",
    "Your email address": "Votre adresse e-mail",
    "You’ve successfully subscribed to": "Vous vous êtes abonné avec succès à",
    "A collection of posts": "Une catégorie d’articles",
    "A collection of 1 post": "Une catégorie avec un article",
    "A collection of % posts": "Une catégorie avec % articles",
    "Get the latest posts delivered right to your inbox": "Recevez les derniers articles directement dans votre boîte aux lettres.",
    "Go to the front page": "Aller sur la page d’accueil",
    "Latest Posts": "Derniers articles",
    "Message:": "Message :",
    "<a href='{url}'>More posts</a> by {name}": "<a href='{url}'>Plus d’articles</a> par {name}",
    "No posts": "Aucun article",
    " (Page %)": " (Page %)",
    "Read More": "En savoir plus",
    "Read <a href='{url}'>more posts</a> by this author": "Lire <a href='{url}'>plus d’articles</a> de cet auteur",
    "Ref:": "Réf. :",
    "See all % posts": "Voir les % articles",
    "Share this": "Partager",
    "Stay up to date! Get all the latest & greatest posts delivered straight to your inbox": "Restez à jour ! Recevez tous les derniers articles directement dans votre boîte aux lettres.",
    "This post was a collaboration between": "Cet article est une collaboration entre",
    "[email protected]": "[email protected]",
    "1 post": "Un article",
    "% posts": "% articles",
    "1 min read": "1 min de lecture",
    "% min read": "% min de lecture"
}
Les intégrations

Ghost supporte beaucoup d'intégrations de base et il est possible d'en ajouter simplement en modifiant le code. Par exemple si on souhaite ajouter des commentaires Disqus il suffit d'ajouter ce code dans le thème à l'endroit idoine :

<div id="disqus_thread"></div>
<script>
    var disqus_config = function () {
        this.page.url = "{{url absolute="true"}}";
        this.page.identifier = "ghost-{{comment_id}}"
    };
    (function() {
    var d = document, s = d.createElement('script');
    s.src = 'https://EXAMPLE.disqus.com/embed.js';
    s.setAttribute('data-timestamp', +new Date());
    (d.head || d.body).appendChild(s);
    })();
</script>

Mais si on préfère que les commentaires soient gérés par Telegram et être notifié par ce canal on configurera cette app et on collera le script au même endroit. Il existe d'autre solutions comme Cove ou mieux Commento qui lui devra être installé localement, dans un autre container Docker par exemple), mais qui présente l'avantage de l'autonomie et de ne pas partager les données des commentateurs.

Pour le reste il est bien sur possible de créer ses propres intégrations en codant un peu... La documentation et l'importante communauté via le forum seront des bonnes sources.

Epilogue

Voila, je cherchait à m'affranchir du mammouth (Wordpress que je déteste) et je crois que j'ai enfin trouvé avec Ghost la bonne solution alternative. En plus comme Ghost est multi auteurs on va peut être en faire un blog communautaire. L'exemple est ici https://ghost.canaletto.fr ! Pour l'instant j'utilise BlogEngine pour ce site et peut être qu'un jour je tenterait la migration, d'autant plus que certains l'ont fait et qu'il existe des convertisseurs.

Enjoy !

Sources

 

Windows Terminal & SSH

Après nous avoir vanté pendant des décennies l'avantage d'un O/S Windows ou tout se passe en mode clic clic, force est de constater ces dernières années que le CLI revient en force, et ce notamment avec PowerShell. Et puis ces dernières années Microsoft nous a pondu Windows Terminal (ou mieux celle-ci) qui supporte bien sur PowerShell, Dos, mais également le client SSH maintenant intégré (timidement) à Windows.

Et c'est celui ci qui m'a intéressé pour remplacer mes anciens clients SSH (j'utilisait Putty ou Bitvise SSH) avec des mots de passe. Sauf que ce client SSH calqué sur ceux que l'on trouve sur Linux (OpenSSH) ne permet bien sur pas de stocker les mots de passe. Et c'est normal. Il va donc falloir apprendre à générer et utiliser des paires de clés SSH, ce qui avec ma culture Windows n'a pas été une mince affaire.

Si ce n'est pas fait on installe le client SSH après avoir installé Windows Terminal (le client SSH peut aussi fonctionner seul, et tout ce qui se rapporte ici à SSH n'est bien sur pas lié à Windows...).

PS C:\> Add-WindowsCapability -Online -Name OpenSSH.Client*

On va donc commencer par générer une paire de clés. Idéalement on se place dans le répertoire .ssh qui se trouve dans le répertoire utilisateur. Cela nous évitera d'avoir à saisir un chemin, car au final les clés devront se trouver dans se répertoire pour simplifier la suite. Il est possible de protéger les clés par une phrase de passe, ou pas.

PS C:\Users\Lionel> cd .ssh
PS C:\Users\Lionel\.ssh> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\Lionel/.ssh/id_rsa): test
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in test.
Your public key has been saved in test.pub.
The key fingerprint is:
SHA256:vAwnkX2iNyxyqFBVnNVHpzPbdvy6g1VoE/RU8o7+hJ0 [email protected]
The key's randomart image is:
+---[RSA 2048]----+
|    .o.o.. ...+ +|
|   .  oo  . .o.= |
|  .   o o ..+  oo|
| .   . = o   =++.|
|.   o * S   ..+o+|
| . . o B o   o.+o|
|  .     o    ooE+|
|            . .+ |
|              oo.|
+----[SHA256]-----+

On dispose maintenant de notre paire de clés, test qui est la clé privée et test.pub qui est la clé publique. Si je ne l'avais pas nommée ainsi on se serait retrouvé avec id_rsa et id_rsa.pub qui est le nom de la clé par défaut. Peu importe le nommage, ce qui compte c'est de bien identifier ces deux fichiers.

A partir de là il va falloir installer la clé publique sur le serveur de destination.

A ce stade il est donc nécessaire que le service SSH soit activé sur le serveur distant avec la possibilité de se connecter avec un mot de passe, voire en root (je sais c'est pas bien). Pour cela on édite le fichier qui va bien avec sudo nano /etc/ssh/sshd_config et on redémare le service :

On remplace PermitRootLogin prohibit-password par PermitRootLogin yes 
On remplace PasswordAuthentication no par PasswordAuthentication yes

A noter que quand on a installé une surcouche comme aaPanel, celui ci se charge du SSH au dessus de l'O/S, et on peut télécharger la clé privée à utiliser coté client directement depuis l'interface, et le cas échéant désactiver l'authentification par mot de passe. Inconvénient, pour l'instant aaPanel ne gère que le root qu'il convient donc de sécuriser.

Et c'est là que ça se complique, car si sous Linux il existe le petit outil idoine pour faire ça :

ssh-copy-id [email protected]_host

Rien de tel sous Windows et il va falloir faire avec ce sont on dispose, donc le client SSH et voici la méthode que j'ai trouvée pour installer la clé publique sur le serveur :

PS C:\> cat ~/.ssh/id_rsa.pub | ssh [email protected] "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

Une confirmation sera demandée (pour ajouter ce nouveau host à la liste locale) ainsi que le mot de passe SSH du serveur distant. 

A ce stade il est possible de se connecter avec notre clé et il sera possible de désactiver (sans se précipiter) l'authentification par mot de passe en éditant le fichier sshd_config comme vu précédemment.

PS C:\> ssh [email protected]

Et si j'ai plusieurs clés destinées à plusieurs serveurs ?

C'est possible, de deux façons, la première en cli :

PS C:\> ssh -i ~/.ssh/ma_cle_perso [email protected]

Ou plus simplement :

PS C:\> ssh MonServeur

A condition d'avoir créé un fichier config dans /.ssh

Host MonServeur
  User root
  HostName 192.168.20.20
    Port 22
  IdentityFile ~/.ssh/ma_cle_perso

Alternativement je préfère cette méthode (ici)

c:\cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

Intégration au menu Windows Terminal

Windows Terminal dispose d'un menu facilement paramétrable auquel on va pouvoir ajouter des raccourcis vers nos serveurs favoris. En cliquant sur paramètres on va directement ouvrir le fichier de paramètres et ajouter une entrée correspondant à un nouveau serveur SSH distant (attention le GUID doit être unique et on peut en générer sur plusieurs sites comme ici).

   {
     "guid":  "{232b7eac-3f44-4560-9250-eee6e97ca4e3}", // Random GUID
       "hidden":  false,
     "name":  "MonServeur",
  "icon":  "c:/users/lionel/pictures/terminal/ps.png", // facultatif
     "commandline":  "ssh 192.168.20.20"
   },

Ainsi il sera très facile d'accéder à un serveur. Dans ce fichier il est également possible de modifier tous les paramètres, mais pour ça je vous laisse lire les mes sources ci-dessous. Et comme il y a du Windows dans l'air, certains n'ont pas pu résister à ajouter des icones dans le terminal...

C'est bien sur anecdotique, mais je suis sur que ça va en amuser certains, voici la marche à suivre :

  1. On télécharge ces polices et on installe la police Caskaydia*
  2. Dans PowerShell on exécute Install-Module Terminal-Icons -Scope CurrentUser
  3. Toujours dans PS : code $profile, et on ajoute cette ligne Import-Module Terminal-Icons
  4. Avec RegEdit : Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont: 000=CaskaydiaCove Nerd Font
  5. Dans les paramètres de Windows Terminal on ajoute "fontFace": "CaskaydiaCove Nerd Font" dans profiles > defaults.

Bonus

Si vous êtes vraiment allergiques à Microsoft (que faites vous sous Windows), il y a une très bonne alternative, Fluent Terminal.

Voilà ! Je n'ai rien inventé et cet article a surtout pour but de me permettre de mémoriser tout ça. Et si ça peut vous aider.... Et si d'aucune ont quelque chose à y ajouter, n'hésitez pas !

Enjoy ;-)

Sources

 

Gérer son serveur Linux avec aaPanel

Comme beaucoup ici le savent à la base je n'ai pas une culture Linux/Unix mais plutôt Windows depuis que j'ai reçu une pile de disquettes Windows 1.03. Et très très longtemps j'ai cru que c'était le graal au point de ne pas trop regarder ce qu'il se passait à coté. Hors si je reste encore convaincu que Linux a peu de chances coté desktop (j'essaie régulièrement), Linux s'est au fil des années affirmé coté serveur, malgré le combat acharné des lobbyistes de Redmond pour laisser penser le contraire et nous laisser croire qu'ils soutiennent l'open source. On ne va pas relancer le débat, ce n'est pas l'objet.

Du coup sous Linux bien souvent je tâtonne pour des choses qui sont pourtant simples. Au fil du temps je suis devenu le roi du copié / collé SSH, tout en essayant de comprendre, ce qui n'est pas toujours évident (au passage je vous conseille vivement Windows Terminal (initiative de quelques convaincus chez MS) qui pour moi est le meilleur client SSH/PS sous Windows).

Bref, pour la faire courte je trouve que Linux manque d'interface. Je ne parle pas d'interface graphique, ce qui alourdirait pour rien un serveur, mais d'interface pour installer et superviser. Alors bien sur il y a cPanel que l'on retrouve chez certains loueurs de VPS, mais d'une part ce n'est pas gratuit et d'autre part pas le plus simple à installer sur un petit serveur isolé.

Et puis un jour j'ai découvert aaPanel. aaPanel c'est une sorte de cPanel minimaliste gratuit et open source, mais qui va permettre de faire en quelques clics de souris les choses essentielles sur un serveur Linux (installer un serveur web, un Wordpress, un FTP, cron, surveillance, etc...). Pour installer aaPanel, une seule ligne de commande suffit et je vous recommande de le faire dès le début sur une Install Linux clean ou rien n'a encore été déployé. Ca prend quelques minutes et vous trouverez plus de détails, notament pour d'autres distributions ici.

Ubuntu :

wget -O install.sh http://www.aapanel.com/script/install-ubuntu_6.0_en.sh && sudo bash install.sh aapanel

Debian :

wget -O install.sh http://www.aapanel.com/script/install-ubuntu_6.0_en.sh && bash install.sh aapanel

A partir de là ça va mouliner un peu et le système vous donnera les informations de connexion (à changer), et la suite se passera bien sur dans votre navigateur préféré :

Je vous laisse explorer l'interface qui est plutôt intuitive. Je vais juste prendre un exemple. Imaginons que je veuille installer un Wordpress. Il me suffit d'aller dans l'App Store et de choisir One Click Deployement et de sélectionner Wordpress et aaPanel fera le reste après avoir choisit quelques options de personnalisation :

Ensuite il me sera conseillé de créer une destination de sauvegarde (GDrive, S3, FTP...) et de faire un cron de sauvegarde. De même qu'en deux clics je vais pouvoir gérer mes certificats Let's Encrypt. Bien sur il est possible d'héberger  et de gérer plusieurs service sur une même instance aaPanel, que ce soit en direct, voire dans des container Docker. C'est donc la solution idéale à installer sur un VPS...  aaPanel est une solution qui s'enrichit de semaines en semaines. Et si vous voulez poser des questions, il y a bien sur un forum dédié.

Vous allez me dire que ce n'est pas avec ça que je vais apprendre à tout faire en CLI ! Ce n'est pas mon but, et tout ce qui peut me faire gagner du temps, je prends. Et surtout ça va me permettre d'être moins dépendant et ainsi de faire facilement des choses que j'étais obligé de confier à des collègues, tout en comprenant mieux ce que je met en œuvre. Enjoy !

 

 

Home Assistant & Visonic

Jadis, quand j'ai commencé à m'intéresser à la domotique, avec une Zibase, j'avais intégré les capteurs de mon système d'alarme Visonic Powermaster Pro. Ensuite sous Jeedom je les ai perdus, j'ai bien tenté avec un RFPLayer, qui dans l'absolu intégrait la techno ZiBase, de les retrouver, mais sans succès tant le plugin dédié et payant étant en dessous de tout. Un échec de plus pour Jeedom, peu importe que ce soit de leur faite ou celle de ZiBlue qui ne fournissait que peu d'informations, le résultat était négatif.

Sous Home Assistant j'ai bien essayé de me servir de la ZiBase pour récupérer ces informations, mais je n'ai pas trop insisté et j'ai fini par tout doubler avec des capteurs Xiaomi/Aqara.

Jusqu'à ce que je découvre la semaine dernière qu'il existait une intégration Visonic ! Mais pour ça il faut que ça communique. La centrale a des options que je n'ai pas et j'étais moyennement chaud pour commander une option RS232 à 80 € sur un site exotique. En lisant un peu j'ai fini par découvrir que cette option ne faisait qu'exposer physiquement le signal qui existe en TTL sur des broches accessibles. Alors j'ai fait des tests avec un câble RS232, USB/RS232 et j'ai même acheté un adaptateur Ethernet / RS232 (USR-TCP232-302) mais ça succès alors que certains disent y être parvenus, et même une pince pour sertir des connecteurs Dupont (l'enfer !), bref je me suis cassé le crane tout un week-end sans succès.

Reste une solution que je n'ai jamais explorée, utiliser un ESP_01 avec le firmware ESP-Link qui convertir les signaux TTL série afin de pouvoir les utiliser en Ethernet depuis l'intégration sous Home Assistant.

Communication

Alors d'abord il faut se procurer le module ESP NodeMCU. Ca doit pouvoir fonctionner avec d'autres ESP et d'autres firmwares mais je me suis contenté de suivre ce que j'ai trouvé. Ca vaut 1 €, c'est minuscule et ca peut tenir dans la centrale qui ainsi devient "WI-FI" !

Pour flasher le firmware ESP-Link il faut un adaptateur USB que je n'avais pas commandé pensant pouvoir le faire avec mon adaptateur USB éclaté. Certains ESP ont un bouton pour les passer en mode flashage, sur celui ci rien de tel, pas plus que sur l'adaptateur... C'est un peu le mystère laissé par les barbus, ne pas tout documenter sans quoi ce serait trop facile, ce genre de montage ça se mérite ! Bref, il faut shunter IO0 et GND avant d'insérer l'objet dans le port USB, ça permet de passer en mode programmation (je l'ai fait juste avec un câble Dupont...).

Maintenant il va falloir trouver un outil de flashage. Mais les barbus bossent sous Linux, et même s'il est possible de faire du Bash ou du Python sous Windows, ma machine ne s'est pas avérée très coopérative...

curl -L https://github.com/jeelabs/esp-link/releases/download/v2.2.3/esp-link-v2.2.3.tgz | \
    tar xzf -
cd esp-link-v2.2.3
esptool.py --port /dev/ttyUSB0 --baud 460800 write_flash -fs 4m -ff 40m \
    0x00000 boot_v1.5.bin \
    0x1000 user1.bin \
    0x7C000 esp_init_data_default.bin \
    0x7E000 blank.bin

Si la plupart des outils de flashage sous Windows fonctionnent, et même Tasmotizer, (Mathieu si tu me lis...), on va avoir besoin ici de flasher plusieurs fichiers .bin à des adresses particulières et le seul utilitaire qui a fonctionné est NodeMCU Firmware Programmer, qui selon les ESP utilisés permet de les fichiers flasher au bon endroit...

Une fois cette opération réussie (YES ! Ca m'a pris l'après midi...), on peu détacher l'ESP_01 de son support USB et aller le brancher dans la centrale. Il sera alimenté en 3.5 v par elle et servira d'interface TCP/Serie. Visonic a prévu des connecteurs dans la centrale afin d'y connecter des cartes optionnelles et couteuses, sauf que les signaux sont disponibles sur les connecteurs et que les cartes ne servent qu'à supporter des connecteurs... Des petits malins on fait un joli travail de recherche (voir les sources). Le connecteur qui nous intéresse est celui de gauche et en branchant un petit câble Dupont à 4 fils sur les 4 du haut à droite on sortira aisément GND TX RX et les 3.75 v nécessaires à l'alimentation de notre ESP.

Il ne reste plus qu'à connecter ça à notre ESP aux bons endroits, en inversant RX/TX et en faisant attention au connecteur d'alimentation car il n'y a pas de fusible...

Ensuite on se connecte en WI-FI sur son SSID (ESPxxx) et on renseigne le réseau WI-FI que l'on consacre aux IoT dans l'onglet WI-FI Station, il redémarre et on peu le pinguer... On pense à le mettre en réservation DHCP... Le seul réglage qui nous intéresse est la vitesse (9600 ou 38400 selon les modèles de centrales), et même si ce firmware permet de faire du MQTT et autres joyeusetées on désactive tout, il ne servira qu'à ça !

Intégration à Home Assistant

Cette intégration j'ai du la lancer 50 fois, mais quand on a la bonne communication ça fonctionne du premier coup. Elle permet beaucoup de choses, mais le mode standard qui me permet de voir et utiliser mes capteurs est suffisant. Je m'en contenterais car dans mes bricolages j'ai perdu le code installateur de la centrale ce qui va me limiter à l'avenir ! (code impossible à reseter). EDIT : Je viens d'apprendre qu'on peut justement le récupérer, grâce à une fonction non documentée de cette intégration...

On installe donc l'intégration Visonic, encore un excellent travail d'un passionné, et on renseigne l'IP et le port (23) de notre ESP. Et c'est tout, comme par magie les capteurs remontent ainsi que le panneau de commande. Il sera ainsi possible d'armer et désarmer la centrale depuis Home Assistant (Géoloc, présence pour l'armement et tag NFC pour le désarmement dans mon cas) et de savoir quel capteur à déclenché l'alarme dans une notification (Slack, TG ou SMS), mais aussi de conserver un log (CSV et/ou XML).

Ce qui m'embête c'est que je me retrouve avec d'un coté mes capteurs Xiaomi / Aqara qui me servaient à l'alarme HA, à couper le chauffage quand on ouvre les fenêtre ou allumer une lampe en cas de passage, et mes capteurs Visonic qui peuvent faire la même chose... Bref, j'aurais su avant je ne me serait pas lâché sur Ali Express...

Sources

J'ai écrit ça rapidement, mais voici mes sources qui contiennent pas mal d'informations pour qui voudra se lancer dans l'expérience

 

Calibre Web & Docker...

J'utilise Calibre pour gérer une bibliothèque libre d'ouvrages numériques. Pour la partager avec mes enfants j'avais jadis monté sur un Synology Calibre Web sous Docker, sans trop savoir de quoi il en retournait, mais bon ça fonctionnait depuis deux ans. J'ai donc décidé d'aller plus loin et de monter ça sur une VM Ubuntu

Installer la VM et Docker n'est pas un soucis et il existe plein de tutos. Installer le container Calibre Web n'est pas non plus un problème, par contre ce que j'ai mis des jours à essayer de faire fonctionner c'est relier ma bibliothèque restée sur le Nas. Naturellement j'ai essayé de monter un volume NFS, voire CIFS, si je parvenais bien à lire et écrire dans ce volume depuis le container Calibre-Web, je n'ai jamais réussit à ce que Calibre Web puisse ainsi fonctionner. Il se passe quelque chose que le développeur de cette image ne sait expliquer, et encore moins moi. Mais en informatique, quand on ne sait pas faire quelque chose, on essaie de trouver un contournement, et je me suis donc dit que si le volume NFS monté dans Docker n'était pas exploitable, ça pourrait peut être fonctionner avec un volume NFS monté directement sous Linux. Et banco !

Explications...

Alors on commence par mettre à jour et installer NFS

> sudo apt update
> sudo apt install nfs-common

Puis on crée les deux répertoires locaux que l'on va utiliser pour nos montages :

> sudo apt update
> sudo apt install nfs-common

Et on mappe nos ressources distantes :

> sudo mount 192.168.20.22:/volume2/Public/Books/calibre /nfs/books
> sudo mount 192.168.20.22:/volume2/Public/Books/calibre-web /nfs/books-config

On crée nos répertoires de travail qui seront utilisés par Calibre Web, ça va nous permettre de vérifier que ça fonctionne :

> sudo mkdir -p /nfs/books.config/config
> sudo mkdir -p /nfs/books.config/app
> sudo mkdir -p /nfs/books.config/kindlegen

Et ensuite on édite le fichier /etc/fstab afin de rendre la chose persistante :

. . .
192.168.20.22:/volume2/Public/Books/calibre /nfs/books   nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
192.168.20.22:/volume2/Public/Books/calibre-web /nfs/books-config    nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Bon, je n'ai bien sur rien inventé et les détails sont par exemple ici.

Maintenant je vais pouvoir créer mon Docker calibre-web après avoir adapté la config à ma sauce, c-a-d que tous mes répertoires de travail seront sur mon Nas :

> docker create --name=calibre-web --restart=always \
-v /nfs/books:/books \
-v /nfs/books-config/config:/calibre-web/config \
-v /nfs/books-config/app:/calibre-web/app \
-v /nfs/books-config/kindlegen:/calibre-web/kindlegen \
-e USE_CONFIG_DIR=true \
-e SET_CONTAINER_TIMEZONE=true \
-e CONTAINER_TIMEZONE=Europe/Paris \
-e PGID=65539 -e PUID=1029 \
-p 8083:8083 \
technosoft2000/calibre-web

J'aurais pu faire ça avec Portainer par exemple, mais c'est finalement bien plus simple de le faire en CLI, surtout avec la masse d'essai que j'ai du faire... D'autant plus que ça ne fonctionne pas, Calibre Web ne fonctionne pas avec le répertoire de config distant. Je me suis donc résolu à le laisser en local, mais pas dans le container mais un répertoire local au cas ou je casserait le container...

> docker create --name=calibre-web --restart=always \
-v /nfs/books:/books \
-v /var/lib/docker/data/calibre-web:/calibre-web/config \
-e USE_CONFIG_DIR=true \
-e SET_CONTAINER_TIMEZONE=true \
-e CONTAINER_TIMEZONE=Europe/Paris \
-e PGID=65539 -e PUID=1029 \
-p 8083:8083 \
technosoft2000/calibre-web

Voilà ! Et comme je ne pense pas pouvoir récupérer mon ancienne configuration, il ne me reste plus qu'à reconfigurer et à créer mes utilisateurs.

Sources

 

 

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.

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.

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