Nouvelle classification des types de virtualisation

tech-presentation-2J’ai déjà eu l’occasion de proposer une classification des différents types de virtualisation lors d’un précédent article sur ce blog. Lors de ce précédent article, je m’étais attaché à classifier les solutions de virtualisation de systèmes d’exploitation. Je propose par le biais de cet article de re-préciser cette classification en y intégrant d’autres types de virtualisation et en reprenant en partie le précédent.

Tout d’abord, il sera essentiel de s’interroger sur ce que nous allons virtualiser car il est possible de virtualiser bon nombre de composants applicatifs. J’utiliserais le terme de composant applicatif pour désigner tout ce qui n’est pas matériel. Ce terme inclura donc les systèmes d’exploitation en globalité ou en partie aussi bien que les applications spécifiques. Ensuite, je proposerais un arbre de classification complété par rapport à la première version de cet article. Je rappellerais au passage les appellations correspondantes aux différents types de virtualisation.

Note : Cet article a été publié le 28 Octobre dans une version simplifiée sur le blog Virtualisation d’Orange Business ServiceS.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Que virtualise-t’on ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite.

Nous allons distinguer trois familles de virtualisation : réseaux, systèmes d’exploitation et processus. Ces trois types constitueront le premier étage de notre arbre de classification.

On virtualise comment ?

Nous avons donc effectué une première discrimination basée sur le composant applicatif que nous allons virtualiser afin d’établir le premier étage de notre arbre de classification. Nous allons ensuite établir le second étage de cet arbre.

Nous allons ensuite associer à chaque composant applicatif les différents types de virtualisation correspondants. En ce qui concerne les systèmes d’exploitation, nous ajouterons une distinction importante qui est la modification ou non du système d’exploitation invité. Un système d’exploitation invité est un système d’exploitation qui s’exécute par dessus une couche de virtualisation spécifique.

Voici donc l’arbre de classification que je propose :

schema_classification_small

Le premier type de virtualisation présent dans cet arbre est la virtualisation d’équipements réseaux. Il aurait été possible d’inclure la virtualisation de réseaux. Ceci a été exclu de cette classification car il ne s’agit que d’un mécanisme de commutation spécifique. Ce type de virtualisation permet de créer des environnements réseaux spécifiques et cloisonnés de bout en bout. Les solutions existantes dans ce domaine sont les produits Nexus de Cisco et le futur switch virtuel de Citrix.

Dans la catégorie des systèmes d’exploitation, nous avons choisi de distinguer les systèmes d’exploitation modifiées et non modifiées. Les modifications en question sont les modifications du noyau nécessaire à l’exécution du système d’exploitation par dessus une couche de virtualisation spécifique.

La virtualisation de système d’exploitation modifiés est la paravirtualisation. Ce terme a tendance à être utilisé de nombreuses manières différentes. La paravirtualisation est la virtualisation de systèmes d’exploitation dont le noyau a été modifié pour communiquer avec la couche de virtualisation au lieu de communiquer avec le matériel physique. Pour résumer, la système d’exploitation va avoir conscience d’être virtualisé et sera adapté à cet effet. L’ajout de simple drivers spécifique n’implique pas forcément paravirtualisation. Les solutions existantes dans ce domaine sont les produits XenServer de Citrix, xVM de Sun, XenSource voire Hyper-V de Microsoft. VMWare commence à se lancer dans cette technologie prudemment. Si vous souhaitez en savoir plus sur la paravirtualisation, je vous laisse consulter l’article sur la paravirtualisation.

En ce qui concerne les systèmes d’exploitation non-modifiés, nous distinguerons deux types de virtualisation : la virtualisation totale et la virtualisation matériel assistée. La virtualisation totale est la virtualisation « primitive » qui consiste à émuler le matériel physique ainsi que son comportement. Il s’agit de l’approche la plus couteuse mais la plus simple à mettre en oeuvre. La virtualisation matériel assisté est une extension du principe de virtualisation totale. Cette extension se matérialise par l’utilisation des extensions processeur spécifiques à la virtualisation (AMD-V et Intel-VT). Ces extensions permettent d’accélérer la virtualisation par différents mécanismes. Les solutions utilisant cette technologie sont VMWare, Virtualbox de Sun, Virtual PC de Microsoft, QEMU et bien d’autres.

