[Saga éclairage] Le besoin, l’idée

0

Introduction

Bonjour à tous,

Je suis équipé maintenant depuis plusieurs années d’éclairages Philips chez moi. J’avais fait l’acquisition de lampes Living Colors et Living White il y a plus de 6 ans, que j’ai complété un peu plus tard avec un kit de démarrage Hue Bloom et progressivement j’ai converti mon éclairage classique en éclairage connecté.

Je ne me suis jamais vraiment préoccupé de l’aspect connecté de mon système d’éclairage. Disposant de télécommandes Living Colors, je trouvais bien plus commode d’en laisser traîner une sur la table basse et une autre dans ma mezzanine. Lorsque j’ai obtenu le kit Hue, je dois reconnaître que j’ai joué avec l’application sur mon téléphone mais cela s’est vite arrêté car je n’ai pas tout le temps mon téléphone à la main et je trouve peu pratique de devoir le sortir pour allumer une lampe.

Pour moi, l’éclairage dans un appartement ou une maison, c’est quelque chose que l’on a l’habitude d’utiliser avec des interrupteurs au mur, il n’y a pas spécialement de raison valable de vouloir casser cette habitude, d’autant que l’on place généralement les interrupteurs près des portes pour les trouver facilement en entrant dans une pièce. C’est alors que j’ai découvert qu’il existait des interrupteurs sans fils plutôt efficaces pour retrouver cette habitude.

Pour vous donner une idée, j’avais ajouté quelques lampes, et j’avais chez moi mes deux Living Colors reliées à mon pont Hue, mais aussi mes deux Living Whites, deux Hue Blooms, ainsi qu’un Lightstrip de première génération. Je disposais d’interrupteurs au mur, aimantés et pouvant se transformer en télécommande, ainsi que des télécommandes Living Colors. La solution idéale pour moi : je peux allumer facilement la lumière en rentrant chez moi et la contrôler depuis mon canapé ou bien mon lit sans avoir à me lever.

Par la suite j’ai continué à faire évoluer mon système en ajoutant des lampes et interrupteurs pour installer dans ma cuisine. Depuis j’ai déménagé et ne m’étais pas vraiment occupé de reconfigurer l’installation, mais récemment, Jean et Guillaume se sont équipés d’un système Philips Hue. Jean a un pont, trois lampes et un interrupteur, alors que Guillaume dispose de plusieurs lampes, de prises commandées Osram compatibles avec Hue, d’interrupteurs, et également de détecteurs de mouvements. Après quelques semaines de tests, j’ai décidé de sauter le pas a mon tour et d’équiper mon appartement. J’ai acheté une prise Osram pour tester, ainsi qu’un détecteur de mouvement, et je dois dire que si je ne suis toujours pas intéressé par l’aspect connecté, l’automatisation de certains éclairages s’avère très pratique.

Quoi de mieux en rentrant chez soi, les bras chargés et de nuit que la lampe de l’entrée s’allume toute seule? Il y a plein de petites choses que l’on peut rendre automatiques ou améliorer sans pour autant casser les habitudes.

Dans ma logique, un système d’éclairage connecté ou non, intelligent ou non, c’est une machine. On l’oublie trop souvent aujourd’hui mais nous avons inventé les machines pour être à notre service et non l’inverse. Une machine se doit donc de m’être utile, me retirer des contraintes, mais en aucun cas le contraire. J’estime que je dois pouvoir allumer mon éclairage facilement avec mes habitudes, mais pourquoi pas permettre de nouveaux usages, j’en liste quelques uns :

  • Allumer un groupe de lampes, et vu qu’on peut le faire, avec des réglages de luminosité et de couleur bien précis
  • Éteindre tout, ou une zone précise en une seule fois
  • Gérer la luminosité en cas de besoin
  • S’allumer en même temps que le réveil sonne
  • Que la salle de bain s’allume et s’éteigne seule (si possible en fonction de l’heure et de la luminosité ambiante et qu’il en soit de même pour les pièces de passage)
  • Contrôler l’éclairage à distance
  • Et potentiellement d’autres.

Globalement c’est ce qui m’intéresse. Ce que je regrette néanmoins c’est qu’a chaque interrupteur Philips Hue posé chez moi, il existe un interrupteur classique qui, lorsqu’il est actionné, casse le fonctionnement de Philips Hue car il va désactiver des ampoules, et si on ne fait pas attention, on se retrouve avec une maison à moitié contrôlable via le système de Philips, et c’est dommage. Une solution à cela consiste à décâbler ses interrupteurs classiques pour les laisser en position marche, mais c’est là que je vais bifurquer pour parler d’un autre type d’éclairage. Nous aborderons nos bidouilles avec Philips Hue plus tard.

Le local LabCellar

Dans notre local, où se trouvent nos bureaux, nos serveurs, nos AS/400 et notre stock, nous avons mis en place un éclairage presque global à base de baguettes et guirlandes LED peu chères, s’appuyant sur des alimentations ATX recyclées et des interrupteurs Legrand Mosaic dans une goulotte. Cela fonctionne très bien, et nous permet de gérer un éclairage d’ambiance, nos lampes de bureau à LED modifiées de chez Ikea, le plafonnier des bureaux, du couloir de l’entrée et enfin du stock.

