Le Firewall Dynamique et de QoS du ResEl

Auteur : Alexandre "Pika" Manoury pika@resel.fr

Date : 28 Février 2013

Le but du nouveau script pour le Firewall / Shapping est de fournir un firewall dynamique (prise en compte automatique des inscriptions, bans, ...) et de QoS (répartition équitable de la bande passante entre les utilisateurs).

Les fonctionnalités

Le firewall gèrent plusieurs fonctionnalités:

  • Création des règles iptables (NAT, PAT, ...)
  • Gestion des règles tc (traffic control) pour gérer les débits et la qos
  • Mise à jour en fonction de l'inscription / suppression / paiement
  • Mise à jour du champ lastDate d'un userResel (nécessite un accès en ECRITURE au Ldap principal)

Paramètres du service

Un service nommé reselqos permet de gérer le firewall en effectuant diverses opérations :

  • Efface toutes les règles/chaînes, vide les files, vide les sets, puis relance le firewall dynamique :
service reselqos start
  • Arrête le script de firewall, sans supprimer les chaines (actuellement pour éviter de couper la passerelle par erreur pendant la phase de test) :
service reselqos stop
  • Mettre à jour le firewall; cette mise à jour s'effectue également toute seule à intervalle régulier (environ toutes les 10 secondes - paramétrable) :
service reselqos update
  • Recharger la configuration du firewall; cela permet de changer le débit ou certains paramètres sans avoir à relancer le firewall (attention, tous les paramètres ne peuvent pas être ainsi modifiés à chaud cf ...) :
service reselqos reload
  • Affiche l'aide :
service reselqos help

Fichier de configuration

Le fichier de configuration est /srv/qos/qos.conf et regroupe l'ensemble des paramètres du firewall, de la qos, de l'ipv6,...
La modification de ce fichier permet de configurer distinctement loli et peach, il n'y a pas besoin de modifier les scripts pour les différents routeurs.

Le fichier se présente sous la forme :

[section1]
key1 = value1
key2 = value2
...

Connexions requises

LDAP

Le script requière une connexion au LDAP (anonyme) pour récupérer la liste des utilisateurs et des machines.
Si cette connexion est perdue après le démarrage les utilisateurs ne seront pas mis à jour mais les règles resteront les mêmes : une personne déjà chargée pourra continuer à accéder à internet.
Le script tentera de se connecter au serveur régulièrement, si le serveur à changer il suffit de modifier le fichier de configuration et de faire un service reselqos reload pour se connecter au nouveau serveur sans redémarrer le serveur.

Les données relative au LDAP sont dans la section :

[ldap]
host = beaune.adm.maisel.enst-bretagne.fr
user =
password =
baseorga = ou=organisations,dc=maisel,dc=enst-bretagne,dc=fr
basepeople = ou=people,dc=maisel,dc=enst-bretagne,dc=fr
basehosts = ou=machines,dc=resel,dc=enst-bretagne,dc=fr

Pour la mise à jour du champ lastDate il y a besoin d'une connexion avec un compte ayant des droits d'écriture sur ce champ. Pensez à vérifier que le serveur ldap remonte l'information sur le ldap principal (dans le cas de Rennes par exemple).

MySQL

Le script requière une connexion à un BDD MySQL afin de stocker la quantité de données téléchargées par utilisateur ainsi que pour le partage de bande passante entre les firewall.
Si cette connexion est perdue après le démarrage les règles resteront inchangées et la mise à jour dynamique continuera si le LDAP est toujours accessible. Néanmoins si le firewall est redémarrer avant de retrouver la connexion, les quota pour la QoS ne seront pas corrects.
Le script tentera de se connecter au serveur régulièrement, si le serveur à changer il suffit de modifier le fichier de configuration et de faire un service reselqos reload pour se connecter au nouveau serveur sans redémarrer le serveur.

Les données relative à MySQL sont dans la section :

[database]
host = maia.adm.maisel.enst-bretagne.fr
user = qos
password = ***
db = qos

Options

Firewall

Toutes les données pour configurer le firewall sont dans la section du même nom dans le fichier de configuration :

[firewall]
enabled = 1
areaPrefix = 172.22.
areaOtherPrefix = 172.23.
eth_ext = eth0.990
... (autres interfaces)
tunnel_name = to_rennes
ip_int = 172.22.199.30
... (autres IP)
net6 = 2001:0660:7302:D000::/52
... (autres network)
area6Prefix = 2001:0660:7302:d
...

IPv6

Le firewall gère actuellement en partie l'IPv6 : les IP des utilisateurs sont filtrées mais la plupart des autres IP (machines, blacklist) ne le sont pas. La gestion de la QoS et les quotas sont néanmoins en place en IPv6. Pour activer ou non l'IPv6 (en cas de désactivation, la politique est de tout accepter) :

[firewall]
v6Enabled = 1

Débit