Au niveau de la virtualisation de processus, nous retrouvons deux types de virtualisation : la virtualisation au niveau du système d’exploitation et la virtualisation d’application. La virtualisation au niveau du système d’exploitation consiste à faire croire à plusieurs jeux de processus qu’ils s’exécutent dans différents systèmes d’exploitation alors que ce n’est pas le cas. Les solutions utilisant cette technique sont les zones Solaris, les chroot Linux, les jails BSD, OpenVZ et bien d’autres. La virtualisation d’application consiste à livrer des applications non installées sur un poste par un serveur. Les solutions utilisant cette technique sont XenApp de Citrix ou VMWare Thinapp.

Au final, je pense que cette classification est plus complète que la précédente que j’avais eu l’occasion de présenter. Elle inclut notamment la virtualisation d’application et la virtualisation d’équipements réseaux. Cette classification reste une proposition et il est tout à fait possible de proposer une classification sous un autre angle.

Installation d’OpenSolaris 2009.06 sur Xen

solaris-logoDans un précédent billet, nous avons vu l‘installation de Xen ainsi que sa configuration réseau. Vous pouvez soit installer des domU Linux ce qui est particulièrement simple, voire magique, avec l’outil xen-tools. Mais étant donné que vous avez été convaincu par ma présentation de Solaris, vous allez vous lancer dans l’installation d’OpenSolaris sur votre plateforme de virtualisation Xen.

L’installation d’un domU OpenSolaris par dessus un dom0 OpenSolaris est particulièrement simple et je n’en parlerais pas ici. Nous allons nous intéresser à l’installation d’un domU OpenSolaris par dessus un dom0 Linux. Les raisons de ceci sont un plus grand challenge et la conservation des avantages d’un dom0 Linux. Cette installation n’est pas des plus simples et nécessite d’y passer un peu de temps. Nous supposerons que vous êtes en 64-bits car la quasi-totalité des plateformes s’exécutent aujourd’hui en 64-bits.

Préparation de l’installation

Pour pouvoir installer OpenSolaris, il va nous falloir OpenSolaris. Jusqu’ici rien de trop compliqué. Nous allons nous placer dans le répertoire /xen pour effectuer l’installation. Je vous laisse donc télécharger l’ISO d’OpenSolaris dans ce répertoire.

Nous allons avoir besoin de divers fichiers dans cet ISO, nous allons donc le monter en local.

cd /mnt && mkdir osol

mount -o loop /xen/osol-0906-x86.iso /mnt/osol

Ensuite, nous allons récupérer les fichiers dont nous allons avoir besoin. Ces fichiers sont un kernel minimaliste afin de pouvoir booter l’installation.

cp /mnt/osol/platform/i86xpv/kernel/amd64/unix /xen/

cp /mnt/osol/boot/x86.microroot /xen/

Nous devons ensuite créer le disque sur lequel le système d’exploitation va s’installer. Vous pouvez soit créer une partition LVM soit créer un image disque. Pour le LVM, je vous réfère à l’excellent tutoriel présent sur le site de Gayux. Pour créer une image disque, vous pourrez utiliser la commande dd comme suit. La commande suivante crée une image de 10Go.

dd if=/dev/zero of=/xen/disk.img bs=1024k count=1 seek=10000

Configuration du domU

Vous allez ensuite devoir paramétrer le domU. Les fichiers de configuration de domU se trouvent par défaut dans le répertoire /etc/xen. Vous pourrez y créer un fichier .cfg qui contiendra les informations suivantes. En ce qui concerne les pré-requis de l’installation, vous allez avoir besoin de 512Mo de RAM pour l’installation. Vous pourrez descendre en deçà par la suite mais l’installation nécessite autant de RAM étant donné qu’il est nécessaire d’exécuter Gnome. Vous devez donc créer le fichier de configuration suivant. J’ai choisi opensolaris.cfg.

name = « opensolaris-cest-trop-bien »
vcpus = 1
memory = 512
kernel = « /xen/unix »
ramdisk = « /xen/x86.microroot »
extra = « /platform/i86xpv/kernel/amd64/unix -B console=ttya,livemode=text »
disk = [‘file:/xen/osol-0906-x86.iso,6:cdrom,r’,’file:/xen/disk.img,0,w’]
vif = [ »]
on_shutdown = « destroy »
on_reboot = « destroy »
on_crash = « destroy »

Vous pouvez ensuite exécuter la VM que vous venez de créer avec la commande suivante :

xm create -c /etc/xen/opensolaris.cfg

Installation

Vous allez ensuite pouvoir démarrer l’installation via le mode ligne de commande jusqu’à ce que vous arriviez à un invite de commande standard. Vous allez pouvoir vous logguer via le compte jack et le mot de passe jack. Logique ? Non, je suis entièrement d’accord.

