[RESOLU] Contrôle de débit et QoS, avec (neuf)box

[bzhgegefr]

Bonjour,

Je préviens tout de suite que j'essaye de mettre en place un truc modérément tordu mais je coince dessus depuis un bon moment.

J'ai quelques connaissances en réseau / linux, sans être expert.

J'explique : j'ai un réseau domestique "classique" : une box en 192.168.1.1, et quelques PC en DHCP. En bonus j'ai aussi un petit serveur debian (NAS, DLNA, NG ...) lui aussi en dhcp.

Cependant il commence a y avoir beaucoup d'utilisateurs sur la box, et je voudrais pouvoir un peu contrôler le débit de la famille (sans installer un limiteur sur chaque PC) pour pouvoir jouer lorsque la soeur regarde une video "streaming" (télécharge a fond et lit en même temps).

--------- Essais avec m0n0wall en VM sur le serveur linux -------------

NB : le debian est un atom 1.5ghz monocoeur (hyperthreading) avec 2 go de RAM. L'OS est installé sur un clé USB 8go pas extra. Il n'y a pas d'extensions VT (il me semble).

Fonctionnellement concluant avec virtualbox, mais problème de perfs, le processus VBoxHeadless prend environ 50a 100% (sur 200%) du CPU total en continu... Les services de l'hôte s'en prennent un coup, mon samba passe de 70mo/s a 30mo/s... pas acceptable, et je n'ai pas réussis a résoudre.

Coincé avec VMWare player car pas d'environnement graphique ...

Pas essayé avec VMWare server (ça me semble trop encore plus lourd coté perfs ...)

--------- Essais avec debian pur -------------

Donc je me suis dit : pourquoi ne pas mettre les PC dans un réseau en 192.168.3.X (le.2 est pour le hotspot, autant pas toucher), garder la box en 192.168.1.1, et a mon serveur debian une patte dans chaque réseau (eth0 = 192.168.1.254 et eth0:0 = 192.168.3.254), le configurer en routeur, et utiliser l'utilitaire "tc" pour contrôler le traffic en fonction des IP par exemple. J'ai pas mal joué avec

Après pas mal d'essais, j'ai "presque" un truc OK. Mon principal soucis est que ma box debian a une seule carte réseau: la box debian renvoie des ICMP redirect pour dire a mon PC du .3 qu'il peut joindre en "direct" sa cible, et donc qu'il n'est pas nécessaire de passer par lui.

Il a raison, mais ça ne m'arrange pas dans le cas présent.

Il y a des flags pour désactiver ces messages ICMP, mais ils n'ont pas d'effet. J'ai ajouté une rêgle iptables afin de "dropper" tous les paquets ICMP redirect dans la chaine OUTPUT de la box debian et il a arrêté de les émettre.

Cette fois tout le traffic venant de mon 192.168.3.X, a destination de 192.168.1.X passe systematiquement par la box debian (logiquement je dois pouvoir le contrôler, même si j'ai pas essayé). Les résolutions DNS fonctionnent bien aussi: logique, c'est du traffic a destination de ma box, et ça ça marche, tout comme l'interface web.

En revanche, dès que le traffic est a destination d'une IP internet, sur le chemin de l'émission ça se passe bien (192.168.3.X => debian => 192.168.1.1, en revanche je n'ai rien sur le chemin du retour,on dirait que ma (neuf)box n'arrive pas a renvoyer le traffic (apres le nat) vers la passerelle.

Bref, si quelqu'un a eut le courage de lire, comprendre ... et a déjà été confronté a ce problème, je suis preneur de conseils ! S'il existe d'autres solutions / façons de faire auxquelles je n'ai pas pensé, ça m'intéresse aussi.

J'imagine que la solution la plus efficace serait l'ajout d'une deuxième carte réseau dans le PC... Vu que ça marche avec deux interfaces virtuels dans m0n0wall , ça devrait le faire avec deux vraie cartes... Ou alors résoudre ce soucis de performances avec la virtualisation.

Il y a peut être aussi la solution de "bridger" la box sur le debian ? ...

Bref, peut être ne suis-je pas le seul dans ce cas ? ... j'espère

[Cyduck]

Bonjour,

As tu essayer d'indiquer à la neufbox la route retour pour atteindre 192.168.3.x ?

Destination : 192.168.3.0 ; Subnet mask : 255.255.255.0 ; Gateway : 192.168.1.254

[bzhgegefr]

Bonjour !

Oui je l'ai fait, c'est d'ailleurs nécessaire pour que la neufbox puisse répondre aux pings, requêtes DNS, HTTP (elle est renseignée comme serveur DNS dans mes PC du 192.168.3.X).

Ce qui me turlupine, c'est que lorsque les paquets ne sont pas destinés a la box elle même, mais a une IP internet (la box va donc faire du nattage), là ça ne revient pas ... (même en capturant a coup de tcpdump) :(

C'est d'autant plus bizarre que ça fonctionne bien avec m0n0wall (VM avec deux interfaces virtuels, lorsque j'utilise en routeur (je n'utilise pas les fonctions de NAT de m0n0wall)). Donc ça doit probablement venir de la configuration de la box debian...

J'ai aussi essayé avec un bridge et des interface tun/tap afin d'avoir quelque chose de plus proche de deux 'vraies' interfaces distinctes (deux adresses MAC différentes) plutôt qu'une simple IP virtuelle eth0:0 (même MAC pour les deux IP), mais là je ne maitrise pas vraiment ... J'arrive a faire fonctionner tant que le tap0 est dans le même subnet que le br0 (aucun intéret pour moi), en revanche, dès que je met le tap0 dans un subnet différent, tap0 est injoignable :'(

[Cyduck]

Arrives tu à pinguer l'interface Wan (ton ip publique) de ta neuf box à partir de la debian ? et plus loin?

Après ça...je pense que je vais être trop limite sur le sujet

[bzhgegefr]

Je n'ai pas essayé l'interface WAN de la box. Mais plus loin, je n'y arrive pas. ça c'est sûr

Pour le moment, j'ai installé un XFCE et VMWare Player pour m0n0wall. C'est pas parfait, mais c'est moins pire que VirtualBox en matière de performances.

J'imagine que le mieux est d'avoir deux interfaces réseaux !

Je vais continuer a chercher et tester, je trouve bizarre que ce ne soit pas faisable :) Connaitrais tu un peu les bridge et tap/tun sous linux ? Ca me semble être le meilleur moyen de faire des interfaces virtuels les plus complets, mais je ne comprends pas pourquoi mon tap0 doit avoir une IP dans le même sous réseau que br0 ... Il me semblait que ces interfaces étaient au niveau ethernet, et non pas IP...

