Les pépites d’OpenSolaris : le projet Crossbow

Antoine 2 commentaires

Cette semaine de vacances me permet de faire une petite pause dans la préparation du réseau de l’Utt Arena. Ce billet ne traitera donc pas de cet événement mais d’un autre sujet que je n’ai pas évoqué depuis quelques temps : OpenSolaris. J’ai eu l’occasion de passer pas mal de temps à faire de l’administration réseau sous cet OS et j’y ai découvert des fonctionnalités pour le moins impressionnantes.

Avant de commencer, il est nécessaire de balayer toutes les éventuelles rumeurs quant à une éventuelle disparition d’OpenSolaris suite au rachat par Oracle. De nombreux médias dits « spécialisés » ont publié des informations très largement fausses par rapport aux conséquences du rachat ou ont très largement oublié certains faits. Si vous souhaitez un article relativement neutre sur le sujet, je vous conseille le blog c0t0d0s0.org.

Le projet Crossbow est un sous-projet lié à la distribution OpenSolaris qui a été intégré à la version 2009.06. L’objectif de ce projet était d’adapter la pile TCP/IP à la virtualisation et d’y ajouter de nombreuses fonctionnalités. Je m’intéresserais plus particulièrement aux outils de gestion de bande passante.

La gestion de bande passante ou QoS est une fonctionnalité bien ancrée dans les équipements réseaux. L’objectif de cette technique est de réguler les flux réseau afin de permettre un partage équitable ou bien une limite définie. La mise en place de cette fonctionnalité est particulièrement compliquée et obscure sous Linux. La documentation, particulièrement nécessaire étant donnée la complexité des outils, est difficile à trouver.

OpenSolaris propose un première utilitaire permettant de différencier les différents flux réseaux selon des critères de niveau 3 et 4 : flowadm. Vous allez pouvoir créer un « flow » selon différents critères que vous choisirez. Vous allez ensuite pouvoir attribuer différentes caractéristiques à ce flux. Par exemple, vous pouvez lui donner un ou bien une priorité, voire même une limite de bande passante. L’incroyable avantage de cet outil est la simplicité avec laquelle il est possible de l’utiliser. En une commande, vous arrivez à créer un flux, lui donner une priorité et lui appliquer une limite de bande passante. En voici un exemple :

flowadm add-flow -l bge0 -a transport=UDP -p maxbw=100M, priority=low limit-udp-1

La page de man de flowadm est particulièrement claire et propose de nombreux exemples dont celui ci-dessus. Une seule commande pour faire tout ca, je trouve ca plutôt exceptionnel. La limite minimale de bande passante que vous pouvez attribuer est fonction du MTU. Dans le cas d’un MTU Ethernet classique, il s’agit de 1,2Mbps.

Une autre fonctionnalité très intéressante est la possibilité d’effectuer de « l’accounting » sur les différents flows que vous avez créé. Vous pourriez par exemple avoir envie de connaitre la quantité de données échangées pour chaque flux. OpenSolaris vous propose ceci ainsi que la possibilité de voir la quantité de données échanges par intervalle de temps. Pour cela, vous pourrez utiliser l’utilitaire acctadm. Cet utilitaire vous permet d’activer l’accounting au niveau de votre système et la commande flowadm vous permettra d’en visualiser le résultat.

Ce billet effectue un tour d’horizon rapide de ce que peut proposer le projet Crossbow en termes de gestion de bande passante réseau. OpenSolaris a clairement une grande avance sur Linux sur ce point bien que ce dernier en soit capable, mais clairement pas avec autant de simplicité.

Architecture réseau d’une LAN Party : Configuration des ASA

Antoine 6 commentaires

Ce billet fait suite au précédent qui avait eu pour objectif de définir le contexte de filtrage IP que nous souhaitons mettre en place. Aujourd’hui, nous allons faire un tour de vue du fonctionnement de nos équipements de sécurité et de routage : les Cisco ASA 5510.

Avant de rentrer dans le vif du sujet, arrêtons-nous pour faire un petit point d’avancement. Nous commençons à avoir des configurations de base relativement solides qui nous permettent de déployer la topologie IP du réseau à chaque session de travail. Le montage de cette topologie ne pose désormais plus de problème particulier. Nous avons réussi à résoudre le problème de la communication entre deux interfaces d’un même ASA. La résolution de ce problème nous a permis de simplifier grandement nos configurations en supprimant toutes les identités NAT des interfaces à security-level 100, soit toutes nos interfaces internes. Je suis content de notre avancement et nous devrions aboutir sur une préparation satisfaisante.

