1 FAI sur ethernet et 1 FAI sur wifi

J’ai commencé par Mandrake puis Fedora ensuite Ubuntu et me voila sur Debian, j’en suis trés content, tout marche bien :smt002 .

Je dispose d’une connection ethernet branchée sur une freebox et d’une connection wifi avec orange.
Les deux connections fonctionnent bien.

Je voulais savoir si il était possible d’attribuer une connection à une application.
Je voudrai par exemple pouvoir jouer en réseaux avec ma connection ethernet et utiliser epiphany avec la connection wifi.

Si quelqu’un connais une solution …

Tu as la possibilité de faire un routage sur deux passerelle avec iproute. Va voir
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html
traduction ici:http://www.traduc.org/docs/howto/lecture/Adv-Routing-HOWTO.html

Oui fran, mais ce n’est pas un routage “par application”, si ?

En tout cas, ça a été possible et ça doit encore l’être à l’aide d’iptables et d’extensions patch-o-matic, mais c’est de la haute voltige.
AMA, le mieux qu’on puisses faire, c’est agrèger les deux interfaces en une seule pour répartir la charge sur les deux. Mais j’ai un doute quant à la possibilité d’aggreger une carte ethernet et une carte wifi.

Bref, à moins d’un truc que j’aurais manqué: pas facile AMA.

Merci pour le lien, je pense que c’est ce que je cherche.
le lien pour la traduction ne fonctionne pas par contre, enfin c’est pas bien grave.

Je regarderai ça demain je pense et si par miracle j’y arrive je vous tiens au courant.

Bon week-end. :smt006

solution 1 : forcer les routes à la main,
gateway par defaut = passerelle livebox
forcer la route vers les serveurs de jeux vers la passerelle freebox
necessite de connaitre les IP des serveurs de jeux.

solution 2 : filtrage par application (ou plutôt par port)
gateway par defaut = passerelle livebox
forcer les ports utilisés par les appli de jeux en réseau vers la passerelle freebox
ne necessite plus de connaitre les IP des serveurs de jeux mais les ports utilisés par chaque jeux.

En effet, pour ça il faut utiliser le marquage de paquets par iptables décrit un peu plus loin : <http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html>.
Cela permet d’utiliser différentes correspondances d’iptables : protocole, port, UID ou GID du processus…

De toute façon, comme disent les Italiens (je crois), traduction = trahison.

On peut marquer les paquets suivant le pid??
–> man iptables
Damned, effectivement on peut même les marquer par les uid ou les gid. Dans ce cas, ça devient très simple. Je viens de trouver un lien plutôt pas mal…
http://www.samag.com/documents/s=1824/sam0201h/0201h.htm apparemment assez complet.

Non, on ne peut plus depuis le noyau 2.6.14. Je voulais dire UID ou GID, pardon (j’ai corrigé mon message précédent). Les options --pid-owner, --sid-owner et --cmd-owner de la correspondance owner ont été retirées parce que jugées irrémédiablement cassées, notamment en multiprocesseur, et incompatibles avec des modifications ultérieures du noyau. Cf. la page man d’iptables.

Zut, même pas eu le temps d’essayer :frowning:

[quote]NOTE: pid, sid and command matching are broken on SMP
[/quote]

Non, on ne peut plus depuis le noyau 2.6.14. Je voulais dire UID ou GID, pardon (j’ai corrigé mon message précédent). Les options --pid-owner, --sid-owner et --cmd-owner de la correspondance owner ont été retirées parce que jugées irrémédiablement cassées, notamment en multiprocesseur, et incompatibles avec des modifications ultérieures du noyau. Cf. la page man d’iptables.[/quote] C’est de ça que je parlais. Je crois que c’est encore dispo en pom.

Sinon, la page sur le marquage que tu indiques plus haut permet bien un routage complexe, mais toujours pas sur la base d’une appli comme le match owner.

Par contre, il y a un filtrage de couche application (l7filter) qui permet peut être de s’approcher d’une reconnaissance par appli:
l7-filter.sourceforge.net/

Dans le pom ? Ça fait un moment que je n’ai plus regardé, maintenant qu’à peu près tout ce dont j’ai besoin a été intégré aux sources du noyau.

La page que j’ai indiquée montre le principe du routage par marque. Ensuite, il n’est pas bien sorcier de remplacer la correspondance sur le port de destination par une correspondance owner sur l’UID ou le GID dans la règle iptables.

Le plus délicat, ça doit être de faire en sorte que les applications visées soient exécutées avec l’UID|GID spécifique.

