Archive for mars, 2018

[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.

Go to Top