Cloisonnement d’un réseau à l’aide de VRF : Introduction

stepfinal2Je vais commencer une nouvelle série d’article plus orientée vers le réseau. Je n’ai eu que relativement peu d’occasions de parler de réseau sur ce blog mais je vais me rattraper quelque peu. Cette série devrait comporter 3 articles voire peut être un peu plus, en fonction de mon humeur. Elle est le résultat d’une journée d’expérimentation effectuée avec un collègue dans le cadre de mon stage. Dans ce billet d’introduction, je vais présenter l’objectif de l’expérimentation, le matériel utilisé et la topologie.

La problématique

Lorsque nous nous sommes lancés dans ces expériences, nous avions un objectif bien précis correspondant à la réalité d’une architecture actuellement en production. La problématique était d’isoler au niveau IP plusieurs clients pouvant potentiellement avoir des plages d’IP similaires. Plus concrètement, l’objectif était d’isoler chaque client dans sa « bulle de routage » afin de pouvoir avoir une plus grande liberté dans l’évolution de l’architecture et dans l’intégration de nouveaux clients.

Nous savions déjà qu’il était possible de résoudre le problème d’isolation par le biais des VRF de Cisco. Pour rappel, une VRF est une « bulle de routage » spécifique à un groupe de ports. Typiquement, une VRF correspond à un client spécifique. La véritable difficulté venait du fait que nous souhaitions également qu’il soit possible de communiquer de manière sélective entre les différentes VRF.

Le matériel utilisé

Afin de pouvoir tester la mise en place de cette idée, nous avons ressorti des équipements Cisco qui se trouvaient fortuitement sur notre chemin. Ce jour là, notre chemin a rencontré deux Cisco 7204 VXR ainsi que deux Cisco 2970G. Chaque 7204 VXR était doté d’une carte de supervision avec 2 ports 100Mbit/s ainsi que d’un module 1 interface 100Mbit/s supplémentaire. Nous avons donc mélangé tout ce matériel pour faire deux routeurs différents : le « Routeur 1  » sans module supplémentaire et le « Routeur 2  » avec les deux modules supplémentaires.

Voici une petite photo du montage que nous avons effectué.

matosLe « Routeur 1  » était le routeur du haut et le « Routeur 2  » était le routeur du bas. Au niveau des switchs, nous n’avons utilisé que celui du bas. Les ports 1 et 2 servaient pour le réseau « Interco ». Les ports 13 à 16 étaient le VLAN de Prod. Les ports 17 à 20 étaient le VLAN Client 1. Les ports 21 à 24 étaient les VLAN Client 2. Le câble permettait de relier le PC de test.

Topologie logique

Le schéma suivant représente la topologie logique que nous avons mis en place.

SchemaGlobalSmall

Le « Routeur 1  » est le routeur qui pourrait faire office de routeur de sortie vers Internet. La route par défaut de notre réseau pointera sur lui. Le « Routeur 2  » est le routeur « coeur » qui arbitrera toutes les VRF et les échanges de routes. Les trois switch du bas du schéma sont les différents LAN de nos clients. L’objectif sera de faire communiquer les LAN client avec le routeur 1 et le LAN de Prod.

Au final, cet article avait pour objectif de vous présenter la topologie et la problématique. Le prochain article s’attachera  la configuration des équipements et la mise en place des VRF.

Articles de la série

Configuration réseau d’OpenSolaris

solarisJe vous ai déjà fait une présentation succincte de Solaris et introduit la prise en main d’un tel système d’exploitation. Au fur et à mesure que je découvre, de mon coté, OpenSolaris, je rencontre différents problèmes. Un problème assez handicapant que j’ai rencontré est la configuration réseau.

Lorsque j’ai monté ma machine virtuelle OpenSolaris, j’ai fait la configuration réseau à la main rapidement via l’utilitaire ifconfig. Je ne représenterais pas cet utilitaire dans ce billet. Son fonctionnement sous Solaris est fortement similaire à son fonctionnement sous Linux. L’utilitaire route fonctionne de manière similaire pour l’ajout de routes. Il est cependant différent dans la mesure où il ne permet pas l’affichage de la table de routage via la commande route -n. Afin d’afficher la table de routage, il est nécessaire d’exécuter la commande netstat -rn.

