Tag - tomato

Entries feed

Saturday, October 28 2017

Tomato by Shibby n'est peut-être pas mort ? Mais vive LEDE malgré tout !

Si j'en crois Wikipedia, l'histoire du micrologiciel Tomato remonte au vénérable Linksys WRT54G et au projet HyperWRT qui avait été développé pour ce routeur. HyperWRT a été supporté par les bénévoles de 2004 à 2008 et en 2008 un fork aura lieu et mènera à Tomato qui sera développé jusqu'en version 1.28. Et là, nouvel abandon, et nouveaux forks, celui de Shibby (un développeur polonais) acquiert une certaine renommée. En 2017, deux vulnérabilités majeures sont publiées :

  • l'une concerne le logiciel dnsmasq (un petit serveur DNS/DHCP) : elle est publiée le 2 octobre 2017 sous le numéro CVE-2017-14491. Brièvement, une faille est détectée qui permet l'exécution de code distant sur une machine propulsant dnsmasq
  • la seconde est KRACK, la découverte par un chercheur belge d'une faille dans le protocole WPA2

Deux très bonnes raisons de mise à jour !

Tous les utilisateurs de firmware de routeurs & points d'accès se sont alors tournés vers les fournisseurs de ceux-ci, et les utilisateurs de Tomato by Shibby ont attendu avec impatience la sortie d'une nouvelle version. Malheureusement, deux semaines après ces annonces, aucun signe de vie et le site qui hébergeait les données de Tomato by Shibby n'est plus accessible au moment où j'écris ces lignes.

Edition au 30 octobre, 8h19 : Shibby m'a répondu - ce n'est qu'un problème temporaire de réseau chez le fournisseur de VPS qui héberge son site internet. Il répond également sur la mise à jour KRACK de la façon suivante : Tomato is using NAS daemon for WPA2 security. The problem is that sources for this daemon are closed by Broadcom. So we have to wait when Asus or Netgear etc will fix it and then try to move newer binaries to Tomato. But that means (probably) only newest routers will have fix for KRACK. I dont think that Asus etc will release fixed firmwares for Mipsel..

Il y a de nombreuses distributions basées sur Tomato by Shibby et d'autres forks de Tomato (cf. la page de Wikipedia sur Tomato, cependant si celle-ci est un jour, aucun des forks n'a été mis à jour post-annonce de KRACK ce qui n'augure rien de bon). Le code source étant disponible, de bonnes âmes expertes sauront peut-être faire renaître la tomate de ses cendres.

Pas de panique, il semble que LEDE soit une bonne alternative à Tomato dans la plupart des cas. Supporté par une communauté qui semble un peu plus large (Tomato by Shibby est (était), ne semble-t-il, soutenu que par un seul homme), LEDE est un fork d'OpenWRT. La dernière version 17.01.4 est très stable, très pratique et a été patchée pour KRACK !