La section rates du fichier de configuration permet de gérer tous les débits (en upload et en download) pour le débit total, le débit du tunnel, le débit shapé, ...
Le débit dit "Global" correspond au débit alloués à l'ensemble Brest + Rennes, il sert au partage dynamique de débit entre les deux campus si un campus sature et que l'autre a de la marge. (Cette fonctionnalité n'est pas encore activée)

Règle de débit

Si des changement de débit doivent avoir lieu sur des tranches horaires spécifiques il suffit de les renseigner dans la section ratesrules :
Exemple : pour passer à 160 Mbps entre 20h et 4h du matin en upload et en download :

[ratesrules]
rule1From = 20:00
rule1To = 4:00
rule1GlobalUp = 200Mbps
rule1GlobalDown = 200Mbps
rule1Up = 160Mbps
rule1Down = 160Mbps

Les autres débits seront adaptés de manière proportionnelle.
Pour qu'un débit ne soit pas modifié, il suffit de mettre sa valeur à 0 (attention, le champ doit quand même être présent !)

Pour ajouter d'autres règles il suffit de rajouter les 6 mêmes champ en remplaçant le début par rule2, rule3 et ainsi de suite.

Qos

Principe

Le principe utilisé ici est le suivant : On possède M groupes de QoS, au début de la journée (vers 5h) tous les utilisateurs sont dans le groupe 0. En fonction de la quantité de données téléchargées, les utilisateurs vont franchir des limites et tomber dans le groupe n+1.

Il existe une distinction entre l'upload et le download. Ainsi un utilisateur peut se trouver dans le groupe 2 en download et dans le groupe 0 en upload.

Limites

La limite de chaque groupe dépend de deux paramètres classSeperationBase et classSeperationParameter : la limite du groupe n vaut :

(la limite du groupe n-1) * classSeperationParameter + classSeperationBase

La limite du ''groupe 0'' vaut classSeperationBase.

Débit par utilisateur

A chaque groupe un débit par utilisateur cible est précisé, les règles TC sont donc mises à jour à chaque fois que des utilisateurs change de groupe afin de conserver le bon débit par utilisateur pour chaque groupe.
Le débit par utilisateur dépend d'un facteur classRateFactor < 1, du débit total, et de la répartition des utilisateurs dans chaque classe.
La répartition est faite de telle manière à répartir l'ensemble du débit disponible entre les utilisateurs tel que un utilisateur du groupe n+1 aura classRateFactor le débit d'un utilisateur du groupe n

Valeurs par défauts

Groupe Limits Rate factor
0 1250 Mo 100%
1 3250 Mo 80%
2 6450 Mo 64%
3 11570 Mo 51%
4 19762 Mo 41%
5 - 33%

Désactivation

La QoS peut être désactiver : dans ce cas tous les utilisateurs sont dans le même groupe et la quantité de données téléchargées n'entrent pas en jeu.

[qos]
enabled = 1

Logs

Un fichier de log est présent : /var/log/reselqos/reselqos.log (par défaut), pour le modifier :

[path]
log = /var/log/reselqos

Si des erreurs du type "xxx has juste arrived on the campus" sont multiples, pensez à vérifier que le script peut bien se co au LDAP est écrire dessus.

Si des erreurs du type "cannot add, the ip is already present in the set", il s'agit de doublons ldap, sans incidence sur le fonctionnement du fw.

Test de la config

Pour lancer un test de la config

[firewall]
test = 1

Et lancer ./qospam.py afin d'avoir accès aux logs et au message d'erreur en direct.

Cette option fait qu'aucune règle du fw ne sera inscrite dans iptables ou dans tc. A tester avant de relancer le service après une modif importante. Cela ne permet pas de tester les règles fw mais permet de vérifier que le script tourne sans erreur.

Partie technique

Scripts

Des scripts pythons gèrent le nouveau firewall, ils sont présents dans /srv/qos/

  • Le fichier qosrunner.py constitue un programme avec une boucle d'actualisation.
  • Le fichier qospam.py sert à lancer ce programme.
  • Le fichier qosfirewall.py gère les règles IPTABLES, IPSET et TC.

  • Le fichier qosparser.py se gère de la lecture du fichier netacct pour recueillir les logs.

  • Le fichier objects.py contient les classes User et Host.

  • Le fichier utils.py contient des fonctions utilitaires.

Gestions des groupes de QoS

  1. Ipset :
  2. Toutes les IP des machines d'un utilisateur du ''groupe 3'' en upload seront mises dans l'Ipset ''qos_u3''
  3. Si l'utilisateur passe dans le ''groupe 4'' en upload, ses IP seront supprimées de l'Ipset ''qos_u3'' et rajoutées dans l'Ipset ''qos_u4'
  4. De même pour les groupes en download ''qos_d'''X''' ''

  5. Dans le cas de l'IPv6, les Ipset se nomment ''v6qos_d'''X''' '' et ''v6qos_u'''X''' ''

  • L'accès à internet est permis à toutes les ips contenues dans ''webaccess'' et ''extrawebaccess'', pensez à vérifier dans ces sets ipset -L webaccess si l'ip est présente en cas de problème

  1. Iptables :
  2. Tous les paquets correspondant aux IP d'un Ipset ''qos_d'''X''' '' seront marqués avec le numéro 1000 + X (ou 2000 + X dans le cas d'un groupe d'upload)
  3. TC :
  4. Un '''groupe de QoS''' correspond à une '''class TC''' avec une ''' qdisc SFQ''' et associée à un '''filter TC'''
  5. Le '''filter TC''' pour le ''groupe n'' récupère tous les paquets marqués avec le numéro 1000 + n (ou 2000 + n selon le cas)
  6. Le débit d'un '''groupe de QoS''' correspond au débit de sa classe TC, chaque groupe peut emprunter du débit autres groupes (jusqu'à une certaine limite) s'ils n'utilisent pas leur bande passante allouée.