La problématique de ce type de configuration est que la configuration n’est pas conservée après un redémarrage du système d’exploitation. Nous allons donc nous intéresser plus spécifiquement à la configuration pérenne des interfaces réseau en IP statique. La configuration se fera via le module physical:default.

Tout d’abord, vous allez devoir déclarer le nom d’hôte de votre machine. Vous remplacerez xnf0 par le nom de votre interface réseau.

echo « hostname »> /etc/hostname.xnf0

Ensuite, on sauvegarde le fichier hosts d’origine et on y insère les noms d’hôte de votre machine.

echo « 127.0.0.1 localhost »> /etc/inet/hosts

echo « 10.0.0.3 antoinebenkemoun.fr »>> /etc/inet/hosts

Nous allons ensuite spécifier le masque de sous-réseau lié à cette interface.

echo « 10.0.0.0 255.0.0.0 »>> /etc/inet/netmasks

Il nous reste plus qu’à préciser la route par défaut.

echo « 10.0.0.1 »> /etc/defaultrouter

La configuration de l’interface est désormais terminée. Il ne nous reste plus qu’à vérifier que les bon services sont activés. Nous devons activer le service physical:default et désactiver physical:nwam. Ce deuxième service est un doublon du premier, il ne faut donc en activer qu’un seul.

svcadm disable svc:/network/physical:nwam

svcadm enable svc:/network/physical:default

Afin de faire prendre en compte les modifications d’interface réseau, il est nécessaire de redémarrer le service physical:default.

svcadm restart svc:/network/physical:default

Le tour est joué ! Je pense que ce billet devrait être utile à certaines personnes démarrant sous Solaris et venant du monde de Linux. Dans tous les cas, il me sera utile pour future référence.

La configuration réseau de Xen

J’ai déjà eu l’occasion d’évoquer la spécificité de la configuration réseau dans le cadre d’une plateforme de virtualisation dans un précédent billet. Je vais traiter ici des différentes configuration réseau possible avec Xen. Bien que cet article s’attachera aux modes présents dans Xen, vous pourrez sans aucun doute retrouver dans d’autres solutions de virtualisation. Si vous souhaitez un rappel de la terminologie Xen qui sera utilisé ici, je vous invite à relire l’article sur la terminologie.

Les trois modes de configuration réseau dans Xen sont : bridge, route et NAT. En Français, nous aurons donc pont, routage et NAT. Ces trois modes répondent à différents besoins en terme de configuration réseau. Le premier critère de choix du mode réseau est la topologie logique du réseau existant. Les éléments de topologie vont inclure les VLAN ainsi que les différents réseaux IP.

Le mode pont

RzoXen-Bridge

Le schéma ci-dessus explique le fonctionnement du mode pont. Il s’agit du mode le plus simple agissant au niveau le plus bas. Les domU sont connectés au dom0 via des interfaces réseau virtuels. Le dom0 ne fait qu’une simple commutation en redirigeant les trames soit vers le bon domaine soit vers le reste du réseau.

L’avantage de ce mode est l’extrême simplicité de la configuration qui permet une transparence par rapport au reste de l’architecture. La configuration des domU est également simple et ne nécessite aucune particularité. Il est possible de superposer n’importe quelle configuration IP en utilisant ce mode. Vous remarquerez que ce mode ne prend pas en compte les VLAN nativement. Nous verrons ultérieurement une possibilité de fonctionnement de ce mode avec la prise en compte des VLAN via 802.1Q.

Le mode routage

RzoXen-Route

Le schéma ci-dessus explique le fonctionnement du mode routage. Il s’agit d’un mode assez peu utilisé. La raison de la faible utilisation de ce mode est lié au fort lien entre topologie physique et topologique logique. Je m’explique. Avec cette configuration, il est pratiquement impossible de migrer des machines virtuelles entre des machines physiques sans modification de routage.

Ce mode est cependant très utile dans le cadre d’un serveur OVH doté d’IP supplémentaires. Ceci est du au fait qu’une bonne partie des serveurs OVH ne supportent pas le mode pont pour un raison inconnue.

Le mode NAT