Il est délicat de comparer LEDE et Tomato : là où Tomato se borne (bornait ?) à propulser routeurs et autres périphériques réseau, LEDE (Linux Embedded Development Environment) veut aller plus loin et propose une véritable micro-distribution avec gestion de paquets (avec l'utilitaire opkg). L'interface graphique LuCI de LEDE est très agréable, elle comporte moins de fonctionnalités que Tomato et il est probable qu'il faille recourir plus fréquemment à la ligne de commande de LEDE pour les paramétrages complexes possibles dans Tomato (par ex. la QoS, la gestion avancée des VLAN etc...). Mais dans les situations simples, LEDE peut-être un remplacement immédiat à Tomato. Pour les cas complexes, la migration est à évaluer, surtout si personne ne reprend le flambeau de Shibby !

Pour découvrir LEDE, c'est ici.

Saturday, February 27 2016

Tomato : utiliser la puissance d'iptables pour contrôler les flux sur les différentes interfaces

Voici quelques lignes à introduire dans la configuration d'un routeur/point d'accès propulsé par Tomato (dont on a déjà parlé dans ces articles) pour interdire aux périphériques branchés sur une interface d'accéder à certains sous-réseaux. Cela peut être pratique lorsque l'on veut interdire à certains périphériques (par exemple des périphériques connectés sur un réseau "invité") d'accéder à certaines ressources locales.

La petite subtilité est la suivante : il est nécessaire d'introduire les règles nouvelles en amont des règles existantes. Et pour ce faire, il faut donc utiliser l'option '-I' d'iptables en précisant la ligne à laquelle on souhaite insérer la nouvelle commande.

Ainsi :

iptables -P FORWARD DROP
iptables -I FORWARD 1 -i br0 -j ACCEPT
iptables -I FORWARD 2 -i br1 -d 192.168.0.0/16 -j REJECT
iptables -I FORWARD 3 -i br1 -j ACCEPT

conduit au comportement suivant :

  • par défaut tout est rejeté
  • on accepte tout en provenance de l'interface br0 (par exemple un Wifi 'maître des lieux')
  • on refuse tous les accès den provenance de l'interface br1 (par exemple un Wifi 'invité') à destination des IPs du sous-réseau 192.168.0.0/16
  • on accepte tout le reste de l'interface br1

Voilà, le tour est joué,

Wednesday, August 12 2015

Dnsmasq, mon meilleur ami aussi pour le boot PXE !

Dnsmasq est un super petit serveur DNS et DHCP à destination des bricoleurs : fort simple à déployer et utiliser, il est parfait pour les installations domestiques ou celles des petites entreprises (on en a déjà parlé ici, ici et ici). Dnsmasq est par exemple employé au sein du micrologiciel (firmware) pour routeur Tomato car il est léger et en même temps très puissant.

J'ai découvert aujourd'hui une nouvelle corde à l'arc de Dnsmasq : il possède des fonctionnalités TFTP (Trivial File Transfer Protocol) qui permettent de l'utiliser pour booter un ordinateur (un serveur par exemple) en mode PXE (Preboot Execution Environment) en quelques lignes de configuration seulement.

L'usage est fort simple, tout se règle dans le fichier de configuration /etc/dnsmasq.conf :

dhcp-boot=pxelinux.0,pxeserver,192.168.18.11
pxe-service=x86PC, "Install Linux", pxelinux
enable-tftp
tftp-root=/tmp/tftp

Les 4 lignes sont assez explicites :

dhcp-boot=pxelinux.0,pxeserver,192.168.18.11
pxe-service=x86PC, "Install Linux", pxelinux

propose à chaque système en faisant la requête de démarrer en mode PXE en interrogeant 192.168.18.11 comme serveur de boot PXE. Pour que la suite fonctionne, il faut évidemment que 192.168.18.11 pointe vers l'hôte hébergeant le service Dnsmasq lui-même.

Puis

enable-tftp

active le TFTP de Dnsmasq.

Et enfin,

tftp-root=/tmp/tftp

indique où trouver le répertoire qui sera servi au travers de TFTP.

Si l'on veut démarrer l'installation de Debian par exemple, on aura préalablement décompressé netboot.tar.gz dans ce dossier ! Et miracle, tout périphérique cherchant à démarrer avec PXE sur le réseau va interroger Dnsmasq et récupérer le nécessaire pour le boot. Démarrer un serveur en PXE devient alors très facile !

Friday, July 10 2015

Routeur avec Tomato, Fibre Orange, VLAN 835

Comme déjà exposé ici, il est possible de se passer de la Livebox d'Orange et d'avantageusement la remplacer par un routeur "évolué" muni du micrologiciel Tomato.

Dans le précédent article, je détaillais le mode opératoire avec le routeur Asus RT-N16. J'ai eu l'occasion dernièrement de répéter l'opération avec l'Asus RT-N18U. Le nouveau mode opératoire est très similaire sauf qu'il ne faut pas utiliser de VID offset pour que cela fonctionne :

Paramétrage PPPoE pour le WAN

Dans l'onglet principal de Tomato, on choisit une connexion PPPoE pour le WAN et on saisit le nom d'utilisateur 'fti/xxxxx' et le mot de passe pour la connexion.

Puis on bascule le WAN dans le VLAN 835

Il faut alors se rendre dans les options avancées, catégorie VLAN.

  • On sélectionne la ligne correspondant au VLAN du WAN et on on saisit 835 comme VID.
  • Il ne faut pas oublier également de cocher la case 'Tagged' pour demander au retour de bien prendre en compte le trafic 'marqué' comme appartenant au VLAN 835.

vlan835-asus-rt-n18u.png

Et voilà le tour est joué. On sauvegarde, le routeur inscrit ces paramètres dans sa nvram et redémarre. On voit que le WAN PPPoE parvient à se connecter à internet et le routeur distribue internet à tous les postes du réseau qui le référencent comme passerelle.

Firmware Tomato (by Shibby) sur Asus RT-N18U

J'ai déjà parlé à plusieurs reprises dans ces pages du micrologiciel Tomato pour les routeurs. J'ai récemment acquis un routeur Asus RT-N18U et me suis empressé d'installer Tomato dessus.

Pour ce faire,

  • on télécharge d'abord la version ARM du firmware ici : http://tomato.groov.pl/download/K26ARM/
  • on extrait le fichier .trx de l'archive
  • on allume le routeur Asus RT-N18U (encore équipé de son micrologiciel natif) et on se rend dans "Administration", "Mise à jour du firmware". On sélectionne alors le fichier .trx de Tomato et on laisse le processus de mise à jour se faire
  • une fois le routeur redémarré, on effectue un "factory reset" avec le bouton dédié pour vider la mémoire des paramètres non adéquats (liés au micrologiciel natif)
  • et hop le tour est joué, on peut alors se connecter au micrologiciel Tomato et enfin profiter de toute la puissance du routeur

Tomato semble fonctionner sans difficulté sur ce matériel - qui, dans mes tests initiaux, a été très performant. A recommander donc !

Sunday, May 17 2015

Augmenter la qualité de service avec la QoS des routeurs sous Tomato

Le firmware Tomato (utilisable dans certains routeurs) continue à m'émerveiller de jour en jour. Je découvrais dernièrement les fonctionnalités de QoS (Quality of Service) qu'il contient. Elles permettent d'activer des règles classiques de QoS pour optimiser les flux sur une connexion au moyen de règles.

Les règles de QoS sont bien évidemment indispensables lorsque les connexions sont massivement partagées pour éviter que quelques utilisateurs actifs en P2P ou effectuant des téléchargements ou téléversements massifs ne viennent rendre la connexion commune utilisable. Elles peuvent aussi améliorer la qualité d'une connexion SIP en la protégeant quelque peu des soubresauts liés à des téléversements (surtout sur des connexions ADSL où le débit montant est limité) réalisés sur le même réseau. De bonnes règles de QoS peuvent également participer à maintenir des latences acceptables en s'assurant qu'un trop grand nombre de paquets n'est pas en train de s'accumuler à l'entrée du réseau du fournisseur d'accès (juste avant le goulot d'étranglement de la connexion ADSL).