Quant à l7filter, outre qu’il faut patcher le noyau, il n’est utilisable en routage avancé que si le motif permettant d’identifier le type de communication est présent dans le premier paquet, ce qui n’est pas le cas en TCP puisqu’un paquet SYN ne contient pas de données. En revanche ça reste possible en UDP, mais il faut utiliser le marquage de connexion (CONNMARK) pour que tous les paquets suivants du flux qui ne contiennent pas forcément le motif suivent le même chemin.

Avant de s’embarquer dans des trucs compliqués, le mieux serait peut-être d’examiner les caractéristiques des différents types de communication à router via l’une ou l’autre connexion. Si ça se trouve un bête routage par protocole/port et/ou adresse de destination suffit. Si par exemple c’est HTTP(S)+DNS+autres trucs connus d’un côté, et le reste de l’autre ça va être simple.

[quote=“PascalHambourg”]Dans le pom ? Ça fait un moment que je n’ai plus regardé, maintenant qu’à peu près tout ce dont j’ai besoin a été intégré aux sources du noyau.[/quote]pas geoip à ce que je sache.[quote=“PascalHambourg”]La page que j’ai indiquée montre le principe du routage par marque. Ensuite, il n’est pas bien sorcier de remplacer la correspondance sur le port de destination par une correspondance owner sur l’UID ou le GID dans la règle iptables. iptables -t mangle -A OUTPUT -m owner --gid-owner <gamers> -j MARK --set-mark 1[/quote] D’accord, encore que ça ne me paraisse pas si évident que ça d’y penser, mais je ne vois pas ce qu’apporte ici l’utilisation d’un marquage. Pour filtrer sur l’UID/GID, on a pas obligatoirement besoin de ça, et si tu ne connais pas owner (ou que tu ne te souviens plus du match, comme moi), un lien sur le marquage avancé n’aide pas vraiment. [quote=“PascalHambourg”]Le plus délicat, ça doit être de faire en sorte que les applications visées soient exécutées avec l’UID|GID spécifique.[/quote] Bah si c’est un service lancé par l’OS, aucun problême pour choisir l’UID ou le GID, et si c’est dans l’espace user, on peut jouer avec les bits suid/sgid et les propriétaires des executables (tant qu’on ne s’amuse pas à donner à l’uid/gid utilisé des privilèges dangereux).[quote=“PascalHambourg”] Quant à l7filter, outre qu’il faut patcher le noyau, il n’est utilisable en routage avancé que si le motif permettant d’identifier le type de communication est présent dans le premier paquet, ce qui n’est pas le cas en TCP puisqu’un paquet SYN ne contient pas de données. En revanche ça reste possible en UDP, mais il faut utiliser le marquage de connexion (CONNMARK) pour que tous les paquets suivants du flux qui ne contiennent pas forcément le motif suivent le même chemin.[/quote] Là, je comprend mieux pourquoi tu parlais de marque.
Sauf que, même si ça ne gène pas forcément avec udp qui est fait pour, comme les paquets udp n’arrivent pas forcément dans l’ordre, il peut y avoir quelques paquets désordonnés qui passent sans être marqués, avant que l’en tête ne soit détecté. [quote=“PascalHambourg”]Avant de s’embarquer dans des trucs compliqués, le mieux serait peut-être d’examiner les caractéristiques des différents types de communication à router via l’une ou l’autre connexion. Si ça se trouve un bête routage par protocole/port et/ou adresse de destination suffit. Si par exemple c’est HTTP(S)+DNS+autres trucs connus d’un côté, et le reste de l’autre ça va être simple.[/quote] C’est aussi ce que je pense, et c’est pour ça que j’ai commencé par dire que ça me paraissait un peu cossu comme truc.

Non, mais je n’ai pas besoin de geoip. :stuck_out_tongue:

Eh ! j’ai indiqué la page du howto et le fait qu’iptables peut filtrer sur l’UID/GID. Si on ne connaît pas la correspondance owner il suffit de faire une recherche avec “uid” ou “gid” dans la page de manuel d’iptables. Qu’est-ce qu’il faut de plus ? Les linuxiens ne sont quand même pas manchots à ce point ? (ha, ha)

Quant à l’utilité de marquer les paquets, elle me paraît évidente : à ma connaissance il n’est pas possible de faire du routage avancé directement en fonction de l’UID/GID du processus ayant émis le paquet, sans passer par une marque d’iptables. (Qu’on ne me parle pas de l’hérésie que constitue la cible ROUTE d’iptables qui permet de forcer le routage d’un paquet).