[bzhgegefr]

Alors, j'ai réussis a obtenir le résultat que je voulais, a peu de choses près.

Pour la mémoire, voici ce que j'ai fait

Les points clé :

- deux sous-réseaux (192.168.1.X "libre" et 192.168.3.X "bridé") et je route entre les deux

- utiliser iptables pour BLOQUER les icmp redirect

- utiliser iptables pour faire du NAT (la box est contente ainsi)

- utiliser iptables pour "tagger" les paquets a "shaper" (upload vers internet, download depuis internet)

- utiliser tc pour limiter les paquets taggués, avec un débit dépendant du tag ci dessus

- désactiver le serveur DHCP de la box

- le serveur dhcp udhcp pour donner des ip avec les bons parametres dans le 192.168.3.X

- pour ne pas être bridé, configurer une ip fixe en 192.168.1.X

Ma débian (il s'agit de br0 au lieu de eth0 car j'ai un serveur openvpn, mais ca devrait être pareil avec eth0 a la place) :

/etc/network/interfaces (config réseau)auto br0iface br0 inet static       address 192.168.1.254       network 192.168.1.0       netmask 255.255.255.0       gateway 192.168.1.1       nameservers 192.168.1.1       bridge-ports eth0       post-up /etc/openvpn/scripts/ovup && /etc/init.d/openvpn start       pre-down /etc/init.d/openvpn stop       post-down /etc/openvpn/scripts/ovdownauto br0:0iface br0:0 inet static       address 192.168.3.254       network 192.168.3.0       netmask 255.255.255.0

Activer le routage :

/etc/sysctl.confnet.ipv4.ip_forward=1

Ensuite j'ai fait un petit script a mettre au démarrage auto pour toutes les histoires de tc / iptables

/etc/init.d/shaper#! /bin/sh# /etc/init.d/shaper#IF=br0# iptables       # flush everything       iptables -F       iptables -t nat -F       iptables -t mangle -F       # install NAT for any non local packet       iptables -A POSTROUTING -t nat ! -d 192.168.0.0/16 -j MASQUERADE       # never send ICMP redirect (problem with because only one IF)       iptables -A OUTPUT --proto icmp --icmp-type redirect -j DROP       # mark paquets to shape (1: upload)       iptables -A PREROUTING -t mangle ! -d 192.168.0.0/16 -j MARK --set-mark 1       # mark paquets to shape (2: download)       iptables -A PREROUTING -t mangle ! -s 192.168.0.0/16 -j MARK --set-mark 2# tc       # clean everything       tc qdisc del dev $IF root       # define rates       tc qdisc add dev $IF root handle 1: htb default 30       tc class add dev $IF parent 1:1 classid 1:10 htb rate 400kbit       tc class add dev $IF parent 1:1 classid 1:20 htb rate 3mbit       # affect upload and download to classes for shaping traffic       tc filter add dev $IF protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:10       tc filter add dev $IF protocol ip parent 1:0 prio 1 handle 2 fw flowid 1:20exit 0

Les débits apparaissent a 400kbit (upload) et 3mbit download. En résumé, tout trafic "natté" par ce système, a destination ou en provenance d'un réseau autre que 192.168/16 (en gros non local, même si je prends pas en compte toutes les classes) sera contrôlé pour le débit. PS: je maitrise pas tout : bcp de copier/coller :)

Il y a bien entendu moyen d'affiner, mais ça commence a me prendre la tête et je n'en ai pas besoin, alors j'en reste là.

Et enfin, le serveur DHCP (pour remplacer celui de la box). J'ai eut un soucis avec celui par défaut (isc-dhcp-server) car il n'a l'air d'être capable de servir des ip que dans le même sous-réseau des interfaces REELLES (donc pas br0:0) où il écoute. Le serveur "udhcpd" faisait moins le difficile. Je l'ai configuré pour :

start           192.168.3.100   #default: 192.168.0.20end             192.168.3.200   #default: 192.168.0.254...#Examlesopt     dns     192.168.1.1option  subnet  255.255.255.0opt     router  192.168.3.254#opt    wins    192.168.10.10#option dns     129.219.13.81   # appened to above DNS servers for a total of 3#option domain  localoption  lease   864000          # 10 days of seconds

Et voili. Très surement customisable / optimisable et tout ce que vous voulez ! Si des gens ont un peu le même soucis, peut être trouverez vous des éléments de réponse ici !