Nous allons donc ensuite devoir exécuter un serveur VNC afin de pouvoir faire l’installation en mode graphique. Je sais que ca vous chagrine de devoir faire une installation en mode graphique mais OpenSolaris ne fait pas d’installation en mode console. Ne vous inquiétez pas, vous allez pouvoir dégager Gnome dès l’installation finie. Avant de pouvoir activer VNC, il va vous falloir configurer votre interface réseau. Si vous êtes en DHCP, cela devrait fonctionner automatiquement. La procédure à suivre pour l’activation du serveur VNC est la suivante :

mkdir .vnc

cp .Xclients .vnc/xstartup

vncserver

Vous pouvez ensuite vous connecter en VNC directement à l’IP en question. Vous allez ensuite pouvoir faire l’installation via le mode graphique. Avant de redémarrer, vous allez devoir récupérer une petite info.

pfexec zdb -vvv rpool | grep bootfs

Vous allez récupérer une information du type « Bootfs = CHIFFRE« . Retenez bien ce numéro ou notez le sur un bout de papier ou tout autre surface.

Exécution

Il est temps de faire un petit résumé de ce que nous avons fait jusqu’à présent. Nous avons préparé l’installation afin de pouvoir exécuter notre installation d’OpenSolaris. Nous avons exécuter le domaine d’installation et mis en place un serveur VNC pour pouvoir y accéder en mode graphique. Dans ce mode graphique, nous avons fait les étapes d’installation. Il nous reste donc plus qu’à exécuter l’OS que nous venons d’installer. Pour se faire, nous allons devoir apporter quelques modifications à notre fichier de configuration.

name = « opensolaris-cest-trop-bien »
vcpus = 1
memory = 270
kernel = « /xen/unix »
ramdisk = « /xen/x86.microroot »

extra = ‘/platform/i86xpv/kernel/amd64/unix -B console=ttya,zfs-bootfs=rpool/CHIFFRE,bootpath= »/xpvd/xdf@0:a »‘
disk = [‘file:/xen/osol-0906-x86.iso,6:cdrom,r’,’file:/xen/disk.img,0,w’]
vif = [‘ip=xx.xx.xx.xx,mac=00:16:3E:FF:AB:AB’]
on_shutdown = « destroy »
on_reboot = « destroy »
on_crash = « destroy »

Vous allez ensuite pouvoir exécuter votre VM et profiter de votre nouvelle installation d’OpenSolaris !

Au final, cette installation est certes un peu fastidieuse mais permet tout de même d’installer OpenSolaris sur un dom0 Linux. Si vous avez des remarques par rapport à ce tutoriel, vous pouvez toujours me contacter via l’onglet prévu à cet effet. Amusez-vous bien sous Solaris !

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.

Installation de Xen sur Debian Lenny

Xen_logoJ’ai déjà eu l’occasion de parler de Xen à de multiples reprises sur ce blog. Je n’ai pas tellement eu l’occasion de proposer de tutoriels pratiques par rapport à cet outil. Je cède certes un peu à la facilité mais je pense que ce type de billet peut être utile.

Pour ce tutoriel, je vais supposer que vous avez une installation neuve de Debian Lenny. Lorsque j’ai testé ce tutoriel, j’ai effectué cette installation sur un serveur dédié OVH. Je vais également supposer que vous êtes en 64-bits. Si vous ne l’êtes pas, il va juste falloir adapter le nom des paquets à votre version. On va tout d’abord installer les paquets liés à Xen et au réseau.

apt-get install xen-hypervisor-3.2-1-amd64 xen-linux-system-2.6.26-1-xen-amd64 xen-utils-3.2-1 xenstore-utils xenwatch xen-shell xen-tools

Vous ne devriez pas avoir d’erreurs lors de l’installation de ces paquets. Si c’est le cas, je vous laisse vous documenter sur Internet afin de résoudre ces messages d’erreurs. Il y a peu de chance que l’installation fonctionne si vous avez des messages d’erreur, c’est donc le moment de les résoudre.

Nous allons ensuite augmenter le nombre de devices de « loopback ». Ces devices servent à monter les systèmes des fichier des domU (machines virtuelles). IL va donc falloir dire au module loop qu’il est nécessaire d’accepter plus de devices de « loopback ». Nous allons donc devoir rajouter la ligne suivante dans le fichier /etc/modules :

loop max_loop=64

L’installation de Xen à proprement dit est finie. Vous allez devoir vérifier que Grub est bien installé car Xen ne fonctionne pas avec LILO. OVH installe LILO par défaut, vous devez donc faire l’installation de Grub. Je vous laisse remplacer sda par votre disque dur de démarrage.

apt-get install grub

grub-install /dev/sda

update-grub