RzoXen-NAT

Le mode NAT est une évolution du mode routage. Vous avez toujours deux plages d’IP différentes de part et d’autre du dom0 mais les IP des domU ne seront pas visibles sur le réseau public.

Par défaut, ce mode permet un accès au réseau public par les domU mais pas d’accès dans le sens inverse. Vous pourrez mettre en place des accès dans le sens inverse en utilisant iptables.

Les mystères de la commande ping

pongJe vais faire une petite parenthèse dans ce billet sur la commande ping. Vous allez me dire que vous connaissez déjà bien la commande ping, ce dont je ne doute pas. Elle sert habituellement à vérifier la connectivité réseau d’une machine sur un réseau ou à travers plusieurs réseaux. Mais connaissez-vous complètement cette commande ?

A travers une erreur de frappe, je me suis retrouvé à découvrir quelques « mystères » par rapport à cette commande. Je tiens à remercier mon collègue Laurent et son erreur de frappe qui nous a permis de découvrir ces « mystères ». Ils ont été testés sur Windows XP et Linux.

L’utilisation habituelle de la commande ping ressemble à la commande suivante et vous donne le résultat indiqué.

root@serveur:~ # ping 10.2.0.10

PING 10.2.0.10 (10.2.0.10): 56 data bytes

64 bytes from 10.2.0.10: icmp_seq=0 ttl=255 time=0.173 ms

64 bytes from 10.2.0.10: icmp_seq=1 ttl=255 time=0.134 ms

— 10.2.0.10 ping statistics —

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max/stddev = 0.134/0.153/0.173/0.000 ms

Premier mystère

Vous avez déjà surement fait des fautes de frappe en tapant cette commande, mais avez-vous déjà regardé le résultat que cela produit ? Voici un exemple du ping vers l’IP 10.2.017.

root@serproxy01:~ # ping 10.2.017

PING 10.2.017 (10.2.0.15): 56 data bytes

64 bytes from 10.2.0.15: icmp_seq=0 ttl=255 time=0.824 ms

64 bytes from 10.2.0.15: icmp_seq=1 ttl=255 time=0.525 ms

— 10.2.017 ping statistics —

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max/stddev = 0.525/0.674/0.824/0.150 ms

On pourrait s’attendre à ce que la commande ping nous retourne un erreur. La syntaxe de l’écriture de l’adresse IP que nous avons saisie est cependant mauvaise… Vous pouvez essayer avec n’importe quelle IP, cela fonctionne de manière similaire. Nous voyons qu’un ping vers la 10.2.017 effectue en réalité un ping vers l’adresse 10.2.0.15. Un ping vers l’adresse 10.2.0.15 aurait été tout à fait logique mais ce n’est pas le cas. Quel est donc le lien entre 10.2.017 et 10.2.0.15 ? Je vous laisse essayer avec différentes IP afin d’essayer de trouver le lien logique.

Explication

Vous avez trouvé ? J’espère bien. Les plus futés d’entre vous auront remarqué que 017 correspond à 15 en base 8 ou octal. Pour la petite explication :

0 x 64 + 1 x 8 + 7 x 1 = 8 + 7 = 15.

Second mystère

Nous avons donc réussi à percer ce premier mystère. Alors que nous étions en train de chercher la solution au premier, nous avons rencontrer une seconde bizarrerie. Essayez la commande ping 10.3.2947 et remarquez le résultat produit.

D:\Documents and Settings\Administrateur>ping 10.3.2947

Envoi d’une requête ‘ping’ sur 10.3.11.131 avec 32 octets de données :

Réponse de 10.3.11.131 : octets=32 temps<1ms TTL=128

Statistiques Ping pour 10.3.11.131:

Paquets : envoyés = 1, reçus = 1, perdus = 0 (perte 0%),

Durée approximative des boucles en millisecondes :

Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms

Dans la même veine, nous pouvons essayer la commande ping 10.199449 et observer le résultat.

D:\Documents and Settings\Administrateur>ping 10.199449

Envoi d’une requête ‘ping’ sur 10.3.11.25 avec 32 octets de données :

Réponse de 10.3.11.25 : octets=32 temps<1ms TTL=128