Les ASA sont la gamme d’équipements de sécurité Cisco orientés vers l’entreprise. J’emplois le terme d’équipement de sécurité et non de pare-feu car cette terminologie est bien plus proche de la réalité. Les fonctionnalités d’un ASA dépassent très largement celles de filtrage protocolaire IP, TCP et UDP. Je vous laisse consulter la liste de fonctionnalités sur le site de Cisco. Nous avons également une carte SSM-AIP pour chaque ASA permettant de faire de l’IPS ce que nous utiliserons pendant l’événement si nous nous ennuyons (sait-on jamais).

Nous avons 4 équipements Cisco ASA 5510 à notre disposition. La version logicielle associée est la version « Base » contrairement à son équivalent haut de gamme, « Security Plus ». La différence entre ces deux versions est réellement énorme. La version « Security Plus » permet de transformer deux interfaces 10/100 en interfaces Gigabit, de débloquer l’interface 3 et d’utiliser le port de « Management » en tant qu’interface de données.

La configuration des ASA est légèrement différente de celle de routeurs Cisco classiques. Cette différence est liée au fait que les ASA ne sont pas basés sur un IOS mais un « Security Appliance OS ». Il y a de nombreuses similarités mais suffisamment de différences pour devoir se documenter spécifiquement.

Je ne vais pas pouvoir détailler toute la configuration des Cisco ASA dans ce billet car il ferait de très nombreuses pages. Je vais cependant relever les points clés qui nous ont posé problème.

Tout d’abord, les ASA sont faits pour faire du NAT entre toutes les interfaces par défaut. Ceci vient de leur héritage historique vis-à-vis des PIX. Ce comportement induit la nécessité d’effectuer de très nombreuses règles de NAT. Il est, heureusement, possible de désactiver ce comportement grâce à la commande « no nat-control « . Une fois le nat-control désactivé, il sera possible de router en direct entre les interfaces tant qu’on effectue une descente dans les security-level. Il sera nécessaire de faire une petite règle de NAT afin de remonter les security-level. Il est cependant tout à fait possible d’effectuer une règle de NAT qui ne modifie aucunement les adresses IP ni les ports afin que l’ASA se comporte comme un routeur.

Ensuite, les ASA considèrent par défaut que du trafic entre deux interfaces de même security-level effectue une montée de security-level. Ce comportement implique la création de nouvelles règles de NAT. Afin d’éviter ce comportement et de minimiser les lignes de configuration, il est possible d’utiliser la commande « same-security-traffic permit inter-interface « . Ainsi, vous simplifiez votre configuration ce qui est très intéressant.

Je mets à votre disposition la configuration de l’ASA nommé Fuji afin que vous puissiez y jeter un regard plus approfondi que mes explications assez superficielles. Il manque les ACL de filtrage en mode tournoi car nous ne les avons pas encore intégrées ainsi que le paramétrage avancé de l’OSPF.

Architecture réseau d’une LAN Party : Filtrage

Antoine 2 commentaires

Ce billet continue la série de billets traitant de l’architecture d’une LAN Party. Après avoir présenté la topologie IP de notre réseau, nous allons nous intéresser au filtrage IP.

Avant de commencer à traiter ce sujet, je vais faire un petit point d’avancement sur la préparation du réseau. Nous avons passé 2 soirées à configurer les équipements Cisco et nous avons réussi à créer la topologie IP évoqué au billet précédent en 2 heures. Ce résultat est relativement satisfaisant et a été rendu possible par la préparation des configurations à l’avance. La quantité de VLAN ne nous a pas posé de problème particulier car la configuration des équipements Cisco est claire à ce niveau. Il nous reste juste une petite problématique au niveau de la communication entre deux interfaces du même ASA.

Le filtrage IP est une composante nécessaire de notre configuration réseau car les ASA refusent par défaut le trafic réseau. Dans le cadre d’une LAN, nous pouvons dissocier deux périodes : les périodes de tournoi et les périodes sans tournoi. Nous avons décidé d’adapter la configuration réseau en fonction de chaque période.

Le filtrage IP hors tournoi sera le plus permissif possible. Il n’y a aucun intérêt à restreindre les flux émanant des tables. Nous imposerons éventuellement une limite de bande passante au niveau des flux sortant sur Internet afin d’éviter la saturation trop rapide du lien. Ce niveau de filtrage nous permettra de tester notre configuration réseau sans se soucier des ACL.

Le filtrage IP pendant les tournois sera, au contraire, le plus restrictif possible. L’objectif est de limiter les flux au minimum nécessaire pour les jeux. La présence de flux parasites serait susceptibles d’impacter négativement la latence des flux de jeux causant ainsi le mécontentement des joueurs.

Au final, le filtrage IP s’adaptera en fonction des conditions de la LAN. Ceci se concrétisera par deux jeux d’ACL que nous appliquerons aux interfaces en fonction du filtrage souhaité.