Vérifiez ensuite le contenu de /boot/grub/menu.lst afin de vous assurer que Xen est bien présent. Vous pouvez ensuite redémarrer votre machine qui devrait booter sur Xen. Si vous n’avez pas eu d’erreur jusqu’ici, tout devrait se passer correctement. Si ce n’est pas le cas, je vous invite à parcourir la mailing-liste de Xen afin de trouver la correspondance de ces erreurs. Pour vérifier que vous êtes bien sur Xen, vous pouvez exécuter uname -r qui vous donnera un noyau Xen si tout est bon.

Voici un rapide aperçu du fonctionnement de l’installation de Xen sur une Debian Lenny. J’évoquerais ultérieurement la configuration réseau et les outils de management.

Aller plus loin que Linux : Solaris

Je vais commencer une nouvelle série de billets sur un système d’exploitation alternatif à Linux. Je ne parlerais pas ici de Windows car mes compétences dans ce système d’exploitation sont fortement limités. Je vais parler de Solaris édité par Sun Microsystems. Je m’attacherais dans un premier temps à faire un tour d’horizon des éléments qui rendent intéressant ce système d’exploitation.

solaris-logo

La plupart de mon expérience en administration système s’est faite autour de la distribution Linux Debian. Debian est une distribution qui je trouve particulièrement simple à utiliser. Les développeurs de cette distribution ont pris un soin particulier de simplifier les différentes taches d’administration système. Ceci passe par une gestion claire et simplifiée des répertoires systèmes mais surtout par un gestionnaire de paquets apt-get. J’ai également eu l’occasion d’utiliser CentOS et Red Hat qui sont pratiquement identiques. L’environnement de cette distribution est également largement simplifié avec une gestion simplifiée des répertoires systèmes et divers utilitaires visant à simplifier l’administration système. Je ne pourrais pas dire que le gestionnaire de paquets inclus dans ces distributions simplifie réellement la vie car je n’ai jamais réussi à le faire marcher correctement.

Un inconvénient fréquemment évoqué par rapport à ces distributions est le fait qu’il est plus difficile de comprendre le mécanisme de fonctionnement du système d’exploitation. Ceci est lié à la simplification des taches d’administration et n’est pas forcément un inconvénient a priori. Cette simplification devient problématique lorsqu’il s’agit de faire du débuggage dans un système de production qui présente un comportement bizarre. Les messages d’erreurs standards sont relativement faciles à diagnostiquer mais lorsque le problème est moins « franc », les choses se corsent. J’adhére partiellement à cet inconvénient. Je souhaitais surtout obtenir une connaissance plus approfondie d’un système d’exploitation. Je me suis donc penché sur Sun Solaris.

Lorsque l’on commence à s’intéresser à Solaris, les choses sont relativement claires dès le début, on va avoir à faire à un Unix dit « traditionnel ». Ceci signifie que les repères acquis sous Linux vont disparaitre totalement et que les outils de simplification seront soit incomplets soit inexistants. D’un autre coté, Solaris est un système d’exploitation qui a de nombreux arguments en sa faveur. Vous avez surement entendu parler de ZFS, le système de fichier révolutionnaire. Vous avez peut être entendu parler de DTrace qui vous donne une vision approfondie du fonctionnement de votre système d’exploitation. Vous avez peut être entendu parler des zones Solaris et de l’intégration native de Xen sous le nom xVM. Et encore, nous n’avons parler de SMF. Bref, autant dire que les arguments sont bien présents.

Solaris permet de s’affranchir des outils et couches de simplification d’un système d’exploitation Linux et de se plonger réellement dans la compréhension du fonctionnement d’un système d’exploitation Unix. Afin de réussir à l’utiliser correctement, il va être nécessaire de comprendre les mécanismes internes. Ceci est un chantier tout à fait passionnant que je vous encourage à entreprendre. Vous ne serez pas seul dans cette entreprise, Sun a prévu pour vous des documentations particulièrement claire et explicite que vous trouverez sur leur site. Sun a également prévu un cursus de certification accessible gratuitement sur leur site. Le passage de l’examen est payant par contre pour la modique somme de 40€.

Mais, pourquoi pas Gentoo ou BSD ? Ces distributions permettent certes de comprendre plus en profondeur le fonctionnement d’un système d’exploitation mais n’ont pas les arguments qu’a Solaris ni la documentation ni le parcours de certification. Je ne dis pas que s’intéresser à Gentoo ou BSD n’aurait eu aucun intérêt, loin de là. J’ai juste préféré changer d’orientation vers une distribution, certes un peu moins libre, radicalement différente.

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.