Tout ce petit monde se contrôle via 5 interrupteurs positionnés en un seul endroit. Et il est hors de question de tout remplacer par du Philips Hue ou une autre solution du même acabit.

Nous disposons aussi dans la cage d’escaliers d’un éclairage classique en 230V et qui est contrôlé par un télérupteur et deux poussoirs, l’un dans le couloir, donc inutile, et un autre en haut des marches. Ce qui veut dire que quand on quitte les locaux, il faut, pour ne pas se retrouver dans le noir, monter les marches ou aller dans le couloir pour allumer l’escalier, redescendre, éteindre toutes les lampes et enfin repartir vers l’escalier. Peu pratique.

De plus, tout notre système d’éclairage ne pouvant se contrôler que par un endroit, il faut obligatoirement s’y rendre. Si on est au fond du stock en se contentant de l’éclairage d’ambiance et que finalement on voudrait plus de lumière, il faut sortir du stock pour allumer la lumière.

Egalement, lorsque personne n’est présent et que la vidéo surveillance nous alerte, déclencher un éclairage pourrait être utile pour mieux voir ce qui se passe.

Le besoin

On veut :

  • Que le système de contrôle tienne dans une boîte
  • Que cela accepte d’être relié à des interrupteurs
  • Que pour chaque tâche on puisse avoir plusieurs interrupteurs si besoin
  • Que cela soit contrôlable et interrogeable à distance au moins par des requêtes HTTP
  • Que l’on puisse contrôler les appareils électriques sans se soucier de leur tension
  • Que cela permette de recycler l’éclairage déjà présent, 12V comme 230V
  • Que cela permette de recycler les interrupteurs poussoirs déjà présents, 12V comme 230V
  • Que cela s’alimente en 5V ou en 12V continu
  • Qu’il n’y ait que de la basse tension qui passe dans les poussoirs.

Nous avons imaginé une boîte qui contiendrait des borniers. D’un côté on aurait 8 entrées pour interrupteurs poussoirs, de l’autre 8 sorties contrôlées par des relais. Entre les deux une puce quelconque et de l’Ethernet.

Le fonctionnement serait assez basique :

  • J’appuie sur le poussoir 1, le relais de la sortie 1 change d’état, tout simplement.
  • J’appuis sur le poussoir 2, le relais de la sortie 2 change d’état, et ainsi de suite.
  • Je câble deux poussoirs en parallèle sur la même entrée, je fais changer alors l’état du relais correspondant par une pression sur l’un des deux poussoirs indistinctement
  • Je souhaite développer une application qui permettrait de contrôler la lumière, il me suffit d’envoyer une requête HTTP simple et claire. Pour cela, je peux demander l’allumage, l’extinction, ou tout simplement l’inversion d’état.
  • Je souhaite développer une application qui affiche l’état des lampes, une requête HTTP me permet également de récupérer l’état actuel de chaque relais.

L’idée c’est que ce système puisse éventuellement contrôler autre chose que de l’éclairage. On pourrait très bien gérer une VMC, ou des prises électriques, ou n’importe quoi d’autre. Ce qui permet, le jour où il ne sera plus utile de pouvoir être recâblé et retrouver une utilité ailleurs.

La suite

Après y avoir réfléchi, j’ai exprimé notre besoin à Jean, notre électronicien afin qu’il me donne ses avis, ses idées. J’ai des notions d’électronique qui n’étaient pas trop mauvaises mais qui malheureusement commencent à dater, et surtout je n’ai aucune idée de comment choisir, comment gérer une puce de type PIC, Arduino et consorts. Le mieux pour moi est de m’en remettre à la personne compétente pour établir les différents choix technologiques nécessaires à la réalisation de ce projet. Nous verrons prochainement avec Jean comment ce besoin pourrait être matérialisé, quels choix s’offrent a nous, etc…

[Saga Pagers] Mes premiers pagers

0

Bonjour à tous,

Un peu partout dans le monde, on trouve, moins fréquemment maintenant, de petits appareils très mignons appelés bipeurs. Alors bipeur, pager, pagette chez nos amis québécois, récepteur de radiomessagerie, peu importe, c’est la même chose. Moi j’appelle cela en général un pager, j’y ferai référence ainsi.

Qu’est-ce que c’est-il donc? Il s’agit d’un petit appareil très facile à transporter, généralement doté d’un écran (même si certains vieux modèles ne peuvent que sonner), parfois d’une lampe d’avertissement et d’un vibreur. Le principe de cet appareil c’est d’écouter sur une fréquence jusqu’à détecter son identifiant et se réveiller pour sonner, voire afficher un message.

En France, nous avions trois réseaux et trois types de terminaux:

  • Tatoo était le nom des récepteurs utilisés sur le réseau France Télécom appelé Alphapage. Ils utilisent le protocole POCSAG et sont aujourd’hui toujours utilisables, le réseau étant toujours opérationnel, même s’il a changé de propriétaire.
  • TamTam était le réseau Cegetel. Il utilisait le protocole ERMES qui n’a pas su convaincre. Fin de service en 1999.
  • Kobby, qui a duré un peu plus longtemps. C’était le réseau de Bouygues Télécom opéré par la filiale Infomobile. Ce réseau utilisait le protocole ERMES, puis le protocole FLEX, comme encore aujourd’hui aux US, expliquant peut-être une fin de service plus tardive (en 2005).