Dans Tomato, la QoS s'active très simplement :

  • on se rend dans le menu dédié et on l'active

qos-settings-tomato.png

  • il est également possible de visualiser le trafic du réseau réparti suivant les différentes catégories de la QoS :

qos-plots-tomato.png

  • et bien sûr il est possible de rajouter des règles pour répartir le trafic dans les 11 catégories proposées par défaut !

Et ensuite ? Ensuite vient le temps du paramétrage : pour chaque catégorie de service on vient placer une limite en débit montant et en débit descendant. On peut donc laisser certains flux prendre la totalité de la bande passante et limiter d'autres de façon à sacraliser une part de la bande passante à d'autres usages. Si vous disposez d'une connexion ADSL avec un débit montant faible, vous vous dites sans doute que seules des limites 'outbound' doivent être établies car c'est la ressource rare : en fait il est important de limiter aussi le débit descendant afin de forcer le routeur à refuser certains paquets qui arrivent. L'expéditeur du paquet réalisera (automatiquement, c'est le fonctionnement normal du réseau) que des paquets se perdent et il réduira ainsi son rythme d'envoi... ce qui évitera l'accumulation de paquets à l'entrée de votre ligne ADSL et devrait permettre de réduire ainsi la pile des paquets en attente pour votre réseau et contribuant ainsi à réduire la latence de votre réseau.

Les règles affichées ci-dessous ne sont pas optimales : je réalise que régler la QoS est une affaire qui demande pas mal de tests et de doigté ; tout est très dépendant des usages sur votre réseau, des priorités et finalement cela laisse la part belle au essais/erreurs !

qos-limits.png

Ah j'allais oublier : voici une référence intéressante sur les mécanismes de QoS : http://tomatousb.org/tut:using-tomato-s-qos-system. J'ai transformé cette page web en ePub pour une lecture facilitée : QoS_TomatoUSB.epub. Bonne lecture !

Bon QoSing !

Thursday, January 8 2015

Activer un réseau Wifi invité sur un routeur avec le micrologiciel TomatoUSB

Nous allons détailler ici les étapes nécessaires pour activer un Wifi "invité" sur un routeur muni du micrologiciel Tomato (TomatoUSB). Par Wifi invité, j'entends un Wifi indépendant du Wifi principal : idéal par exemple pour partager sa connexion avec un voisin ou un ami que l'on ne souhaite pas voir fureter sur son réseau interne. Bien aussi pour les petites entreprises qui veulent présenter à leurs visiteurs un Wifi avec accès à internet mais déconnecté du reste du réseau de l'entreprise.

Voici donc comment procéder.

Etape 1 : créer une interface LAN spécifique avec son propre intervalle d'IP, son propre DHCP...

Dans TomatoUSB, dans l'onglet LAN, vous devriez vraisemblablement voir le bridge par défaut br0 correspondant à votre interface principale d'accès au Web. Nous allons ajouter une nouvelle interface br1 avec son propre DHCP et son propre intervalle d'IP.

guest-wifi-img1.png

Etape 2 : créer une interface sans fil virtuelle

