Hello,
Si mon réseau interne, j'avais bien spécifié : NE PAS UPLOADER avec Edonkey ou kazaa car on a un upload très limité.
J'ai un utilisateur qui upload visiblement beaucoup, saturant pas mal le réseau. ça réponse: "ben j'utilise pas edonkey mais emule".. L'innocent.
Comme j'ai pas envie de m'engueuler avec lui : je lui ai déjà dit 3 fois de couper l'upload mais j'ai encore des problèmes de réseau, j'aimerais simplement faire une règle iptable sur le serveur qui empèche l'upload avec edonkey/emule.
Une idée de comment faire ça ?
A la limite, le mieux, ce serait même de limiter la bande passante de ces logiciels. Je ne sais pas si il y'a moyen.
Ma passerelle est sous Debian.
Je pensais aussi, plutot que de surcharger le réseau interne, installer un outil p2p sur la passerelle, accessible depuis une interface web. ça permettrait aux membres de mon réseau de ne pas à avoir leur PC tout le temps allumé et à moi de pouvoir stopper le p2p quand j'ai besoin de la bande passante. Une idée sur la manière de réaliser ça ?
Si je fais ça, faut aussi couper tous les p2p internes au réseau ! :)
En fait, je ne suis pas du tout un adepte du p2p, mais le prix de la connection étant partagé entre tous les utilisateurs, je ne peux pas imposer mon point de vue.
Journal controler le p2p sur le réseau ?
1
déc.
2003
# Re: controler le p2p sur le réseau ?
Posté par rangzen (site web personnel) . Évalué à 5.
[^] # Re: controler le p2p sur le réseau ?
Posté par cumulus . Évalué à 4.
Pour ton problème, quelque chose m'échappe, si tu as une passerelle, tu as dû forwardé un port vers sa machine pour que les gens puissent se connecter chez lui pour l'upload, non ?
J'avais un peu le même problème quand j'étais en coloc, on avait dit "saturation de la bande passante la nuit" et ça se passait bien mais si y'a des boulets qui se lèvent à 15h ça fait chier tout le monde .. Alors un script dans un cron qui arrête le forward du dit port à certaines heures et voilà (faut dropper les connexions actives sur le port sinon l'effet ne sera pas immédiat).
[^] # Re: controler le p2p sur le réseau ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
J'ai simplement fait un partage de connection : http://people.via.ecp.fr/~alexis/formation-linux/firewall.html(...)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: controler le p2p sur le réseau ?
Posté par cumulus . Évalué à 1.
iptables --table nat -A PREROUTING --in-interface $EXT_INTERFACE -p tcp --dport $PORT -j DNAT --to-destination $MACHINE
$EXT_INTERFACE : interface connectée au net (ppp0 par exemple)
$PORT : le port à forwarder
$MACHINE : l'IP privée vers laquelle tu veux rediriger tes paquets
Sinon man iptables
Tu peux négocier un HIGHID contre un arrêt de la mule aux heures que tu veux :)
[^] # Re: controler le p2p sur le réseau ?
Posté par mcben . Évalué à 2.
En standard, il intègre une interface socket (type telnet), et un serveur web. Il existe également des GUI pour différents systèmes (linux et windows notamment) et dans différents langages (tcl/tk, java, gtk, etc.)
Donc tes users se connectent comme ils le veulent sur le serveur, et ensuite lancent leur téléchargement.
Je n'ai pas réellement tester la chose à fond (je voulais voir simplement ce que donnait le système client-serveur), mais ca a l'air pas mal du tout.
Le problème, si ca en est un, c'est que les utilisateurs pourront voir/gérer les téléchargements des autres.
[^] # Re: controler le p2p sur le réseau ?
Posté par rangzen (site web personnel) . Évalué à 1.
[^] # Re: controler le p2p sur le réseau ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
# Re: controler le p2p sur le réseau ?
Posté par XHTML/CSS inside (site web personnel) . Évalué à 1.
Sinon je crois qu'il est possible de limiter en upload sur le logiciel, mais c'est comme changer un pneu crevé sur une route bardée de clous, ça servira à rien (ton vilain utilisateur se fera un plaisir de réaugmenter le débit en upload dès que tu auras le dos tourné...)
++
[^] # Re: controler le p2p sur le réseau ?
Posté par kapouik . Évalué à 2.
[^] # Re: controler le p2p sur le réseau ?
Posté par cozon (site web personnel) . Évalué à 1.
S'il utilise toujours la même machine, dropper (ou encore mieux, tartiper) les connexions sortantes de son PC vers ces ports devrait pas mal le géner, même si le résultat n'est pas garanti.
Une autre astuce : J'avais trifouillé le protocole edonkey durant un temps : Il suffit de sacrifier quelques paquets importants pour que plus rien ne fonctionne. Si tu arrives à dropper un certain type de paquets (genre la connexion au serveur et la connexion au client) son emule ne devrait plus marcher du tout.
http://savannah.nongnu.org/download/mldonkey/docs/Edonkey-Overnet/e(...)
Et pour les furieux, je crois que etherreal comprend le protocole edonkey. Si ce n'est pas encore le cas, i y a un patch http://www.ethereal.com/lists/ethereal-dev/200307/msg00217.html(...)
[^] # Re: controler le p2p sur le réseau ?
Posté par Cédric Foll . Évalué à 3.
C'est en effet le cas pour le pkg debian/testing.
J'ai écrit un petit truc là dessus sur la ml snort-sigs qui permet de bloquer le traffic e-donkey en utlisant snort comme IPS (en balançant des RST lorsque l'on détecte une demande de connection e-donkey). Je le fais fonctionner sur un réseau sur un réseau de 500 postes et ça marche top.
cf http://marc.theaimsgroup.com/?l=snort-sigs&m=106563019211265&am(...)
Pour bloquer le traffic il suffit de rajouter un resp:rst_all dans les règles.
Il n'est pas possible, à ma connaissance, de faire ça au niveau iptables à moins d'utiliser des modules externes.
[^] # Re: controler le p2p sur le réseau ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
# Re: controler le p2p sur le réseau ?
Posté par kanard . Évalué à 2.
Sinon la limite de la bande passante sur le logiciel même est très facilement faisable (dans les preférences) mais il faut que ton uploadeur fou soit consentant (cela réduit proportionnellement la vitesse de download avec un ratio up/down 1/4).
Pour les clients accessibles avec interfaces web, tu peux utiliser edonkey2000 (marche en ligne de commande), avec comme interface PHPdonkey ( http://freshmeat.net/projects/phpdonkey/?topic_id=251(...) ) ou Webdonkey qui a l'air plus abouti ( http://freshmeat.net/projects/webdonkey/?topic_id=251(...) ).
[^] # Re: controler le p2p sur le réseau ?
Posté par Cédric Foll . Évalué à 1.
Par contre tous les postes dans un réseaux naté sont lowid (ils ne peuvent pas recevoir de connections depuis l'exterieur).
Mais on peut très bien faire du e-donkey en étant lowid. Le download est moins rapide mais le upload n'est pas diminué.
# Re: controler le p2p sur le réseau ?
Posté par kapouik . Évalué à 7.
iptables -A FORWARD -i $EXTIF -o $INTIF -m state \
--state ESTABLISHED,RELATED -j ACCEPT
Où EXTIF représente l'interface "externe" (celle qui accède à Internet) et INTIF l'interface "interne" (celle qui est reliée au réseau interne). Grosso modo, cette règle signifie que les connections extérieures vers l'intérieur ne sont pas autorisées mais que les données rentrantes relatives aux connections existantes de l'intérieur vers l'extérieur sont traitées convenablement. Bien évidemment, cette règle doit s'intégrer dans l'ensemble des autres règles IPTABLES de ton réseau et à elle seule ne constitue pas une solution en tant que telle !
À titre informatif, je te recommande l'excellent script rc.firewall-2.4-stronger du Linux Masquerade HOWTO qui peut te servir d'exemple : je m'en suis pas mal inspiré pour mon propre réseau et je dois dire que c'est une grande source d'information. D'ailleurs, cette règle est tiré de ce script :) Ce script permet de ne laisser passer vraiment que ce qui est nécessaire.
L'adresse du document Linux Masquerade HOWTO dans lequel tu trouveras le script rc-firewall-2.0-stronger ainsi que les informations pour accomplier ta tâche est la suivante :
-> http://www.e-infomax.com/ipmasq/howto/c-html/index.html(...)
# Re: controler le p2p sur le réseau ?
Posté par Ramso . Évalué à 5.
# Re: controler le p2p sur le réseau ?
Posté par flg . Évalué à 4.
Bien à toi.
F. Le Gall
# Re: controler le p2p sur le réseau ?
Posté par farib . Évalué à 3.
# Re: controler le p2p sur le réseau ?
Posté par sneoo . Évalué à 2.
# Re: controler le p2p sur le réseau ?
Posté par Anonyme . Évalué à 1.
Magnifique excuse !
# Re: controler le p2p sur le réseau ?
Posté par tomachaka . Évalué à 1.
Je suppose que c'est une connexion CampusNet à LLN, non ? ;-)
Une solution, quand un de tes cokotteurs "oublie" kazaa (ou autre) allumé pendant la journée, c'est d'utiliser tcpnice pour réduire la bande passante qu'il occupe.. (c'est un des outils fait par Dug Song --> dsniff)
C'est pas très beau, mais ça marche, temporairement...
Sinon, on a mldonkey sur la passerelle.
[^] # Re: controler le p2p sur le réseau ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: controler le p2p sur le réseau ?
Posté par tomachaka . Évalué à 1.
tomachaka at dlfp point org
# Re: controler le p2p sur le réseau ?
Posté par TImaniac (site web personnel) . Évalué à 1.
tu utilise eMule ? tu acceptes la philosophie du logiciel : tu télécharges, donc tu partages. Sinon tu l'utilises pas.
# Re: controler le p2p sur le réseau ?
Posté par C. OB (site web personnel) . É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 !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.