Il ne nous reste donc plus que le réseau Alphapage/Tatoo pour nous amuser.

Il était une fois Il y a environ deux ans, alors que je repensais à ces histoires de pagers et sachant que le réseau fonctionnait toujours contrairement à la croyance populaire, j’ai eu envie de sauter le cap. Oui, en 2016, j’achetais un Tatoo. Je me suis rendu sur différents sites de petites annonces et j’ai trouvé deux occasions plutôt sympathiques.

 

J’ai joué un peu avec, les ai réactivés, envoyé quelques messages, mais les différents projets en cours ne me permettaient pas de m’y pencher sérieusement.

N’est-ce pas la classe? Sur la gauche, un Tatoo 5 (Motorola Instinct) et sur la droite un Tatoo 21 (Motorola Memo Express). Comme on peut le voir, les deux terminaux sont griffés « Tatoo ». C’était excessivement commun à l’époque. Tout le monde se souvient du logo Itinéris ou SFR sur son téléphone portable, voire chez Bouygues l’utilisation d’un numéro de modèle propre à l’opérateur. C’était un peu la foire.

Non seulement il y avait les étiquettes affichant généralement l’opérateur, en l’occurrence Tatoo, mais il y avait aussi les adaptation géographiques. En POCSAG, le réseau fonctionne dans les 466 MHz en France. Malheureusement, c’est le seul pays ou presque à utiliser cette fréquence. Trouver un pager d’un autre pays qui puisse fonctionner est tout bonnement impossible. C’est d’autant plus dommage quand on voit les plus récents récepteurs Motorola qui sont plutôt bien fichus. Motorola a quitté aujourd’hui ce marché mais il existe toujours d’autres constructeurs proposant des appareils très efficaces et polyvalents.

[Mémo] Imposer des paramètres Mozilla Firefox pour un poste en entreprise

0

Pour éviter de chercher à chaque fois, et pour vous faire profiter de l’occasion, voici un petit mémo qui compile et filtre une partie de la littérature (souvent en anglais) à propos de la gestion de configuration des profils Mozilla Firefox, notamment en entreprise.

D’abord le point d’entrée

Ce fichier porte une trace forte héritée du long passé de Firefox et les recommandations pour son nom et son emplacement ont évoluées plusieurs fois. Pour les branches récentes (soit l’ESR actuelle (branche 52) et la précédente (branche 45), ça fonctionne), on utilisera un fichier « C:\Program Files\Mozilla Firefox\defaults\pref\autoconfig.js ». Ce fichier est le déclencheur pour la configuration forcée de Firefox. Bien évidemment, vous devrez adapter le chemin d’accès en fonction de votre contexte, sachant que ce qui est dit ici, et illustré dans un contexte Microsoft, fonctionne parfaitement en environnement Linux (voir les chemins d’accès courants en référence).

Dans ce fichier, on trouvera seulement trois lignes indiquant globalement l’utilisation d’un fichier de configurations forcées.

// Utilisation de configurations forcées
pref("general.config.filename", "mozilla.cfg");
pref("general.config.obscure_value", 0);

Notez que le commentaire en première ligne est obligatoire, quand bien même il serait vide (donc juste deux slashs).

De plus, remarquez l’apparition en clair du nom de fichier que nous allons aborder, ici « mozilla.cfg ». Il pourrait tout aussi bien s’appeler « monentreprise.cfg », le fonctionnement n’en serait pas affecté.

Ensuite le fichier de configuration lui-même

Ici aussi, je préfère ajouter une ligne de commentaire au début. Dans ce cas, c’est plutôt recommandé suite à un vieux bug (antérieur à la version 22). C’est normalement corrigé depuis bien longtemps mais on l’a gardé plus par habitude (commentez vos codes !) que par nécessité. Moi-même j’ai cédé et je l’ai gardé dans mes cas d’usage.

Le fichier en question, que nous appellerons « mozilla.cfg » pour être en phase avec le fichier précédent, se place directement dans « C:\Program Files\Mozilla Firefox\ ».

Il contient, outre le commentaire de la première ligne, et les éventuels commentaires à différents endroits de ce fichier, les configurations à effectuer.

Généralement, on appelle les trois fonctions suivantes :

  • lockPref : pour forcer une configuration (et verrouiller l’élément qui permet de la modifier dans l’interface utilisateur)
  • pref : pour écraser une configuration à chaque démarrage du navigateur
  • defaultPref : pour configurer certains paramètres lors de la création d’un profil (soit la plupart du temps à la première ouverture de Firefox)

En voici un exemple appliqué, lequel interdit l’exécution de la mise à jour automatique. Je ne recommande pas l’application de ces éléments si vous n’avez pas une politique fiable chargée du suivi de version et de la mise à jour par d’autres moyen.