Réponse de 10.3.11.25 : octets=32 temps=1 ms TTL=128

Statistiques Ping pour 10.3.11.25:

Paquets : envoyés = 2, reçus = 2, perdus = 0 (perte 0%),

Durée approximative des boucles en millisecondes :

Minimum = 0ms, Maximum = 1ms, Moyenne = 0ms

Après le premier mystère, on commence à comprendre que la commande ping agit selon une logique étrange. Vous remarquerez qu’il ne s’agit plus, cette fois-ci, de base 8. Une fois de plus, cela fonctionne avec n’importe quelle IP formatée selon ce mode. On voit facilement qu’on n’est plus en base 8 car le chiffre 9 ne nous renvoie pas d’erreur particulière. Je laisse chercher les plus intrépides d’entre vous. Les autres, vous pouvez continuer à lire cet article.

Vous avez trouvé ? Vous en êtes bien sur ? Les plus futés d’entre vous auront remarqué que nous ne sommes plus en base 8 mais en base 256. Pour démontrer ce fait, je ferais appel à la division avec reste entier.

Explication

Reprenons le premier exemple :

2947 / 256 = 11 reste 131.

Etant donné le préfixe 10.3, vous avez donc 10.3.11.131.

Reprenons le second exemple :

199449 / (256 x 256) = 3 reste 2841

2841 / 256 = 11 reste 25

Nous avons donc 10.3.11.25. Pour vous en convaincre, vous pourrez voir que :

256 x 256 x 3 + 256 x 11 + 25 = 199449.

Au final, j’espère que cet article vous a plu et vous a un peu retourner le cerveau, car s’en était bien l’objectif. Vous ne verrez plus la commande ping de la même manière désormais.

Un peu de QoS avec Pfsense

J’ai déjà eu l’occasion de vous parler de Pfsense dans un précédent billet. Pour rappel, il s’agit d’une distribution basée sur FreeBSD qui a pour objectif de founir différents services réseau. Cette distribution brille par sa simplicité d’utilisation et par son nombre conséquent de fonctionnalités.

pfsense-logo

Un des grands avantages de Pfsense est de disposer d’un système de gestion de paquets. Ce système permet de pouvoir facilement rajouter des applications tierces.

Dans notre cas, nous avons un LAN qui contient un certain nombre de postes. Le problème de ce LAN est qu’il a la fâcheuse tendance de consommer toute notre bande passante. Nous allons donc devoir implémenter une solution de QoS. La QoS est un ensemble de techniques qui consiste à mettre une priorité à du trafic et à contrôler la bande passante allouée à ce trafic. Il existe bien sûr de nombreux boitiers commerciaux qui sont capables d’assurer ces fonctionnalités mais leur prix est pour le moins prohibitif.

Le trafic que nous aurons à gérer est essentiellement du trafic web (HTTP et HTTPS). Les contraintes sur la QoS sont qu’il va être nécessaire de plafonner le débit utilisable à 10Mbit/s et d’éviter qu’un utilisateur puisse saturer toute la bande passante.

Squid semble être la solution idéale pour faire ce que nous avons à faire. Etant donné que nous allons traiter que des flux web, le proxy web semble être la meilleure solution. Pfsense est capable de faire de la QoS sur des paquets  mais les options ne sont pas aussi poussées que lors de l’utilisation d’un proxy. Avec la QoS standard, nous n’aurions pas pu garantir qu’un utilisateur ne puisse pas saturer toute la bande passante par exemple.

On va donc installer le package Squid :

pfsensepackages

Une fois le package Squid installé, nous allons pouvoir paramétrer le proxy web que nous venons d’installer. Vous devriez pouvoir y accéder dans le menu services comme illustré dans l’image suivante :

pfsenseproxy

Dans la page principale de configuration, nous allons pouvoir configurer les différentes options de notre proxy. Il est intéressant de vérifier les interfaces sur lesquelles il va répondre et le port d’écoute. Il faut ensuite définir les plages d’IP autorisées à utiliser ce proxy dans l’onglet « Access Control ». Nous allons ensuite pouvoir nous attarder sur la configuration de la QoS.