Dans les fonctions avancées du micrologiciel TomatoUSB, nous allons cette fois ajouter une interface sans fil virtuelle.

guest-wifi-img2.png

Evidemment, il conviendra de choisir un code de sécurité différent de celui de l'interface principale !

Etape 3 : on place chaque réseau dans des VLANs distincts

On crée un nouveau VLAN distinct du VLAN principal utilisé pour br0. On branche donc br1 sur ce VLAN et voilà un bon cloisonnement !

guest-wifi-img3.png

Etape 4 : on rajoute une couche d'iptables

Dans Administration->Scripts, on ajoute les règles suivantes au pare-feu (iptables) pour n'autoriser aucun échange entre les 2 bridges.

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o br0 -j ACCEPT
iptables -A FORWARD -i br0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o br1 -j ACCEPT
iptables -A FORWARD -i br1 -o eth0 -j ACCEPT

et hop le tour est joué !

Sunday, January 4 2015

Tomato, VLAN & WAN: this is poorly documented!

It is not obvious to change the VLAN for the WAN port on a router using the Tomato firmware. This might be a necessity when the PPPoE infrastructure of your internet provider requires such a setting.

This is the case in France with the Orange provider (not for DSL but for fiber access): the internet traffic should transit on the VLAN 835.

To do so with Tomato:

  1. choose the PPPoE connection for the WAN (do not forget username and password if needed)
  2. get to the Advanced settings, VLAN page and change the VID for the WAN to correspond to the required VLAN. With some routers (such as the Asus RT-N16), changing the VID does not work and you should in fact add an offset and change the VLAN number. As an example, for VLAN 835, you have to choose a VID offset of 832 and set the WAN to the VLAN 3. Then VID should automatically change to 835.
  3. save and reboot, the WAN connection should now work

You can see below the appropriate setting for a WAN over VLAN 835 as requested by French Orange provider.

vlan835-orange-tomato.png

Hope this helps!

Fibre FTTH Orange et routeur avec micrologiciel Tomato : l'astuce du VLAN

Si la Fibre Optique FTTH d'Orange offre une bonne qualité de service (du moins dans mon expérience), la LiveBox pro fournie est selon moi une catastrophe : instable, ne re-démarrant pas toute seule en cas de coupure de courant, possibilités de paramétrage faibles...

J'ai très vite décidé de la renvoyer à Orange et de la remplacer par un routeur Asus RT-N16 équipé du micrologiciel Tomato (by Shibby). J'ai donc conservé le convertisseur fibre/RJ45 mais ai ré-envoyé la Livebox elle-même à l'opérateur (ce qui m'a valu d'ailleurs la disparition des frais de location de modem sur ma facture).

Je n'étais cependant pas au bout de mes peines car l'infrastructure de la Fibre Orange nécessite un paramétrage particulier de VLAN pour fonctionner.

Comme expliqué ici, le vénérable VPI/VCI 8/35 de l'ADSL a été remplacé en Fibre chez Orange par un VLAN 835. Concrètement, le routeur doit s'enregistrer et communiquer sur ce VLAN 835 pour discuter avec les équipements réseaux d'Orange et obtenir une adresse IP puis faire transiter le trafic vers internet.

Il faut donc apprendre au micrologiciel Tomato que le port WAN du routeur (celui connecté filairement au convertisseur fibre/RJ45) doit communiquer exclusivement sur ce VLAN.

On choisit le PPPoE pour le WAN...

Dans l'onglet principal, on choisit une connexion PPPoE et on saisit le nom d'utilisateur 'fti/xxxxx' et le mot de passe pour la connexion.

... et on bascule le WAN dans le VLAN 835

Il faut alors se rendre dans les options avancées, catégorie VLAN.

  • Dans VID offset, on saisit : 832 (c'est le multiple de 16 le plus proche de 835).
  • Puis on sélectionne la ligne correspondant au VLAN du WAN et on on choisit le numéro de VLAN 3. Automatiquement, le VID (VLAN ID) doit devenir 835 (832 d'offset + 3).
  • Il ne faut pas oublier également de cocher la case 'Tagged' pour demander au retour de bien prendre en compte le trafic 'marqué' comme appartenant au VLAN 835.

vlan835-orange-tomato.png

Et voilà le tour est joué. On sauvegarde, le routeur inscrit ces paramètres dans sa nvram et redémarre. On voit que le WAN PPPoE parvient à se connecter à internet et le routeur distribue internet à tous les postes du réseau qui le référencent comme passerelle.

A noter : Sur ASUS RT-N16, il a été nécessaire d'utiliser l'Offset. Il semblerait que sur des modèles de routeur plus récents, il ne soit pas nécessaire de changer l'offset mais seulement de modifier manuellement le VID.