// Fichier de configurations forcées
lockPref("app.update.auto", false);
lockPref("app.update.enabled", false);
lockPref("app.update.mode", 0);
lockPref("app.update.service.enabled", false);
lockPref("browser.search.update", false);

Mais on peut avoir des choses plus compliquées. Vous trouverez une référence pour aller plus loin, puisqu’après tout, c’est bien un fichier JavaScript, mais pour le coup, ça devient hors-sujet.

Et sinon

Il existe aussi un autre moyen de forcer des configurations en utilisant un fichier « user.js » dans le profil de l’utilisateur. Cela permet d’écraser les valeurs contenues dans « prefs.js » par celles de « user.js ». Cependant, un utilisateur averti saura se rendre dans son profil Firefox et modifier ou supprimer le fichier « user.js ».

Au moins, ce moyen a été cité !

Sachez qu’il existe un outil appelé CCK2 qui peut vous faciliter grandement la tâche. Mais comme je reste un adepte de la méthode manuelle (et donc formatrice), c’est celle-ci que j’ai décrite dans cet article.

L’avenir

Sachez qu’avec la version 60 ESR, Mozilla fournira un véritable outil de configuration. Difficile de dire avec précision s’il sera bien ou pas, ni comment il évoluera. Cependant l’initiative était vivement attendue depuis longtemps afin de cesser le bidouillage à base de fichiers comme indiqué ici. Affaire à suivre.

Références

[Astuce] Monter une image disque VirtualBox sous Linux

0

Introduction

J’ai besoin de transférer des fichiers lourds (quelques Gio) depuis le disque dur virtuel d’une machine VirtualBox vers la machine hôte. La machine virtuelle est sous Windows, mais les additions invités ne fonctionnent pas, et je ne désire pas modifier la configuration réseau pour mêler mon réseau local à celui de la machine virtuelle. Pour pouvoir transférer mes fichiers, je vais donc devoir monter l’image disque de ma machine virtuelle.

Émuler un périphérique bloc

Sous Linux, une manière de créer des périphériques blocs dynamiquement est de recourir au module noyau nbd. NBD est un protocole similaire à iSCSI, qui permet de créer des périphériques blocs à partir d’un serveur. On charge le module nbd avec la commande suivante :

sudo modprobe nbd max_part=8

Vous devriez voir apparaître plusieurs entrées nbd0, nbd1, etc. dans le répertoire/dev.

On cherche à faire de notre image disque VirtualBox un périphérique bloc, et pour ce faire, nous allons utiliser le serveur NBD qemu-nbd (sur certaines distributions, il est contenu dans un paquet qemu-utils). On le lance ainsi :

sudo qemu-nbd --connect=/dev/nbd0 monimagedisque.vdi

Si vous inspectez encore une fois le répertoire /dev, de nouvelles entrées sont arrivées pour représenter les différentes partitions contenues dans l’image disque, sous la forme nbd0p0, nbd0p1, etc.

Monter les partitions

Dans mon cas l’image contient deux partitions (la première contient le bootloader, la seconde l’OS et mes données), et je ne vais monter que la seconde (nbd0p1). On commence par créer un dossier dans lequel sera monté la partition :

sudo mkdir /mnt/vbpart1

Ensuite on peut monter la partition avec la commande mount :

sudo mount /dev/nbd0p1 /mnt/vbpart1

Si la commande mount s’exécute correctement, vous devriez pouvoir accéder aux fichiers de la partition dans le point de montage que vous avez configuré.

Démonter les partitions et arrêter le serveur nbd

La procédure à suivre se déroule en deux étapes. D’abord on démonte la ou les partitions montées :

sudo umount /dev/nbd0p1

Une fois toutes les partitions démontées du périphérique nbd0, on peut procéder à l’extinction du serveur NBD :

sudo qemu-nbd -d /dev/nbd0

[Sans contact] Un lecteur/encodeur RFID pour moins de 10€

0

J’avais besoin d’un lecteur/encodeur RFID pour un projet personnel, alors je me suis renseigné sur internet, et j’ai vu beaucoup de recommandations pour le lecteur/encodeur ACR122U, qu’on trouve un peu partout (eBay, Amazon, etc.) pour une trentaire d’euros. Je trouvais cela cher pour un dispositif RFID, j’ai donc cherché une solution alternative plus économique.

La solution trouvée consiste à associer un module RFID destiné à des projets électroniques à base d’Arduino à un adaptateur USB-UART.

Module NFC

Il faut acheter un module NFC basé sur la puce PN532 mais attention, toutes les cartes ne sont pas identiques ! En effet, la puce PN532 peut être exploitée par 3 interfaces (I²C, SPI, UART), et en fonction du choix du fabricant, il est parfois uniquement possible d’utiliser une des trois interfaces. Pour ma part, j’ai le module ElecHouse rouge :

Il dispose de deux interrupteurs pour sélectionner le mode d’interface à utiliser (appelé HSU sur le module : High Speed UART). On le trouve pour environ 5€ en provenance de la Chine.

Adaptateur USB-UART

Votre ordinateur étant peu probablement doté d’une interface UART accessible (sauf si vous utilisez un ordinateur embarqué, type Raspberry Pi), il nous faudra une interface USB-UART. On en trouve pour quelques euros sur internet. J’utilise pour ma part un adaptateur basé sur la puce FT232R :