Architecture réseau d’une LAN Party : Conception

Antoine 4 commentaires

Ce billet fait suite au précédent qui avait eu pour objectif de définir le contexte d’un réseau d’une LAN et de présenter le projet. Aujourd’hui, nous allons définir l’architecture IP et L2 de notre LAN.

Avant de commencer, je souhaite faire un petit point d’avancement. La préparation de l’Utt Arena a commencé quelque peu en retard au niveau du réseau pour diverses raisons. Les choses avancent donc très vite et je vais essayer de vous faire partager notre avancement sur ce blog du mieux possible. J’approfondirais plus ou moins les sujets en fonction du temps que j’ai à ma disposition.

Je pense que l’architecture d’un réseau se doit d’être la plus simple possible et la plus logique possible. Si un réseau est simplement compréhensible par un humain, il sera plus facile à gérer et les sources d’erreur seront réduites. La conception de l’architecture est une phase exceptionnellement critique sur laquelle repose tout le reste.

L’objectif de notre réseau est le contrôle des flux et la l’optimisation de la latence. Ces deux objectifs sont quelque peu contradictoires car le contrôle des flux implique l’ajout d’intermédiaires de filtrage et de routage. Nous avons essayé de concilier au mieux ces deux objectifs.

Nous avons créé un VLAN par switch de table ce qui correspond à 20 joueurs pour les tournois CS et CSS. Ces deux tournois sont, de loin, les plus problématiques en terme d’utilisation réseau. Ceci nous fait donc 8 VLAN pour CS et 4 VLAN pour CSS. Pour les tournois TrackMania et Warcraft III, nous avons choisi de faire un VLAN par tournoi. Les joueurs Warcraft III jouent entre eux sans passer par un serveur, il est donc plus simple de les placer dans un VLAN dédié.

Tous les VLAN contenant les joueurs seront routés par un ASA. Nous avons ensuite réparti les VLAN équitablement parmi les ASA.

Ensuite, nous devons interconnecter les ASA entre eux. Nous avons choisi le protocole de routage OSPF car il s’agit d’un protocole simple et efficace. La logique traditionnelle voudrait que nous insérions un routeur central afin de router les flux des 4 ASA. Etant donné que notre objectif est la latence, nous avons choisi de ne pas mettre ce routeur. Les ASA seront donc tous interconnectés par le même réseau IP. OSPF est parfaitement capable de gérer cette configuration en passant par l’élection d’un DR (Designated Router).

Nous avons ensuite ajouté deux routeurs standards afin de router les flux des serveurs et des administrateurs. Ces routeurs participeront également à l’OSPF avec les ASA.

Et pour finir la tache la plus importante, le nommage des équipements. Inutile mais tellement indispensable et amusant. Nous avons choisi des noms de volcans pour les ASA et des noms de montagne pour les routeurs. Les ASA s’appelleront ainsi Etna, Fuji, Kilauea et Pinatubo et les routeurs Everest et K2.

Cliquez sur l’image pour l’agrandir.

Au final, nous obtenons un schéma relativement effrayant. Ce dernier nous a permis de nous rendre compte de la taille du réseau que nous avons projeté de mettre en place. La difficulté est, honnêtement, un facteur très motivant. Cette réflexion a été faite avec toute l’équipe réseau et avec le retour de personnes extérieures ce qui a permis de dynamiser la réflexion.

Dans les prochains épisodes : la spécificité de la configuration des ASA et un rebondissement inattendu ! Quel suspens !

Architecture réseau d’une LAN Party : Introduction

Antoine 6 commentaires

J’avoues avoir un peu de mal à poster des billets régulièrement en ce moment. Cela s’explique en partie par une petite baisse de motivation pour le faire mais aussi la reprise des cours qui sont un peu plus nombreux que prévus.

Un autre projet qui va me prendre beaucoup de temps est l’Utt Arena. Mais qu’est ce que l’Utt Arena me diriez-vous ? Il s’agit d’une LAN Party ou, pour faire plus « marketing », un tournoi de jeux vidéo. Ce n’est pas la première fois que je m’investis dans ce projet car j’en avais été président en 2007 et 2008. Depuis, j’ai essentiellement aidé occasionnellement. Pour l’édition 2010, je me suis proposé avec l’aide d’un ami et d’un « nouveau » pour mettre en place et gérer la partie réseau de cette LAN.

Une LAN est un événement d’envergure dans lequel les joueurs ramènent chacun leur ordinateur. Le principal problème provient de ce fait. Il serait possible de croire que les joueurs ont des machines « de course » avec une installation (Windows, forcément) propre. La réalité est tout autre. Nous retrouvons les « versions » les plus exotiques de Windows remplies jusqu’aux oreilles de malware et d’applications non recommandables.

