[Lundi] Table 5 : Load Balancing & Netfilter avancé

Load Balancing en quelques mots :

En français : répartition de charge. Consiste à distribuer une tâche à un pool de machines ou de périphériques afin de :

• lisser le trafic réseau, c'est-à-dire de répartir la charge globale vers différents équipements ;
  

• s'assurer de la disponibilité des équipements, en n'envoyant des données qu'aux équipements en mesure de répondre, voire à ceux offrant le meilleur temps de réponse.
  

La gestion des files d’attente

Principe :
Le principe général est le suivant :
• Sélectionner le type de paquet à traiter dans la couche netfilter, par exemple, les paquets « interactifs » d’une session ssh (port 22), les paquets correspondant à la réception du mail (port 25), etc.
• Marquer ces paquets avec la directive --set-mark de netfilter
• Modifier et hiérarchiser la file d’attente des paquets concernés à l’aide d’un gestionnaire ad hoc (le meilleur gestionnaire sous Linux est htb, Hierarchical Token Bucket).

CBQ

Notre gestion de la bande passante se fera via des files d'attente basées sur du Class Based Queueing (CBQ) sur notre GW.
Nous ferons usage d'iptables pour sélectionner et marquer les paquets et donc leur attribuer une classe.

Définition : CBQ est une file d'attente permettant de stocker d'autres files en fonction des classes pré-déterminées.

Dans un premier temps, nous devons définir une file d'attente racine pour le périphérique eth1 dans notre cas.

Code:

tc qdisc add dev eth1 vénérable grand maitre handle 100: cbq bandwidth 100Mbit avpkt 1000 mpu 64

L'utilitaire tc (Traffic Control) est utilisé ici pour créer (add) une queuing discipline (qdisc) pour eth1, le nom est 100:, la bande passante de l'interface 100Mbit, une taille moyenne de paquets fixée à 1000 octets et une taille minimum fixée à 64 octets.

Nous définissons ensuite deux classes (branches), une par type de connexion :

Code:

# tc class add dev eth1 parent 100:0 classid 100:1 cbq bandwidth 10Mbit rate 40Kbit allot 1514 prio 1 maxburst 10 avpkt 100 isolated

Cette première classe nommée 100:1 possède le moins de bande passante (rate 40Kbit), mais une priorité supérieure (prio 1). En effet, une connexion intéractive n'a, habituellement, pas besoin d'une bande passante très grande, mais pour éviter le lag, ce type de connexion doit avoir priorité sur toutes les autres. Le paramètre isolated indique que la bande passante de 40Kbit ne doit pas être empruntée par les autres classes. Nous nous assurons un débit minimum. En revanche, cette classe possède la faculté de prendre de la bande passante aux autres dans la mesure du possible.

Voici la définition pour la seconde classe :

Code:

# tc class add dev eth10 parent 100:0 classid 100:2 cbq bandwidth 10Mbit rate 450Kbit allot 1514 prio 8 maxburst 2 avpkt 1500 bounded

Cette classe limite sa bande passante à 450Kbit et ne doit jamais dépasser cette limite (bounded). Elle possède également une priorité bien inférieure à la précédente.

Nous utilisons ensuite iptables pour marquer les paquets. Nous distinguons deux types de connexion ici :
• les paquets d'une taille inférieure à 500 sont considérés comme étant des connexions intéractives (ssh, telnet, http, etc.)
• les paquets d'une taille > 500 font partis des autres connexions
Nous utilisons donc la table mangle pour marquer les paquets des sessions intéractives avec une valeur 3 et les autres avec une valeur 4 :

Code:

# iptables -t mangle -A OUTPUT -m length --length 0:500 -j MARK --set-mark 3

Code:

#iptables -t mangle -A OUTPUT -m length --length 500:0xffff-j MARK --set-mark 4

Nos classes sont maintenant définies, il ne nous reste plus qu'à indiquer quelle classe utiliser pour chaque type de connexion. Cette fois, ce sera le paramètre filter de tc qui sera utilisé :

Code:

# tc filter add dev eth1 parent 100:0 protocol ip handle 3 fw flowid 100:1

Code:

# tc filter add dev eth1 parent 100:0 protocol ip handle 4 fw flowid 100:2

On retrouve notre marque (handle 3 et handle 4), le CBQ parent (100:0) et respectivement les classes à utiliser pour chaque type de connexion (flowid 100:1 et flowid 100:2).

La gestion des files d'attente

Autre Manip


Nous avons mis en place 3 files d’attente configurées selon les modalités suivantes :

• Une file de discipline SFQ avec un trafic limité à 2mb/s et un trafic normal à 2mb/s
• Une file de discipline SFQ avec un trafic limité à 40 mb/s et un trafic normal à 40 mb/s
• L’ensemble de ces files sont limitées à 60 mb/s au total, toutes files confondues. La discipline de cette file de sortie est HTB.
  

Par conséquent, le trafic sortant de la machine sera limité à 60 mb/s au total, et le traitement par files d’attentes séparées permettra de répartir le trafic selon son importance.

Afin de vérifier le fonctionnement de ces séries de files d’attente, et la façon dont les paquets sont priorisés en cas d’engorgement, il faut créer un script de configuration automatique pour configurer iptables et tc.

Le script de mise en œuvre automatique
Le script que nous avons rédigé pour mettre en œuvre place nos files d’attente est le suivant :

#!/bin/sh
./no_firewall

## j’effacer l’ancienne config si elle existe
##=============================

tc qdisc del dev eth1 vénérable grand maitre 2>/dev/null


##je crée ma file d'attente principale
##========================

tc qdisc add dev eth1 vénérable grand maitre handle 100: htb


##j'utilise Iptables pour marquer les paquets selon mes choix
##===========================================

iptables -t mangle -A OUTPUT -o eth1 -j MARK --set-mark 5
iptables -t mangle -A INPUT -i eth1 -j MARK --set-mark 5
iptables -t mangle -A FORWARD -j MARK --set-mark 5

##Je définie deux classes, une par type de connexion ;
##====================================

tc class add dev eth1 parent 100: classid 100:1 htb rate 60000Kbit
tc class add dev eth1 parent 100:1 classid 100:10 htb rate 2000Kbit ceil
20000Kbit
tc class add dev eth1 parent 100:1 classid 100:20 htb rate 40000Kbit
ceil 40000Kbit

#Création des files
##============

tc qdisc add dev eth1 parent 100:10 handle 54: sfq
tc qdisc add dev eth1 parent 100:20 handle 60: sfq

##filtrage suivant les marques des paquets
##Avec ces commandes on affecte les paquets marqués aux files d'attentes correspondantes, et bien sùr ils seront gérés suivant les paramètres de flux définis.
##========================================================

tc filter add dev eth1 protocol ip handle 5 fw flowid 100:10

Le script No_Firewall :

