Hello,
Je ne sais pas si ton probleme est resolu depuis le temps, a tout hasard je te propose la solution que j'ai mise en place dans un cas similaire (Acces ADSL partage entre plusieurs etudiants dans une residence).
En fait, c'est base sur le QoS de linux, donc il faut que ca soir compile dans le noyeau ou alors que ca soit en modules.
( Les modules, ils commencent pas sch_qqchose.o )
Il te faut aussi la commande "tc" . Si tu l'a pas, faut aller te la chercher ( ou te la compiler comme moi sur ma slackware par ex.) . Le package est "iproute".
( ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz(...) ), mais il existe des rpm, des pkg, ... pour diverses distrib.
Une fois que t'a fais ca, action.
( Ah oui, $OUTDEV est a remplacer par l'interface *de sortie* des paquets, donc le modem adsl. Si t'a un modem speedtouch home comme j'avais a l'epoque ca sera ppp0. Un cable-modem ? ca sera sans doute un ethN .
Il faut bien comprendre que on ne peut controler que le traffic qui *sort*. Celui qui rentre, bah, une fois qu'il est la, le mieux est de l'acheminer vers le client... Sinon, de toute facon, 99% du temps en TCP le client va le redemander. )
En fait, sous linux, ca se passe en 3 etapes :
1/ : firewall, + redirection de ports si necessaire. Ca tu a deja je pense.
2/ : "Marquage de paquets" : Avec ca, tu va placer une marque sur chaque paquets, en fonctions de certains criteres. Dans ton cas, le critere ca sera l'adresse ip des clients.
Imaginons que tu ais sur ton reseau 3 clients, qui ont respectivement les adresses 192.168.1.1, .2, et .3 .
Tu va faire, a la suite du script de firewall :
iptables -A POSTROUTING -t mangle -o $OUTDEV -s 192.168.1.1 -j MARK --set-mark 1
iptables -A POSTROUTING -t mangle -o $OUTDEV -s 192.168.1.2 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -s 192.168.1.3 -j MARK --set-mark 3
Certains paquest doivent etre ultra-prioritaires, on va les classer a part :
# Class 1 : TCP connection control (ACK,SYN,RST,FIN) , ICMP and DNS(53 UDP)
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 53 -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --sport 53 -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p icmp -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags SYN SYN -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags RST RST -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags FIN FIN -j MARK --set-mark 5
3/ "Integration des paquets dans les files d'attentes".
En fait, la le principe est de modifier la file d'attende de depart de paquets reseau de linux, par defaut une bete fifo.
On va repartir les paquets dans les files d'attentes. ( qu'on appelle "CLASSES" )
Donc, on fait ceci : ( accroche-toi, j'explique au fur et a mesure )
# Lignes suivantes a modifier selon ton acces
MAX_UPLOAD_RATE=300kbit
CLASS1=100kbit
CLASS2=100kbit
CLASS3=100kbit
# Obligatoire : la classe racine. C'est une simple PRIO a 2 voies : Si il y a des paquets dans la premiere file (1:1) , alors on les envoie, sinon on envoie ceux de la seconde file (1:2).
tc qdisc add dev $OUTDEV root handle 1: prio bands 2 priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
# On ajoute dessous la premiere regle 2 files d'attente : l'une de type 'sfq' et l'autre de type 'htb'.
# SFQ est comme un FIFO, mais optimise : c'est a dire que si il y a plusieurs paquest dans la file d'attente, sfq va essayer de les envoyer intelligement, en fonction de criteres varies et par connections. Ca sera la file d'attente utilise pour les paquets hautements prioritaires (marques 5 ci-dessus)
# htb est la ou la majorite des paquets vont etre envoyes.
tc qdisc add dev $OUTDEV parent 1:1 handle 11: sfq perturb 10
tc qdisc add dev $OUTDEV parent 1:2 handle 12: htb
# Configuration de HTB.
# HTB (Hierarchical Token Buket) permet de balancer plusieurs files d'attentes en autorisant le partage de ressources. Donc, dans notre cas, chacun aura 1/3 de la bande passante definie dans MAX_UPLOAD_RATE.
# Ceci n'est valable *que* si tout le monde upload en meme temps ! Sinon, et c'est ca qui est chouette, un client peut utiliser la bande passante d'un autre qui ne l'utilise pas.
# Le resultat c'est que un uploader fou va pouvoir uploader comme un sale a 100% de la bande passante, mais si un autre arrive avec une simple requete HTTP, alors sa requete passera d'abord ( puisque il utilisera SON morceau de bande passante ). Si tous les 3 utilisateurs uploadent, alors chacun verra 30% de la bande passante.
tc class add dev $OUTDEV parent 12: classid 12:1 htb rate $MAX_UPLOAD_RATE ceil $MAX_UPLOAD_RATE
# All classes could take the whole bandwidth, BUT they are not equal in front of congestion
# Il est possible de regler ca plus fin, la j'ai mis de facon a ce que tout le monde soit vraiment egal.
tc class add dev $OUTDEV parent 12:1 classid 12:10 htb rate $CLASS1 burst 10k ceil $MAX_UPLOAD_RATE prio 2
tc class add dev $OUTDEV parent 12:1 classid 12:20 htb rate $CLASS2 burst 10k ceil $MAX_UPLOAD_RATE prio 2
tc class add dev $OUTDEV parent 12:1 classid 12:30 htb rate $CLASS3 burst 10k ceil $MAX_UPLOAD_RATE prio 2
echo " Adding last level disciplines"
# Finally, the connections selected by the CBQ are delivered with an SFQ discipline.
# Ca c'est important pour que en cas de congestion ( ex : un edonkey qui tourne, on puisse quand meme naviguer sur le web, sfq faisant un "entrelacement" des connections
tc qdisc add dev $OUTDEV parent 12:10 handle 121: sfq perturb 10
tc qdisc add dev $OUTDEV parent 12:20 handle 122: sfq perturb 10
tc qdisc add dev $OUTDEV parent 12:30 handle 123: sfq perturb 10
# Enfin, dans cette section on attribue chaque classe a une marque placee par iptable -t mangle.
# ( la marque est donnee par le mot-cle handle )
tc filter add dev $OUTDEV protocol ip parent 1: prio 1 handle 5 fw flowid 1:1
tc filter add dev $OUTDEV protocol ip parent 1: prio 1 handle 1 fw flowid 1:2
tc filter add dev $OUTDEV protocol ip parent 1: prio 1 handle 2 fw flowid 1:2
tc filter add dev $OUTDEV protocol ip parent 1: prio 1 handle 3 fw flowid 1:2
tc filter add dev $OUTDEV protocol ip parent 12: prio 1 handle 1 fw flowid 12:10
tc filter add dev $OUTDEV protocol ip parent 12: prio 1 handle 2 fw flowid 12:20
tc filter add dev $OUTDEV protocol ip parent 12: prio 1 handle 3 fw flowid 12:30
Bon, voila. Pas facile... Mais ca marche nickel ! j'ai pu gerer un reseau d'une bonne 30aine de personnes avec un truc comme ca ( enfin, en un peu plus complique quand meme, parceque je partagais aussi la connections avec ceux qui ne payaient pas, en garantissant a ceux qui payaient la priorite. ) , sur une simple adsl, et tout le monde pouvais surfer sans aucuns ralentissements, irc, ssh pareil, ... avec au moins 20 kaaza/morpheus/edonkey et autres winmx a l'epoque.
Faut une machine qui encaisse bien la charge par contre. Moi ca tournais sur un 486dx2/66, et des fois aux heures de pointe la charge processeurs atteignait 100%. ( Bon faut dire que cette passerelle se tapais aussi le serveur DNS, le serveur dhcp et le serveur proxy squid )
Hesite pas a me demander plus d'infos si t'a besoin.
OB
PS: dernier ptit truc : si tu as comme ca m'est arrive des gens qui "piquent" les IP des autres pendant qu'ils ne sont pas la pour avoir la connection internet alors qu'ils y ont pas droit, alors un petit truc rapide :
tu cree un fichier /etc/ethers avec les adresses MAC des clients dedans, ex:
08:00:20:00:61:CA 192.168.1.1
ensuite, tu demandes a arp de le lire :
arp -f /etc/ethers.
de cette facon, arp va forcer l'association MAC<-> IP, ( flag M ), interdisant n'importe qui d'autre d'utiliser cette IP. Le paquet sera effacer avant meme d'arriver au firewall. Ceci n'empeche pas bien sur les adresses ip qui ne sont pas dans le fichier de se connecter quelque soit leur carte.
Bien pratique ca !
Tiens, d'ailleurs est-ce que tu as des pages/documents sur ce sujet justement ? Parceque je comptais sur cygwin pour porter une library que je developpe sous windows, mais si cygwin degrade vraiment trop les performances, bah je vais revoir ma copie... :-(
Salut !
Je ne suis absolument pas d'accord avec ton second paragraphe.
Dans son cas precis, et en admettant que la machine n'offre pas d'autres services reseau que le partage de fichiers, un P90 avec 128Mo de Ram et un gros disque dur suffit amplement, si la charge n'est pas trop lourde (Ex: un service compta, une administration....).
Sous Linux, tu prend une Slackware 9 ou une debian recente, sans mode graphique (Pas plus que sous Netware d'ailleurs), ca va marcher nickel. Il y aura sans doute plus de boulot a la mise en place, mais pratiquement plus ensuite.
Avec Windows, si t'arrive a finir l'install de l'OS t'aura de la chance...(Et un gros swap). Ou alors, il faut prendre un NT, plus supporte.
D'ou le changement de machine prevu dans son budget, chose qui n'est pas forcement voulu au cas ou le materiel a des caracteristiques particulieres, comme une carte RAID SCSI, des baies extractibles a chaud....
Dans un autre domaine d'application, je me souviens avoir utilise comme routeur ADSL pour les 50 personnes du batiment (je sais c'est mal !) un 486 DX2/66, 48 Mo de Ram et 200Mo de disque, avec les dernieres version de linux (pour avoir iptables et le controle de flux), qui faisais aussi serveur DNS-cache et proxy web Squid (Et il y avais aussi Webmin pour l'administration, ainsi que SSH).
Les seuls arrets ont ete en juillet et aout.
A l'heure actuelle, les gens qui ont pris ma suite on besoin d'un P3/600 pour faire la meme chose sous Windows 2K + wingate (Ils voulaient pas garder linux), le controle de flux en moins parceque personne ne sais comment le faire.
Je pense donc que effectivement, Linux est une solution tres efficace pour recycler le vieux materiel qui marche parfaitement, meme avec des versions recentes, au prix d'une installation certainement plus delicate.
Ca n'implique pas que linux ne fonctionne pas correctement sur du materiel recent. C'est juste un petit plus qui peut etre parfois utile.
# Re: controler le p2p sur le réseau ?
Posté par C. OB (site web personnel) . En réponse au journal controler le p2p sur le réseau ?. Évalué à 1.
Je ne sais pas si ton probleme est resolu depuis le temps, a tout hasard je te propose la solution que j'ai mise en place dans un cas similaire (Acces ADSL partage entre plusieurs etudiants dans une residence).
En fait, c'est base sur le QoS de linux, donc il faut que ca soir compile dans le noyeau ou alors que ca soit en modules.
( Les modules, ils commencent pas sch_qqchose.o )
Il te faut aussi la commande "tc" . Si tu l'a pas, faut aller te la chercher ( ou te la compiler comme moi sur ma slackware par ex.) . Le package est "iproute".
( ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz(...) ), mais il existe des rpm, des pkg, ... pour diverses distrib.
Une fois que t'a fais ca, action.
( Ah oui, $OUTDEV est a remplacer par l'interface *de sortie* des paquets, donc le modem adsl. Si t'a un modem speedtouch home comme j'avais a l'epoque ca sera ppp0. Un cable-modem ? ca sera sans doute un ethN .
Il faut bien comprendre que on ne peut controler que le traffic qui *sort*. Celui qui rentre, bah, une fois qu'il est la, le mieux est de l'acheminer vers le client... Sinon, de toute facon, 99% du temps en TCP le client va le redemander. )
En fait, sous linux, ca se passe en 3 etapes :
1/ : firewall, + redirection de ports si necessaire. Ca tu a deja je pense.
2/ : "Marquage de paquets" : Avec ca, tu va placer une marque sur chaque paquets, en fonctions de certains criteres. Dans ton cas, le critere ca sera l'adresse ip des clients.
Imaginons que tu ais sur ton reseau 3 clients, qui ont respectivement les adresses 192.168.1.1, .2, et .3 .
Tu va faire, a la suite du script de firewall :
iptables -A POSTROUTING -t mangle -o $OUTDEV -s 192.168.1.1 -j MARK --set-mark 1
iptables -A POSTROUTING -t mangle -o $OUTDEV -s 192.168.1.2 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -s 192.168.1.3 -j MARK --set-mark 3
Certains paquest doivent etre ultra-prioritaires, on va les classer a part :
# Class 1 : TCP connection control (ACK,SYN,RST,FIN) , ICMP and DNS(53 UDP)
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 53 -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --sport 53 -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p icmp -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags SYN SYN -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags RST RST -j MARK --set-mark 5
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags FIN FIN -j MARK --set-mark 5
3/ "Integration des paquets dans les files d'attentes".
En fait, la le principe est de modifier la file d'attende de depart de paquets reseau de linux, par defaut une bete fifo.
On va repartir les paquets dans les files d'attentes. ( qu'on appelle "CLASSES" )
Donc, on fait ceci : ( accroche-toi, j'explique au fur et a mesure )
# Lignes suivantes a modifier selon ton acces
MAX_UPLOAD_RATE=300kbit
CLASS1=100kbit
CLASS2=100kbit
CLASS3=100kbit
# Obligatoire : la classe racine. C'est une simple PRIO a 2 voies : Si il y a des paquets dans la premiere file (1:1) , alors on les envoie, sinon on envoie ceux de la seconde file (1:2).
tc qdisc add dev $OUTDEV root handle 1: prio bands 2 priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
# On ajoute dessous la premiere regle 2 files d'attente : l'une de type 'sfq' et l'autre de type 'htb'.
# SFQ est comme un FIFO, mais optimise : c'est a dire que si il y a plusieurs paquest dans la file d'attente, sfq va essayer de les envoyer intelligement, en fonction de criteres varies et par connections. Ca sera la file d'attente utilise pour les paquets hautements prioritaires (marques 5 ci-dessus)
# htb est la ou la majorite des paquets vont etre envoyes.
tc qdisc add dev $OUTDEV parent 1:1 handle 11: sfq perturb 10
tc qdisc add dev $OUTDEV parent 1:2 handle 12: htb
# Configuration de HTB.
# HTB (Hierarchical Token Buket) permet de balancer plusieurs files d'attentes en autorisant le partage de ressources. Donc, dans notre cas, chacun aura 1/3 de la bande passante definie dans MAX_UPLOAD_RATE.
# Ceci n'est valable *que* si tout le monde upload en meme temps ! Sinon, et c'est ca qui est chouette, un client peut utiliser la bande passante d'un autre qui ne l'utilise pas.
# Le resultat c'est que un uploader fou va pouvoir uploader comme un sale a 100% de la bande passante, mais si un autre arrive avec une simple requete HTTP, alors sa requete passera d'abord ( puisque il utilisera SON morceau de bande passante ). Si tous les 3 utilisateurs uploadent, alors chacun verra 30% de la bande passante.
tc class add dev $OUTDEV parent 12: classid 12:1 htb rate $MAX_UPLOAD_RATE ceil $MAX_UPLOAD_RATE
# All classes could take the whole bandwidth, BUT they are not equal in front of congestion
# Il est possible de regler ca plus fin, la j'ai mis de facon a ce que tout le monde soit vraiment egal.
tc class add dev $OUTDEV parent 12:1 classid 12:10 htb rate $CLASS1 burst 10k ceil $MAX_UPLOAD_RATE prio 2
tc class add dev $OUTDEV parent 12:1 classid 12:20 htb rate $CLASS2 burst 10k ceil $MAX_UPLOAD_RATE prio 2
tc class add dev $OUTDEV parent 12:1 classid 12:30 htb rate $CLASS3 burst 10k ceil $MAX_UPLOAD_RATE prio 2
echo " Adding last level disciplines"
# Finally, the connections selected by the CBQ are delivered with an SFQ discipline.
# Ca c'est important pour que en cas de congestion ( ex : un edonkey qui tourne, on puisse quand meme naviguer sur le web, sfq faisant un "entrelacement" des connections
tc qdisc add dev $OUTDEV parent 12:10 handle 121: sfq perturb 10
tc qdisc add dev $OUTDEV parent 12:20 handle 122: sfq perturb 10
tc qdisc add dev $OUTDEV parent 12:30 handle 123: sfq perturb 10
# Enfin, dans cette section on attribue chaque classe a une marque placee par iptable -t mangle.
# ( la marque est donnee par le mot-cle handle )
tc filter add dev $OUTDEV protocol ip parent 1: prio 1 handle 5 fw flowid 1:1
tc filter add dev $OUTDEV protocol ip parent 1: prio 1 handle 1 fw flowid 1:2
tc filter add dev $OUTDEV protocol ip parent 1: prio 1 handle 2 fw flowid 1:2
tc filter add dev $OUTDEV protocol ip parent 1: prio 1 handle 3 fw flowid 1:2
tc filter add dev $OUTDEV protocol ip parent 12: prio 1 handle 1 fw flowid 12:10
tc filter add dev $OUTDEV protocol ip parent 12: prio 1 handle 2 fw flowid 12:20
tc filter add dev $OUTDEV protocol ip parent 12: prio 1 handle 3 fw flowid 12:30
Bon, voila. Pas facile... Mais ca marche nickel ! j'ai pu gerer un reseau d'une bonne 30aine de personnes avec un truc comme ca ( enfin, en un peu plus complique quand meme, parceque je partagais aussi la connections avec ceux qui ne payaient pas, en garantissant a ceux qui payaient la priorite. ) , sur une simple adsl, et tout le monde pouvais surfer sans aucuns ralentissements, irc, ssh pareil, ... avec au moins 20 kaaza/morpheus/edonkey et autres winmx a l'epoque.
Faut une machine qui encaisse bien la charge par contre. Moi ca tournais sur un 486dx2/66, et des fois aux heures de pointe la charge processeurs atteignait 100%. ( Bon faut dire que cette passerelle se tapais aussi le serveur DNS, le serveur dhcp et le serveur proxy squid )
Hesite pas a me demander plus d'infos si t'a besoin.
OB
PS: dernier ptit truc : si tu as comme ca m'est arrive des gens qui "piquent" les IP des autres pendant qu'ils ne sont pas la pour avoir la connection internet alors qu'ils y ont pas droit, alors un petit truc rapide :
tu cree un fichier /etc/ethers avec les adresses MAC des clients dedans, ex:
08:00:20:00:61:CA 192.168.1.1
ensuite, tu demandes a arp de le lire :
arp -f /etc/ethers.
de cette facon, arp va forcer l'association MAC<-> IP, ( flag M ), interdisant n'importe qui d'autre d'utiliser cette IP. Le paquet sera effacer avant meme d'arriver au firewall. Ceci n'empeche pas bien sur les adresses ip qui ne sont pas dans le fichier de se connecter quelque soit leur carte.
Bien pratique ca !
Voila !
[^] # Re: Les bases de données OpenSource en ébullition
Posté par C. OB (site web personnel) . En réponse à la dépêche Les bases de données OpenSource en ébullition. Évalué à 1.
[^] # Re: Un petit vent d'hiver
Posté par C. OB (site web personnel) . En réponse à la dépêche Un petit vent d'hiver. Évalué à 1.
Je ne suis absolument pas d'accord avec ton second paragraphe.
Dans son cas precis, et en admettant que la machine n'offre pas d'autres services reseau que le partage de fichiers, un P90 avec 128Mo de Ram et un gros disque dur suffit amplement, si la charge n'est pas trop lourde (Ex: un service compta, une administration....).
Sous Linux, tu prend une Slackware 9 ou une debian recente, sans mode graphique (Pas plus que sous Netware d'ailleurs), ca va marcher nickel. Il y aura sans doute plus de boulot a la mise en place, mais pratiquement plus ensuite.
Avec Windows, si t'arrive a finir l'install de l'OS t'aura de la chance...(Et un gros swap). Ou alors, il faut prendre un NT, plus supporte.
D'ou le changement de machine prevu dans son budget, chose qui n'est pas forcement voulu au cas ou le materiel a des caracteristiques particulieres, comme une carte RAID SCSI, des baies extractibles a chaud....
Dans un autre domaine d'application, je me souviens avoir utilise comme routeur ADSL pour les 50 personnes du batiment (je sais c'est mal !) un 486 DX2/66, 48 Mo de Ram et 200Mo de disque, avec les dernieres version de linux (pour avoir iptables et le controle de flux), qui faisais aussi serveur DNS-cache et proxy web Squid (Et il y avais aussi Webmin pour l'administration, ainsi que SSH).
Les seuls arrets ont ete en juillet et aout.
A l'heure actuelle, les gens qui ont pris ma suite on besoin d'un P3/600 pour faire la meme chose sous Windows 2K + wingate (Ils voulaient pas garder linux), le controle de flux en moins parceque personne ne sais comment le faire.
Je pense donc que effectivement, Linux est une solution tres efficace pour recycler le vieux materiel qui marche parfaitement, meme avec des versions recentes, au prix d'une installation certainement plus delicate.
Ca n'implique pas que linux ne fonctionne pas correctement sur du materiel recent. C'est juste un petit plus qui peut etre parfois utile.
Desole pour les accents, qwerty oblige :-(