Ce n’est pas spécifique à UDP, les paquets TCP peuvent aussi arriver dans le désordre. Mais comme dans le cas qui nous occupe les paquets sont émis localement, il y a peu de risque qu’ils soient dans le désordre. Sauf éventuellement s’il y a de la fragmentation (je ne garantis pas l’ordre des fragments), mais l’activation du suivi de connexion réassemble les fragments avant la traversée des chaînes iptables, donc c’est facile à éviter.

J’attire l’attention sur un détail important : tous les paquets sortants d’une communication devront être routés vers la même connexion internet. Si deux paquets sortent par deux connexions différentes, ils auront une adresse source différente et le destinataire ne comprendra rien. Donc on ne peut pas commencer par envoyer les paquets par une connexion, détecter le motif et changer de connexion pour la suite.

Les discussions entre pascal et matt sont toujours aussi passionnantes et instructives.
Continuez à nous instruire.
Merci les gars et bravo.

[quote=“piratebab”]Les discussions entre pascal et matt sont toujours aussi passionnantes et instructives.
Continuez à nous instruire.
Merci les gars et bravo.[/quote] Ne me remercie pas: ce n’est pas en pensant à votre instruction à vous que je cause avec Pascal, mais à la mienne.
En général, si la discussion dure, c’est pour comprendre pourquoi j’avais tort: regardes bien nos échanges tu verras. :smt003

[quote]Qu’on ne me parle pas de l’hérésie que constitue la cible ROUTE d’iptables qui permet de forcer le routage d’un paquet[/quote]En quoi cette cible ROUTE est une héresie (je l’avais remarquée mais jamais utilisée, je n’ai pas besoin de sophistication à ce point, c’est juste pour comprendre, j’apprends des trucs là…)

hello
on peux aussi faire un scripte qui ouvre les connections a la demande, le problème c’est que sa mange un peux de cpu,(puisqu’il faut qu’il recherche en permanence). mai de ce faite on peux choisir qu’elle processus a le droit et ver ou routage etc. ce que fait le script ci-dessou

Il n’est pas pour diriger les paquets sur une interface spécifique. Cela doit pouvoir ce faire de cette manière :wink: en le modifiant

c’est pas la solution nikel mai c’est celle qui a mon avis est la plus souples, le prix les resources cpu note que c’était pas gourmand sur ma machine m’en-fin tout est relatif puis que ma config est un cpu 2,5 ghz :confused:
et tu peux gérer la fréquance du scan ce qui mange du cpu, c’est a chaque passage, sinon il ne fait rien

tu peux t’en inspirer, seulement j’ai pas trop creuser il est probable que des commande son a revoir ce script date de 2007 a mes débuts (sorry pour les fautes)

#!/bin/sh
DAEMON="Firewall 0.3"
NAME="Firewall"
ID=$$
DESC="Firwall 0.3"

#programe autoriser
ProgAuto=(ruby wget nexuiz-li weechat-curse firefox-b ntop evolution http ssh wish underware poker-interfac poker3d)

#performance et securiter
# PauseForBreak=0.1
# PauseForClose=0.1
PauseWhile=0.5
#protocole -i4 =ipv4  -i6 = ipv6 -i=tous
protocol="-i"
# votre interface reseaux
ETH="eth1"
#Fichier temporaire pour les appelles lsof
File="/home/tnt/volatile/lsof_auto"
# si vous voulez que sa scan en permance laisser sure true et i = 1 et boucledesortie = 0
# si vous voulez que cela soie juste pour le démarrage régler a
# une valeur qui vous convienne environ 300
#toute foit avant de rectiver  le par feux vous devrez l'a appler de cette manière:
#/etc/init.d/firewall stop && /etc/init.d/firewall start
boucleinfinie="true"
boucledesortie="0"
i="1"
#log des prog,port fermer (ON : OFF)
LOG="ON"
#permet de loguer avec iptables (ici avec ulog) (ON : OFF)
LOGIP="OFF"
prefix="LOGIP-ON"
#fichier permettant facilment de savoir si un port est fermer
pathlog="/home/tnt/volatile/close.log"
#Repertoire qui ser aux montage d'un volume en ram
ddvol="/home/tnt/volatile"
# cela represente une faille
Restricted="0755"
#Contien le PID  en cour 
PID="/home/tnt/volatile/pid"

echo "Configuration des règles de base"
#root interdi en sortie sauf sur le port 53 !
idroot="0"
#state input
DROPSTATE="-m state --state NEW,INVALID"
#Mise a zero des regle (par précaution)
#
# On remet la police par défaut à ACCEPT
#
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

#
# On remet les polices par défaut pour la table NAT
#
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

#
# On vide (flush) toutes les règles existantes
#
iptables -F
iptables -t nat -F

#
# Et enfin, on efface toutes les chaînes qui ne
# sont pas à defaut dans la table filter et nat