#!/bin/sh
iptables -F
iptables -F -t nat
iptables -F -t mangle
echo 1> /proc/sys/net/ipv4/ip_forward

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Après divers tests tout semble marcher nikel (utilisation d'iptraf par exemple)

Schéma de notre architecture pour bientôt !

Configuration du Bridge

Nous avons ajouté une troisième carte à notre Bridge. Nous verrons plu tard l'utilité .

Désactiver toutes les interfaces du pont :

Code:

ifconfig eth0 down
ifconfig eth1 down
ifconfig lo down

Le pont n'a pas besoin d'adresse IP pour fonctionner. Il faut enlever toutes les adresses IP et faire passer les interfaces en mode promisc . Le mode promisc permet aux interfaces d'écouter tout le réseau et donc transférer les trames :

Code:

#ifconfig eth0 0.0.0.0 promisc
# ifconfig eth1 0.0.0.0 promisc
# ifconfig eth2 0.0.0.0 promisc

Enfin, nous passons à la création du pont en lui donnant un nom qui pour nous sera « bridge» :

Code:

# brctl addbr bridge

Il nous faudra également configurer les interfaces en les associant à notre pont « bridge » :

Code:

# brctl addif bridge eth0
# brctl addif bridge eth1
# brctl addif bridge eth2

Maintenant, il faut réactiver toutes les interfaces sans oublier le pont que nous venons de créer :

Code:

# ifconfig eth0 up
# ifconfig eth1 up
# ifconfig eth2 up
# ifconfig lo up
# ifconfig bridge up

Nous avons regroupé cette configuration dans un script :

Code:

# !/bin/bash
ifconfig eth0 0.0.0.0 promisc up
ifconfig eth1 0.0.0.0 promisc up
ifconfig eth2 0.0.0.0 promisc up
ifconfig lo up
ifconfig bridge up

brctl addbr bridge
brctl addif bridge eth0
brctl addif bridge eth1
brctl addif bridge eth2
brctl show

La manipulation s'effectue sur notre pont qui relie notre passerelle « GW » à l'interface eth0 et le Hub à l'interface eth1 & eth2. Nous avonc utilisé un Hub HP à 8 ports
Tous les détails sont repris sur le schéma ci-dessous :



Pour vérifier si notre pont est totalement transparent, il nous suffit de faire un traceroute et le résultat démontrera que le pont n’est pas présent .
La commande ifconfig, nous permet de voir que notre bridge a correctement été créé et qu’aucune interface ne posséde une adresse ip.

//Règles
Nous allons utiliser « ebtables » pour définir des politiques par défaut. Nous allons tout bloquer et ajouter au fur et à mesure les règles acceptées :

script defaultPolitique

Code:

# !/bin/bash
# ebtables -F
# ebtables -t nat  F
 
# ebtables -P INPUT DROP
# ebtables -P OUTPUT DROP
# ebtables -P FORWARD ACCEPT


Nous allons utiliser « iptables » pour accepter certaines règles

script bridgePolitique

Code:

# !/bin/bash
./defaultPolitique
# On accepte e trafic http
Iptables –A FORWARD -p tcp –dport 80 –j ACCEPT
Iptables –A FORWARD -p udp –dport 80 –j ACCEPT

#On accepte le DNS
Iptables –A FORWARD -p tcp –dport 53 –j ACCEPT
Iptables –A FORWARD -p udp –dport 53 –j ACCEPT

#On accepte les retours si la connexion a déjà été établie
Iptables –A FORWARD –m state –state ESTABLISHED, RELATED –j ACCEPT

#On accepte le ssh
Iptables –A FORWARD –p tcp –dport 22 –j ACCEPT
Iptables –A FORWARD –p udp –dport 22 –j ACCEPT

#On accepte le ICMP
Iptables –A FORWARD –p icmp –j ACCEPT

#Mettre les logs iptables dans un fichier var/log/syslog
Iptables –I FORWARD –j LOG

Nous allons ajouter des règles de marquage de paquets afin que chaque paquet entrant dans le bridge soit marqué. Ils seront marqués en fonction de leur adresse IP source.
Donc tous nos paquets venant de l'adresse 172.16.0.205 (GW) seront marqués par « 1 » et tous les paquets venant de 172.16.0.4 (hub connecté au répétiteur qui est lui-même connecté à deux interface du bridge) seront marqués par « 2 » et « 3 »

script loadBalancing

Code:

#effacer tous les qdisc existants
tc qdisc del dev eth0 vénérable grand maitre 2>/dev/null
tc qdisc del dev eth1 vénérable grand maitre 2>/dev/null
tc qdisc del dev bridge0 vénérable grand maitre 2>/dev/null

ebtables -t filter -A FORWARD -p IPv4 --ip-dst 172.16.0.205 -i eth0 -j mark --set-mark 1 --mark-target ACCEPT
 ebtables -t filter -A FORWARD -p IPv4 --ip-dst 172.16.0.4 -i eth1 -j mark --set-mark 2 --mark-target ACCEPT
ebtables -t filter -A FORWARD -p IPv4 --ip-dst 172.16.0.4 -i eth2 -j mark --set-mark 3 --mark-target ACCEPT

… suite à venir