Connection électrique entre adaptateur USB-UART et carte NFC

À l’aide d’un cable mâle-mâle, il faut effectuer les connexions suivantes :

  • VCC UART -> VCC NFC
  • GND UART -> GND NFC
  • TX UART -> RX NFC
  • RX UART -> TX NFC

Si votre adaptateur est doté d’un cavalier permettant la sélection de la tension VCC, mettez-le en position 3V3. Sinon assurez-vous que votre adaptateur avec des niveaux de tension 0-3V3.

Configuration pour l’utilisation avec libnfc

Sur Linux, la majorité des outils permettant de travailler sur le NFC sont écrits avec la bibliothèque libnfc (installée par défaut sur Kali Linux, disponible dans les dépôts Fedora). Pour pouvoir utiliser notre lecteur/encodeur avec libnfc, il va falloir créer un fichier de configuration.

On va d’abord avoir besoin de connaître le nom du fichier de l’adaptateur USB-UART. En ayant l’adaptateur débranché, listez les périphériques série sur votre système avec la commande :

ls /dev/tty*

Branchez l’adaptateur et répétez l’opération. La nouvelle entrée correspond à celle de votre adaptateur (par exemple dans mon cas /dev/ttyUS3).

Dans le dossier /etc/nfc/devices.d/, créez un fichier monrfid.conf (le nom du fichier importe peu, l’extension par contre oui), en prenant soin de remplacer le chemin du fichier de votre adaptateur USB-UART :

name = "Mon adaptateur RFID maison"
connstring = "pn532_uart:/dev/ttyUSB3"

Votre lecteur/encodeur NFC est prêt à être utilisé !

[Apple] Installer iWork sur iOS 5.1.1

0

Je possède un iPad de première génération qui est destiné à rester sous iOS 5.1.1, la dernière version d’iOS pour ce modèle d’iPad. Cette version est sortie il y a plus de 5 ans, et inévitablement le support logiciel est quasiment mort : il n’est plus possible de publier des applications compatibles avec cette version d’iOS. C’est malheureux, mais dans la mesure où les capacités matérielles de cet iPad étaient limitées, ce n’est pas trop aberrant.

Je voulais y installer la suite iWork (Pages, Numbers, Keynote) de manière à pouvoir l’utiliser comme un outil d’appoint pour rédiger des documents en mobilité, mais il n’est pas possible de procéder directement depuis l’iPad : on nous indique qu’il est trop vieux.

La solution consiste à passer par iTunes, sur Mac dans mon cas, pour bidouiller les requêtes qui interviennent lors du téléchargement de l’application.

Attention : il n’est plus possible de télécharger d’applications sur l’App Store iOS depuis iTunes à partir de la version 12.7!

Installation d’un proxy pour modifier des requêtes

L’idée est d’intercepter les requêtes vers l’iTunes Store pour changer le External Version Identifier (l’identifiant attribué à chaque version d’un logiciel distribué sur l’App Store). Pour ce faire nous utiliserons Charles, un proxy. Ce logiciel est payant ($50) mais la version gratuite suffit amplement.

Une fois l’application Charles lancée, vous devrez lui accorder les privilèges administrateurs pour qu’elle puisse intercepter les communications internes à votre ordinateur.

Nous allons devoir intercepter des communications chiffrées (SSL), donc il faut importer le certificat autogénéré de Charles, sinon iTunes rechignera à communiquer avec l’iTunes Store. Rendez-vous dans Help > SSL Proxying > Save Charles root certificate, sauvegardez le certificat quelque part, puis importez-le dans le trousseau.

Ensuite, exportez le certificat importé dans le trousseau au format .cer, et tapez la commande suivante pour l’ajouter en tant que certificat vérifié :

sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" /chemin/vers/mon/certificat.cer

Modifier les requêtes vers l’iTunes Store

Lancez un téléchargement d’application quelconque depuis iTunes. Vous devriez observer l’apparition d’une ligne vers un serveur dont le nom de domaine est formatté ainsi : ***-buy.itunes.apple.com. Faites un clic droit dessus puis sélectionnez Enable SSL Proxying. Cela va faire en sorte à ce que les communications SSL soient interceptées.

Lancez à nouveau un téléchargement d’application depuis iTunes. Dépliez l’arbre du serveur ***-buy.itunes.apple.com (WebObjects > MZBuy.woa > wa > buyProduct) et faites un clic droit sur buyProduct pour sélectionner Breakpoints. Cela va avoir pour effet de mettre en attente chaque requête vers buyProduct, pour pouvoir modifier son contenu.

Lancez à présent le téléchargement d’une application de la suite iWork, par exemple Pages. Charles va s’activer et vous proposer de modifier la requête. Cliquez sur l’onglet XML Text, et modifiez la valeur de appExtVrsId. Vous devez utiliser les valeurs suivantes :

  • Pages 1.7.2 : 14498879
  • Numbers 1.7.3 : 16806622
  • Keynote 1.7.2 : 14498877