iptables -X
iptables -t nat -X
#==============================================
# on autorise tout ce qui est en local
#règle de filtrage pour rejeter les paquets en prioriter et pour proteger les service par defaut qui son ouvert
iptables -A INPUT -f -j DROP
iptables -A INPUT -p tcp -m length --length 0:20 -j DROP
iptables -A INPUT -p udp -m length --length 0:20 -j DROP
iptables -A INPUT -i $ETH $DROPSTATE -j DROP
iptables -A INPUT -i $ETH -s 192.168.1.0/24 -j ACCEPT
#loopack
iptables -A INPUT -i lo -j ACCEPT
#iptables -t filter -A INPUT -i $ETH -m limit --limit 24/h --limit-burst 1 -p all -j ULOG --ulog-prefix="USER INPUT Final"
#==============================================
#==============================================
#le loopack
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -p TCP --dport 53 -m owner --uid-owner $idroot -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -p UDP --dport 53 -m owner --uid-owner $idroot -j ACCEPT
iptables -A OUTPUT -o $ETH -m owner --uid-owner $idroot -j DROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -o $ETH -d 192.168.1.0/24 -j ACCEPT
#iptables -t filter -A OUTPUT -o $ETH -m limit --limit 24/h --limit-burst 1 -p all -j ULOG --ulog-prefix="USER OUTPUT Final"
#===============================================

set -m

case "$1" in
  start)
echo "montage du disque virtuel"
mount -t tmpfs -o size=5m,nr_inodes=10k,mode=$Restricted tmpfs "$ddvol"
echo "montage du disque terminer"
echo "$$" > "$PID"

while $boucleinfinie ;do
lsof $protocol -P > $File
	while read line ;do
	n1=`echo $line | cut -d":" -f2 | cut -d"(" -f1 | cut -d"-" -f1`
	n2=`echo $line | cut -d" " -f1`
	Found="FALSE"
		if [ "COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME" != "$n1" ] ;then
			for TB in ${ProgAuto[*]} ;do
				if [ "$TB" = "$n2" ] ;then
					#echo "affichage " $n2 "===" $TB "sure le port"  $n1
					Found="TRUE"
					#sleep $PauseForBreak
					break
				fi
			done
			#if [ "$Found" = "TRUE" ] ;then
			#	echo "app auto $n2 sur le port $n1"
			if [ ! -n "${PortClose["$n1"]}" -a "$Found" != "TRUE" ] ;then
				echo "app interdi $n2 sur le port $n1"
				PortClose[$n1]="TRUE"
				if [ "$LOGIP" = "ON" ] ;then
				iptables -t filter -A INPUT -i $ETH -m limit --limit 24/h --limit-burst 1 -p tcp --dport $n1 -j ULOG --ulog-prefix="$prefix"
				iptables -t filter -A INPUT -i $ETH -m limit --limit 24/h --limit-burst 1 -p tcp --sport $n1 -j ULOG --ulog-prefix="$prefix"
				iptables -t filter -A INPUT -i $ETH -m limit --limit 24/h --limit-burst 1 -p udp --dport $n1 -j ULOG --ulog-prefix="$prefix"
				iptables -t filter -A INPUT -i $ETH -m limit --limit 24/h --limit-burst 1 -p udp --dport $n1 -j ULOG --ulog-prefix="$prefix"
				iptables -t filter -A OUTPUT -o $ETH -m limit --limit 24/h --limit-burst 1 -p tcp --dport $n1 -j ULOG --ulog-prefix="$prefix"
				iptables -t filter -A OUTPUT -o $ETH -m limit --limit 24/h --limit-burst 1 -p tcp --sport $n1 -j ULOG --ulog-prefix="$prefix"
				iptables -t filter -A OUTPUT -o $ETH -m limit --limit 24/h --limit-burst 1 -p udp --dport $n1 -j ULOG --ulog-prefix="$prefix"
				iptables -t filter -A OUTPUT -o $ETH -m limit --limit 24/h --limit-burst 1 -p udp --dport $n1 -j ULOG --ulog-prefix="$prefix"

				iptables -A INPUT -i $ETH -p tcp --dport $n1 -j DROP
				iptables -A INPUT -i $ETH -p tcp --sport $n1 -j DROP
				iptables -A INPUT -i $ETH -p udp --dport $n1 -j DROP
				iptables -A INPUT -i $ETH -p udp --sport $n1 -j DROP
				iptables -A OUTPUT -o $ETH -p tcp --dport $n1 -j DROP
				iptables -A OUTPUT -o $ETH -p tcp --sport $n1 -j DROP
				iptables -A OUTPUT -o $ETH -p udp --dport $n1 -j DROP
				iptables -A OUTPUT -o $ETH -p udp --sport $n1 -j DROP
				else
				iptables -A INPUT -i $ETH -p tcp --dport $n1 -j DROP
				iptables -A INPUT -i $ETH -p tcp --sport $n1 -j DROP
				iptables -A INPUT -i $ETH -p udp --dport $n1 -j DROP
				iptables -A INPUT -i $ETH -p udp --sport $n1 -j DROP
				iptables -A OUTPUT -o $ETH -p tcp --dport $n1 -j DROP
				iptables -A OUTPUT -o $ETH -p tcp --sport $n1 -j DROP
				iptables -A OUTPUT -o $ETH -p udp --dport $n1 -j DROP
				iptables -A OUTPUT -o $ETH -p udp --sport $n1 -j DROP
				fi
				#sleep $PauseForClose
				if [ "$LOG" = "ON" ] ;then
					echo "$n2 >=======> $n1" >> $pathlog
				fi