Tout d’abord, il faut se rendre dans l’onglet « Traffic Management » dans lequel nous allons pouvoir effectuer tous nos paramétrages. Nous allons pouvoir paramétrer la bande passante maximale utilisable par les utilisateurs de notre proxy en renseignant le champ « Overall Bandwidth Throttling ». Afin d’éviter qu’un utilisateur puisse consommer toute la bande passante, nous allons donc paramétrer une limitation par utilisateur. Nous allons supposer qu’il n’y a jamais plus de 3 utilisateurs qui essayent de consommer beaucoup de bande passante. Nous pouvons donc mettre 3Mbit/s. L’image suivante résume le paramétrage :

pfsensethrottling

Une fois les paramètres pris en compte, nous aurons un proxy web qui régulera et limitera la bande passante utilisé par nos utilisateurs qui passeront par ce proxy. Nous avons également la possibilité de rajouter des fonctions de filtrage web avec le plugin SquidGuard et une blacklist adaptée. Il est également possible de mettre le proxy web en mode transparent en cochant une option dans les options générales du proxy.

Fibre optique Numéricable : installation et mise en service

Fibre OptiqueJ’ai déjà parlé de la vraie fausse offre fibre optique Numéricable dans un billet précédent ainsi que de mon dilemne entre Numéricable et l’offre THD de Dartybox.

Une fois la commande effectuée, j’avais choisi un jour et un créneau horaire pour la venue du technicien. La veille de la venue du technicien, j’ai reçu un appel me demandant d’avancer le rendez-vous à 14h alors que le rendez-vous était prévu à 16h. Je refuse car je travaille la journée et que partir aussi tôt du travail n’est pas raisonnable. La personne semble insistante mais je refuse sa proposition. Le jour-même de l’installation, je reçois un autre appel mais cette fois-ci du technicien pour avancer le rendez-vous. J’ai donc du, une fois de plus, décliner la proposition alors que le technicien semblait plutôt agacé. Ce fut donc un premier contact avec Numéricable assez désagréable, vous l’aurez bien compris.

Je m’arrange pour arriver à 16h dans mon nouvel appartement pour pouvoir recevoir le technicien qui ne semble pas être présent. C’est donc au bout d’une demi heure qu’il me rappelle alors qu’il était en bas depuis 1h30. Après lui avoir dit bonjour, je me reprends une remarque comme quoi il n’avait personne entre 14h et 16h et que ca fait donc pas mal de temps qu’il attend. Deuxième contact désagréable.

La personne fait donc le tour de l’appartement pour voir comment il va pouvoir installer le cable coaxial permettant de me raccorder à l’internet. Résultat de son analyse, il faut percer trois trous à travers trois murs différents pour pouvoir me raccorder. En sachant que je suis locataire, il n’est pas souhaitable de faire des trous partout même si ce raccordement a pour objectif de rester. Après avoir refait l’analyse avec lui, nous arrivons à nous mettre d’accord sur le fait qu’il suffit d’un seul trou même si l’idée ne lui plaisait pas particulièrement.

Cette personne n’était pas équipée d’une échelle ou même d’un petit tabouret pour pouvoir percer un trou au dessus de la porte. Il a donc du monter par dessus son fourreau de cable. Le reste de l’installation s’est passé sans soucis et s’est faite proprement. Afin de vérifier que tout fonctionne correctement, le technicien m’a branché le routeur Netgear et nous avons testé la connexion au wifi.

Tout a donc fonctionné assez rapidement assez vite. Les débits sont au rendez-vous avec un débit descendant de 70 Mbit/s et un débit montant de 3 Mbit/s. C’est donc plus qu’honnête !

L’installation s’est bien passé mais c’est à ma grande surprise que Numéricable avait décidé de me facturer 50€ en plus des 40€ d’installation au titre de la mise en place du service.  Après acharnement face à la hotlineuse dont le niveau en Français laissait à désirer, j’ai réussi à me les faire enlever.

La morale de l’histoire est qu’il ne faut pas hésiter à vérifier ce que fait Numéricable sous peine d’avoir quelques petites surprises assez désagréables. L’installation est faite depuis 3 semaines et tout fonctionne à merveille. Je suis donc un abonné à la vraie fausse offre fibre optique de Numéricable plutôt content !