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).
Le firewall gèrent plusieurs fonctionnalités:
Cliquez ici pour toutes les infos sur le basculement entre les connections
Un service nommé reselqos permet de gérer le firewall en effectuant diverses opérations :
service reselqos start
service reselqos stop
service reselqos update
service reselqos reload
service reselqos help
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
...
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).
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
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
...
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
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)
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.
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.
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.
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
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% |
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
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 et é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.
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.
Des scripts pythons gèrent le nouveau firewall, ils sont présents dans /srv/qos/
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.
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
Last edited by amanoury, 2017-09-27 20:43:34