#			elif [ "${PortClose["$n1"]}" = "TRUE" ] ;then
#				echo "port déjà fermer : " $n1
#			else
#				echo "ERREUR inconnue : " ${PortClose[$n1]}
			fi
		fi

	done < $File 
	sleep $PauseWhile

i=$(($i+1))
if [ "$i" = "$boucledesortie" ] ;then
	boucleinfinie="false"
	echo "Le contrôle des programes est terminer le: " `date` >> $pathstop
	
fi
done

	;;
  stop)

PID="/home/tnt/volatile/pid"
ddvol="/home/tnt/volatile"
kill -n 9 $(cat $PID) 2>/dev/null
echo "Demontage du volume"
sleep 2
umount -t tmpfs "/home/tnt/volatile"
# umount -t tmpfs "$ddvol"
echo "Demontage terminer"
echo "Mise a zero des regles d'iptables"
#
# On remet la police par défaut à ACCEPT
#
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

#
# On remet les polices par défaut pour la table NAT
#
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

#
# On vide (flush) toutes les règles existantes
#
iptables -F
iptables -t nat -F

#
# Et enfin, on efface toutes les chaînes qui ne
# sont pas à defaut dans la table filter et nat

iptables -X
iptables -t nat -X
echo "$DAEMON est terminer"
	;;
  *)
	N=/etc/init.d/$NAME
	echo "Ne pas utiliser /etc/init.d/iptable_auto {start} OR news {start}=stop " $DAEMON >&2
	echo "Usage /etc/init.d/firewall stop && (OR) /etc/init.d/firewall start"
	exit 1
	;;
esac

exit 0

Donc en gros tu ferais deux tableaux 1 pour chaque interface et le tour est jouer pour les règles iptable/iproutes c’est a toi d’adapter :slightly_smiling:

Je viens de lire cette discution, fort passionnante, mais là à 6h45 je vous avoue je nage plus: je coule :smt003 :smt003 :smt003 :smt003

Je vais prendre un petit dej’ et relire tout ça tranquillement.
Quoique’il en soit merci beaucoup d’avoir pris de votre temps pour me répondre.

Ne vous prenez pas trop la tête quand même hein, si j’y arrive pas c’est pas non plus la fin du monde :smt002

[quote=“l’institutrice”]
Ne vous prenez pas trop la tête quand même hein, si j’y arrive pas c’est pas non plus la fin du monde :smt002[/quote]
Trop tard, fallait pas poser la question! :smiley:

Elle outrepasse la décision de routage prise par la pile IP. Tu me diras, c’est justement fait pour… Ouais, mais ça force le routage n’importe où alors que les décisions de routage sont censées être prises à des endroits bien précis du cheminement du paquet dans la pile (en entrée, après PREROUTING ; en sortie, avant et éventuellement après OUTPUT). Ça, c’est pour la partie “philosophique”.

En ce qui concerne la partie “pratique”, la cible ROUTE duplique une partie du code source de routage du noyau. Or on connaît le problème avec le code dupliqué : il faut le maintenir synchronisé avec le code de base lors des évolutions de ce dernier, ce qui n’est pas toujours le cas. Il y aurait aussi des problèmes avec IPSec.

En tout cas, le patch ROUTE a été toujours été jugé “cassé” par les développeurs de netfilter, au point qu’il fut retiré du patch-o-matic-ng lors d’un nettoyage.

A noter que ROUTE a une option très prisée par certains : --tee, qui permet de dupliquer le paquet, notamment à des fins d’observation comme un tap ethernet ou un port miroir. Cette fonctionnalité a maintenant droit à sa propre cible TEE.