Cliquez ensuite sur Execute, cela vous sera demandé plusieurs fois. Le téléchargement de l’application devrait commencer, et vous pourrez devriez vous retrouver avec l’application souhaitée dans vos téléchargements iTunes.

[Astuce] Accès distant avec OpenVPN

0

En voulant configurer un serveur d’accès distant avec OpenVPN, je suis tombé dans quelques petits pièges. Aussi, pour que mon expérience puisse servir à d’autres, autant vous en faire part.

Contexte

C’est très simple, presque bateau : un serveur, avec OpenVPN, des clients, avec OpenVPN également et quelques petites subtilités côté serveur. Les clients se connectent au serveur et accèdent à des ressources locales au serveur mais aussi à l’infrastructure qui se trouve derrière. Imaginez que l’infrastructure est importante et que le serveur serve de bordure à un protocole de routage dynamique.

Première astuce : les types de tunnels

D’abord, j’ai fait l’erreur de laisser les clients se connecter via un VPN TAP. Bien que ça fonctionne, ce n’est pas vraiment adapté en pratique. Sommairement, les tunnels de type TAP sont principalement conçus pour des connexions de site à site, et les tunnels de type TUN servent aux accès distant pour un terminal (ordinateur, téléphone, tablette…). Bref, on repasse en TUN pour le cas qui m’intéresse, c’est-à-dire de l’accès en itinérance de terminaux.

Deuxième astuce : la topologie des tunnels de type TUN

Les interfaces de type TUN fonctionnent au niveau 3 du modèle OSI, mais en fait c’est un montage un peu complexe quand on y regarde de très près mais qui fonctionne très bien. Sauf bien évidemment quand on utilise déjà des astuces de routage ou de pare-feu, ce qui était le cas sur mon serveur.

Regardons justement plus en détail. Sur une extrémité de tunnel TAP, on trouve une interface réseau virtuelle, possédant son adresse IP et son masque, et un pair en face. On est donc pas bien loin du tunnel GRE si on enlève le chiffrement qui va autour, dans le principe bien sûr.

Pour une extrémité TUN, il faut tenir compte de la notion de topologie. Par défaut, un serveur TUN démarre avec une topologie dite « net30 », soit assignation d’un sous-réseau /30 (2 IP possibles, le serveur et le client). Et pour que le client communique avec le serveur (au sens applicatif, par exemple un serveur Web abrité derrière la connexion VPN), il faut que le noyau puisse recevoir les paquets, et il n’y a qu’une seule interface virtuelle qui est montée. Dans ce cas, on va tomber sur une interface TUN déclarée dans le noyau avec une adresse IP /32, une route injectée « manuellement » par OpenVPN pour tout le sous-réseau, et un routage strictement interne à OpenVPN entre les clients. Obscur hein ! Décryptons avec un dessin.

Ce schéma représente le principe de fonctionnement d’une topologie Net30. Le serveur réel (le noyau du système d’exploitation) voit une unique adresse IP en 192.168.90.1/32, tout le reste étant masqué par le processus OpenVPN. Chaque client voit sa propre adresse IP dans un sous-réseau dédié par OpenVPN. Par exemple le client ayant l’adresse 192.168.90.6/30 discutera avec le serveur via l’adresse 192.168.90.5/30 et ne pourra pas communiquer avec le reste du monde, sauf à lui « pousser » des routes.

Il faut bien comprendre qui va tenir le rôle de routeur : est-ce le serveur OpenVPN ou est-ce le noyau de l’OS ? La réponse dépend de la configuration : avec l’option « client-to-client », c’est OpenVPN qui s’occupera du routage, sinon c’est le noyau.

Avec un Net30 et une plage réduite dans la configuration d’OpenVPN, disons 192.168.90.0/29, on peut avoir un serveur et un client (et un seul), et instancier autant de processus OpenVPN que nécessaire, et donc autant d’interfaces dans le noyau. Ca peut éventuellement servir pour appliquer des règles de pare-feu très fines entre clients ou différentes d’un client à l’autre.

Mais c’est peut-être un peu beaucoup… Et c’est pas tout à fait ça que je cherchais. Tout simplement parce que l’interface déclarée en tant que 192.168.90.1/32 crée du souci à mon protocole de routage, même avec la route « manuelle » évoquée plus haut qui serait ici 192.168.90.0/24. Dans mon cas, le protocole choisit le masque le plus restreint plutôt que la route statique, même en lui forçant la main.

Et c’est là qu’entre en jeu le paramètre « topology ». Moyennant de lui indiquer le mode « subnet », on retombe sur le même principe de fonctionnement que les interfaces TAP, et le noyau verra de nouveau l’interface virtuelle en tant que 192.168.90.1/24. Et voilà que mon routage s’est remis d’aplomb presque instantanément !

Troisième astuce : tout ça pour le client OpenVPN sur Android

Le client OpenVPN pour Android ne supporte pas les tunnels TAP ! C’est de là que tout est parti. Quand, lorsque j’ai bêtement converti mon serveur de TAP vers TUN, j’ai vu surgir tous ces problèmes de topologie mais aussi de routes et de DNS !