Lors des précédentes éditions, nous avons choisi la simplicité par manque de moyens matériels et humains. Tous les joueurs étaient disposés sur un même LAN (au sens IP du terme) avec un DHCP pour leur allouer des adresses IP automatiquement. L’inconvénient est que tous les ordinateurs pouvaient communiquer sans restriction. Dans de telles conditions, les partages de films interdits aux mineurs et la prolifération des malwares en tous genre sont optimaux.

De plus, il était quasiment impossible d’avoir une visibilité quelconque sur les différents flux échangés ainsi qu’une évaluation de la latence. Ah la latence, parlons-en. Les participants à une LAN ne jurent que par elle. Au dessus de 10 ms affichées par le jeu Counter-Strike, le réseau est considéré trop lent. Bien que des astuces soient possibles au niveau des serveurs de jeu afin d’optimiser l’affichage de cette latence, l’optimisation du réseau est primordiale.

Cette année, nous avons réussi à mettre la main sur une batterie d’équipements de sécurité robustes. Nous aurons à notre disposition 4 firewalls Cisco ASA 5510 ainsi que quelques routeurs Cisco 2800 Series. L’ajout d’intermédiaires de communication au niveau IP induira inéluctablement une latence supplémentaire. Cela nous permettra cependant de pouvoir réellement maitriser notre réseau et de bénéficier des fonctionnalités de QoS du Modular Policy Framework Cisco. Nous espérons sincèrement que cet ajout de latence sera minime au regard des avantages fournis par les fonctionnalités de ces équipements.

Ce billet est le premier d’une série de billets ayant pour objectif de détailler le processus de mise en place de cette architecture ainsi que des différents outils (open source, bien sur) d’évaluation des performances réseau. Elle sera clôturée par un retour d’expérience suite à l’événement qui aura lieu du 16 au 18 Avril. En attendant, je retourne éplucher les différentes documentations des ASA.

Dangers du cloud computing : l’interopérabilité

Antoine 3 commentaires

Ce billet fait suite au premier sur les dangers du cloud computing qui s’était plus orienté vers la sécurité des données placées dans le cloud. La seconde problématique que je souhaitais aborder est la celle de l’interopérabilité entre les clouds.

Lorsqu’une architecture est conçue initialement, les concepteurs disposent d’un certain nombre d’éléments motivant un choix technologique par dessus un autre. Dans le cas du cloud computing, ces éléments ne sont pas fixés depuis une durée particulièrement longue et ne sont clairement pas fixés à des échéances au delà du moyen terme. La relative nouveauté du cloud computing devrait démotiver bon nombre de concepteurs d’architecture.

Dans le cas où le choix serait fait de se baser sur une architecture intégrée au sein d’un cloud quelconque, il est nécessaire de se poser très sérieusement la question de l’interopérabilité. Lorsqu’une entité va placer son architecture,  elle confiera d’une part ses données mais aussi le travail humain lié à la conception d’une plateforme. Ce travail humain a un coût relativement important en fonction de l’architecture en question. De sérieux problèmes sont à envisager dans l’éventualité d’une faillite de la société hébergeant le cloud ou même une catastrophe quelconque mettant à mal le cloud. La non-transparence des clouds actuels rend exceptionnellement compliqué l’évaluation de ces risques.

La problématique de l’interopérabilité se pose ainsi. Dans le cas où une entité utilisatrice utilisatrice d’infrastructure cloud souhaite changer d’hébergeur pour une raison X ou Y, en a-t’elle la possibilité ? Il y a bien sur plusieurs niveaux de réponse à cette question. Nous pouvons envisager une situation dans laquelle il lui est juste possible de récupérer les données applicatives ce qui impliquerait de devoir reconstruire la quasi totalité de l’infrastructure applicative. Nous pouvons également envisager une situation où il est possible de récupérer une version « packagée » des machines virtuelles ou, à l’opposé, une situation où rien n’est prévu pour être compatible avec d’autres plateformes.

De plus, ce n’est pas parcqu’il est possible de récupérer une machine virtuelle qu’il sera possible de l’exécuter sur une autre plateforme sans devoir se plonger dans les méandres du système d’exploitation pour peu que celà soit même possible.

Au final, l’interopérabilité est un enjeu majeur de toute plateforme informatique et suscite de nombreux débats habituellement. Les problématiques d’interopérabilité dans le cloud computing ne semblent pas encore avoir passioné grand monde ce qui est dommage car elle est bien réelle et existante. Le logiciel libre a clairement un rôle à jouer dans le cadre de cette standardisation avec les acteurs majeurs de l’industrie associée.