Parce que malgré un « ip route » sur un teminal Android (7.1.2), impossible de voir les routes poussées par le serveur dans le noyau Linux de l’Android. Même en root. Alors qu’elles sont bien présentes et bien inscrites par OpenVPN. Bref, que faut-il alors faire pour que ça fonctionne ?

Sur le serveur, il faut pousser les routes et éventuellement si c’est nécessaire (comme dans mon cas) les serveurs DNS. On placera donc les éléments suivants, que vous aurez bien évidemment pris soin d’adapter à votre cas, dans la configuration côté serveur :

push "route 10.0.0.0 255.0.0.0"
push "dhcp-option DOMAIN labcellar.com"
push "dhcp-option DNS 10.0.0.10"
push "dhcp-option DNS 10.0.0.11"

Je ne veux rediriger que le trafic interne dans le tunnel, c’est pouquoi je ne fais que pousser la route adaptée. Vous trouverez sur Internet pléthore de sites vous expliquant comment rediriger l’intégralité du trafic dans le tunnel. Ici, c’est l’accès aux outils internes qui m’intéresse, et la résolution des noms. Côté client Android, il faut bien penser à laisser l’option « pull » activée afin que soient pris en compte tous ces paramètres « pushés » par le serveur. Et n’oubliez pas dans les versions récentes d’Android d’aller régler les « Applications autorisées », soit en mode « liste blanche » (seulement les applications cochées), soit en mode « liste noire » (interdire les applications cochées).

En fait, au delà de l’astuce de configuration, il faut savoir que le seul moyen d’avoir des informations de débogage consiste à augmenter la « verbosité » du logiciel OpenVPN et à faire confiance au fait qu’il affiche ou non des erreurs à chacune de ses actions. Demander ces informations directement au noyau Android aboutit à n’avoir que des informations erronées ou incomplètes si l’on tente de procéder comme sur un ordinateur classique.

Références

Il y a une petite coquille dans cet article (qui n’est pas liée à la syntaxe ou à la grammaire mais bien sur le sujet de fond), et qui n’a pas d’impact sur toutes les explications données, ni sur la solution mise en œuvre. Je l’ai laissée (presque) exprès. Saurez-vous la retrouver ? J’éditerai cet article dans un mois environ pour indiquer la solution.

Edit du 09/04/2018 : si vous avez bien suivi les explications sur la topologie Net30, vous avez peut-être remarqué qu’il y a une incohérence dans le schéma que j’ai proposé. En effet si le pseudo-serveur qui émule le switch interne qui relie les tunnels entre eux s’attribue d’abord une adresse avant d’en attribuer une à son client, ça signifie que la patte en haut à gauche qui représente la machine physique ne contient pas les bonnes adresses. Côté switch, c’est l’adresse .1 et côté serveur physique, c’est .2. Et c’est effectivement le cas : l’adresse visible avec un « ifconfig » ou un « ip address » est bien une valeur paire, et généralement .2 pour un subnet /24 divisés en morceaux de /30.

[Palm] Emettre des codes infrarouge « Pronto » avec un Palm

0

Une histoire rocambolesque : j’avais besoin de tester une prise antenne dans un logement, et pour cela me suis muni d’un décodeur TNT. Pour lancer une recherche de canaux télévisuels, il faut une télécommande. Je n’avais pas à ma disposition de piles adéquates pour mettre dans la télécommande, et ai donc dû improviser avec un Palm TX…

Dans cet article, nous allons donc émuler une télécommande infra-rouge à l’aide d’un Palm en se servant de codes pour télécommande Philips Pronto en hexadécimal. Dans mon cas, il proviennent de la fabuleuse base de données irdb.tk.

Il n’existe pas (à ma connaissance) de méthode permettant d’entrer directement des codes infrarouges dans une application Palm pour les émettre. Nous allons donc bidouiller avec plusieurs logiciels pour parvenir à notre objectif.

(suite…)

[Mémo] Démarrer des instances OpenVPN avec systemd

0

Remarque préliminaire : cet article traite du démarrage d’instances d’OpenVPN sur un système Linux, ici une Debian Stretch, avec systemd. Il ne traite pas de la manière dont on configure une instance OpenVPN (paramètres et clés).

Avec SysV, un démon maître était lancé et chaque instance à démarrer automatiquement se faisait par configuration dans le fichier « /etc/default/openvpn » (du moins sur les Debian-like).

systemd est conçu pour gérer nativement ces problématiques de multi-instances, alors autant en profiter.

Contexte

Supposons que votre ordinateur portable nécessite d’être raccordé à trois infrastructures distantes via VPN, dont une de manière permanente. Imaginez que vous êtes un prestataire qui prend le contrôle à distance chez ses clients, tout en gardant en permanence un lien vers son serveur NAS à la maison,

On a donc 3 configurations différentes que nous appellerons « maison », « client-a » et « client-b ». Ces trois configurations et tous les fichiers nécessaires (notamment les clés) se placent dans leurs dossiers respectifs. Ce qui donne :

$ ls /etc/openvpn
client   client-a   client-b   maison   server

Cela dit, on remarque la présence de deux dossiers supplémentaires appelés « client » et « server ». Ils sont liés au fonctionnement prédéfini par les gabarits d’unités systemd pour OpenVPN 2.4.

Mise en œuvre

Pour chaque dossier créé, on trouve un certain nombre d’éléments, dont le fichier de configuration. Voici un exemple :

$ ls /etc/openvpn/maison
maison.conf   shared.key

Remarque : on pourrait tout bourrer comme des sagoins dans le dossier « client », mais je ne trouve pas ça très propre et très maintenable si les tunnels se multiplient.

Cependant, c’est bien le dossier « client » qui va faire foi dans un premier temps, vu la manière dont le gabarit est construit. Un simple lien symbolique suffit :

# ln -s /etc/openvpn/maison/maison.conf /etc/openvpn/client/maison.conf

Le gabarit n’est pas amorçable directement, il faut nommer explicitement une instance. Ici le fichier s’appelle « maison.conf ». Inscrire l’instance « maison » (qui ira bien chercher « maison.conf » dans le dossier « client ») est enfantin :

# systemctl enable openvpn-client@maison
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-client@maison.service → /lib/systemd/system/openvpn-server@.service.

Désormais, le VPN vers la maison se lance automatiquement au démarrage du système !

Et pour lancer les autres instances, pas besoin de les inscrire, systemd se débrouille à partir du nom indiqué pour retrouver ses petits.

# systemctl start openvpn-client@client-a

Remarques

Le paquet OpenVPN exploite donc désormais les services systemd, et non plus les scripts de type UNIX System V. Pour bien décortiquer l’affaire, il faut donc comprendre le fonctionnement des « unités » systemd. La petite bête réside dans ce paragraphe (en langue de Shakespeare) :

Optionally, units may be instantiated from a template file at runtime. This allows creation of multiple units from a single configuration file. If systemd looks for a unit configuration file, it will first search for the literal unit name in the file system. If that yields no success and the unit name contains an « @ » character, systemd will look for a unit template that shares the same name but with the instance string (i.e. the part between the « @ » character and the suffix) removed. Example: if a service getty@tty3.service is requested and no file by that name is found, systemd will look for getty@.service and instantiate a service from that configuration file if it is found.

Soit en gros : il détecte la présence d’un arobase, donc il suppose une instanciation. Il extrait le nom de l’instance entre le ‘@’ et le ‘.’, et lance le gabarit (reconnaissable au ‘@.service’) avec en paramètre le nom de l’instance.

Le paquet lui-même installe ces fichiers :

# ls -l /lib/systemd/system/openvpn*
-rw-r--r-- 1 root root 707 juil. 18 22:15 /lib/systemd/system/openvpn-client@.service
-rw-r--r-- 1 root root 780 juil. 18 22:15 /lib/systemd/system/openvpn-server@.service
-rw-r--r-- 1 root root 320 juil. 18 22:15 /lib/systemd/system/openvpn.service
-rw-r--r-- 1 root root 894 juil. 18 22:15 /lib/systemd/system/openvpn@.service

Dans le fichier « openvpn-client@.service », on trouve ces directives (parmi d’autres) :

WorkingDirectory=/etc/openvpn/client
[...]
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf

Et voilà grosso modo comment systemd s’y retrouve pour lancer des instances différentes à partir d’un même fichier. Même principe pour le gabarit « openvpn-server ».

Et les deux derniers ? Ce sont les versions pour OpenVPN 2.3, que je recommande d’abandonner si vous le pouvez. Ces instances cherchent leur configuration dans le dossier « /etc/openvpn » et sont lancées de manière significativement différentes. Si vous n’êtes pas un expert OpenVPN, ou ne recherchant pas explicitement ces détails de lancement, vous pouvez les abandonner sans regret. Sachez qu’un OpenVPN 2.4 peut parfaitement discuter avec un OpenVPN 2.3 moyennant de les laisser s’entendre sur les algorithmes et certains paramètres nouvellement introduits : c’est testé et approuvé !

systemd, faut en manger ! C’est bon ! (Mais des fois ça croque un peu sous la dent…)

[Debian] Basculer la mise en réseau de System V à systemd

1

Depuis Debian Jessie (8.X), systemd se fait de plus en plus présent dans la distribution, et permet d’effectuer une migration en douceur au fil des versions. Parmi celles à noter, je voudrais vous faire découvrir la partie mise en réseau élémentaire.

L’objectif est de remplacer la gestion classique avec l’ensemble ifupdown et le client DHCP de l’ISC. On pourra même supprimer les paquets à la fin de la migration. Pour corser les choses, je vais appliquer ce cas d’usage à un VPS 2016 chez OVH, dont la gestion manuelle révèle quelques surprises.

Testez vos configurations dans une machine virtuelle ! Ça vous évitera des surprises en production. Et lisez cet article en entier avant de vous lancer : systemd est super, mais aussi super chiant parfois…

Configurer systemd

La configuration des éléments réseau de systemd se fait dans le dossier /etc/systemd/network. Pour ce qui nous concerne, on va créer un fichier avec en préfixe un nombre quelconque, par exemple « 30 » puis un nom représentatif pour vous, je prendrai « wired » pour mes liens filaires, et l’extension « .network ». Dans cet exemple, ca me donne donc « 30-wired.network ».

(suite…)

Go to Top