ROUTE c'est moche, tous ceux qui ne l'utilisent pas te le diront. :-p
Les règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.
ROUTE c'est moche, tous ceux qui ne l'utilisent pas te le diront. :-p
Les règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.
ROUTE c'est moche, tous ceux qui ne l'utilisent pas te le diront. :-p
Les règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.
Pascal Hambourg wroteLes règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.
... sauf qu'on a un problème: Lorsque iptable marque le paquet, la décision
de routage a déjà été prise.
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote
Les règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.
... sauf qu'on a un problème: Lorsque iptable marque le paquet, la décision
de routage a déjà été prise.
Pascal Hambourg wroteLes règles de routage (ip rule...) s'appliquent aussi aux paquets émis
localement. Par contre le marquage avec la cible iptables MARK ou
CONNMARK doit être fait dans la chaîne OUTPUT puisque c'est par là et
non par la chaîne PREROUTING que passent ces paquets.
... sauf qu'on a un problème: Lorsque iptable marque le paquet, la décision
de routage a déjà été prise.
ROUTE c'est moche
ROUTE c'est moche
ROUTE c'est moche
Le 07-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Je ne pense pas qu'il soit nécessaire de faire la distinction puisque la
table de routage 'local', qui contient les destinations locales à la
machine et broadcast, a priorité sur les règles de routage avancé.
Je ne suis pourtant pas sûr que cela fonctionne sans (une histoire
de gateway si mes souvenirs sont bons...).Comment obtenir la table public_traffic ?
$ ip route show table public_traffic
Root gershwin:[/etc/mysql] > ip route show table public_traffic
default via 213.215.42.65 dev eth0
Root gershwin:[/etc/mysql] >
Le 07-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Je ne pense pas qu'il soit nécessaire de faire la distinction puisque la
table de routage 'local', qui contient les destinations locales à la
machine et broadcast, a priorité sur les règles de routage avancé.
Je ne suis pourtant pas sûr que cela fonctionne sans (une histoire
de gateway si mes souvenirs sont bons...).
Comment obtenir la table public_traffic ?
$ ip route show table public_traffic
Root gershwin:[/etc/mysql] > ip route show table public_traffic
default via 213.215.42.65 dev eth0
Root gershwin:[/etc/mysql] >
Le 07-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
public_traffic est une table ayant par défaut une route passant par
eth0 (passerelle 213.215.42.65). La marque 0x1 est posée par une
règle ipfilter (ce qui provient de mes clusters par eth2 et qui
n'est pas à destination de la machine frontale est marqué).
Je ne pense pas qu'il soit nécessaire de faire la distinction puisque la
table de routage 'local', qui contient les destinations locales à la
machine et broadcast, a priorité sur les règles de routage avancé.
Je ne suis pourtant pas sûr que cela fonctionne sans (une histoire
de gateway si mes souvenirs sont bons...).Comment obtenir la table public_traffic ?
$ ip route show table public_traffic
Root gershwin:[/etc/mysql] > ip route show table public_traffic
default via 213.215.42.65 dev eth0
Root gershwin:[/etc/mysql] >
Bon, ça progresse :
J'ai rajouté
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
J'arrive à me connecter en ssh sur 213.215.42.70 en voyant le trafic sur
eth0, ce qui est bien le but recherché.
Par contre, mes interfaces virtuelles coincent un peu...
Root gershwin:[/usr/scripts] > ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.70 Bcast:213.215.42.79 Mask:255.255.255.240
est mon interface principale et
Root gershwin:[/usr/scripts] > ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.75 Bcast:213.215.42.79 Mask:255.255.255.240
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Y a-t-il
moyen de contourner le truc, ou faut-il que je trouve un moyen de
remplacer mes interfaces virtuelles ?
Le but ultime est de pouvoir router par eth0 (213.215.42.70) les
adresses de 213.215.42.71 à 213.215.42.78 une par une (pour des
histoires de QoS et de firewall).
Bon, ça progresse :
J'ai rajouté
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
J'arrive à me connecter en ssh sur 213.215.42.70 en voyant le trafic sur
eth0, ce qui est bien le but recherché.
Par contre, mes interfaces virtuelles coincent un peu...
Root gershwin:[/usr/scripts] > ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.70 Bcast:213.215.42.79 Mask:255.255.255.240
est mon interface principale et
Root gershwin:[/usr/scripts] > ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.75 Bcast:213.215.42.79 Mask:255.255.255.240
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Y a-t-il
moyen de contourner le truc, ou faut-il que je trouve un moyen de
remplacer mes interfaces virtuelles ?
Le but ultime est de pouvoir router par eth0 (213.215.42.70) les
adresses de 213.215.42.71 à 213.215.42.78 une par une (pour des
histoires de QoS et de firewall).
Bon, ça progresse :
J'ai rajouté
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
J'arrive à me connecter en ssh sur 213.215.42.70 en voyant le trafic sur
eth0, ce qui est bien le but recherché.
Par contre, mes interfaces virtuelles coincent un peu...
Root gershwin:[/usr/scripts] > ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.70 Bcast:213.215.42.79 Mask:255.255.255.240
est mon interface principale et
Root gershwin:[/usr/scripts] > ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.75 Bcast:213.215.42.79 Mask:255.255.255.240
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Y a-t-il
moyen de contourner le truc, ou faut-il que je trouve un moyen de
remplacer mes interfaces virtuelles ?
Le but ultime est de pouvoir router par eth0 (213.215.42.70) les
adresses de 213.215.42.71 à 213.215.42.78 une par une (pour des
histoires de QoS et de firewall).
Bon, ça progresse :
J'ai rajouté
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
Tu veux dire eth3 sur la dernière ligne (sinon y a doublon) ?
J'arrive à me connecter en ssh sur 213.215.42.70 en voyant le trafic sur
eth0, ce qui est bien le but recherché.
Et le trafic retour sort aussi par la bonne interface ?
Par contre, mes interfaces virtuelles coincent un peu...
Root gershwin:[/usr/scripts] > ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.70 Bcast:213.215.42.79 Mask:255.255.255.240
est mon interface principale et
Root gershwin:[/usr/scripts] > ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.75 Bcast:213.215.42.79 Mask:255.255.255.240
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
Attention que les caches ARP des émetteurs ne contiennent pas
d'anciennes réponses.
Y a-t-il
moyen de contourner le truc, ou faut-il que je trouve un moyen de
remplacer mes interfaces virtuelles ?
Il reste l'artillerie lourde : le filtrage des requêtes ARP avec des
règles arptables.Le but ultime est de pouvoir router par eth0 (213.215.42.70) les
adresses de 213.215.42.71 à 213.215.42.78 une par une (pour des
histoires de QoS et de firewall).
Une pensée : ne serait-il pas plus simple de faire en sorte que le
routage normal dans la table 'main' sorte par eth0 au lieu de eth3 ? Il
n'y aurait ensuite que le traffic émis avec l'adresse source de eth3 à
faire sortir par eth3.
Bon, ça progresse :
J'ai rajouté
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
Tu veux dire eth3 sur la dernière ligne (sinon y a doublon) ?
J'arrive à me connecter en ssh sur 213.215.42.70 en voyant le trafic sur
eth0, ce qui est bien le but recherché.
Et le trafic retour sort aussi par la bonne interface ?
Par contre, mes interfaces virtuelles coincent un peu...
Root gershwin:[/usr/scripts] > ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.70 Bcast:213.215.42.79 Mask:255.255.255.240
est mon interface principale et
Root gershwin:[/usr/scripts] > ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.75 Bcast:213.215.42.79 Mask:255.255.255.240
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
Attention que les caches ARP des émetteurs ne contiennent pas
d'anciennes réponses.
Y a-t-il
moyen de contourner le truc, ou faut-il que je trouve un moyen de
remplacer mes interfaces virtuelles ?
Il reste l'artillerie lourde : le filtrage des requêtes ARP avec des
règles arptables.
Le but ultime est de pouvoir router par eth0 (213.215.42.70) les
adresses de 213.215.42.71 à 213.215.42.78 une par une (pour des
histoires de QoS et de firewall).
Une pensée : ne serait-il pas plus simple de faire en sorte que le
routage normal dans la table 'main' sorte par eth0 au lieu de eth3 ? Il
n'y aurait ensuite que le traffic émis avec l'adresse source de eth3 à
faire sortir par eth3.
Bon, ça progresse :
J'ai rajouté
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
Tu veux dire eth3 sur la dernière ligne (sinon y a doublon) ?
J'arrive à me connecter en ssh sur 213.215.42.70 en voyant le trafic sur
eth0, ce qui est bien le but recherché.
Et le trafic retour sort aussi par la bonne interface ?
Par contre, mes interfaces virtuelles coincent un peu...
Root gershwin:[/usr/scripts] > ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.70 Bcast:213.215.42.79 Mask:255.255.255.240
est mon interface principale et
Root gershwin:[/usr/scripts] > ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.75 Bcast:213.215.42.79 Mask:255.255.255.240
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
Attention que les caches ARP des émetteurs ne contiennent pas
d'anciennes réponses.
Y a-t-il
moyen de contourner le truc, ou faut-il que je trouve un moyen de
remplacer mes interfaces virtuelles ?
Il reste l'artillerie lourde : le filtrage des requêtes ARP avec des
règles arptables.Le but ultime est de pouvoir router par eth0 (213.215.42.70) les
adresses de 213.215.42.71 à 213.215.42.78 une par une (pour des
histoires de QoS et de firewall).
Une pensée : ne serait-il pas plus simple de faire en sorte que le
routage normal dans la table 'main' sorte par eth0 au lieu de eth3 ? Il
n'y aurait ensuite que le traffic émis avec l'adresse source de eth3 à
faire sortir par eth3.
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
Synthétiquement, conceptuellement, pédagogiquement, et en trois
phrases, qu'est-ce qui est moche, dans ROUTE ?
Synthétiquement, conceptuellement, pédagogiquement, et en trois
phrases, qu'est-ce qui est moche, dans ROUTE ?
Synthétiquement, conceptuellement, pédagogiquement, et en trois
phrases, qu'est-ce qui est moche, dans ROUTE ?
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
Bon, j'ai testé sur une de mes machines avec un noyau 2.6.20 et
arp_ignore=1, deux interfaces sur le même segment ethernet avec chacune
une adresse principale et un alias secondaire ethX:1. Résultat conforme
à la théorie : seule l'interface ayant l'adresse principale ou l'alias
secondaire répond aux requêtes ARP pour cette adresse et donc reçoit le
trafic IP destiné à celle-ci.
Pour le routage en sortie, j'ai plus trop d'idée.
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
Bon, j'ai testé sur une de mes machines avec un noyau 2.6.20 et
arp_ignore=1, deux interfaces sur le même segment ethernet avec chacune
une adresse principale et un alias secondaire ethX:1. Résultat conforme
à la théorie : seule l'interface ayant l'adresse principale ou l'alias
secondaire répond aux requêtes ARP pour cette adresse et donc reçoit le
trafic IP destiné à celle-ci.
Pour le routage en sortie, j'ai plus trop d'idée.
l'adresse publique de l'un de mes clusters. Si je fais un ping sur
213.215.42.75, le ping arrive sur eth3. J'ai bien essayé de forcer
arp_ignore sur toutes les interfaces (all), mais rien n'y fait,
arp_ignore ne fonctionne que sur les interfaces matérielles.
Je suis très surpris. Les alias sont normalement des adresses comme les
autres, "ip addr" ne devrait pas montrer d'autre différence que le label
(nom de l'alias). Il faudra que je teste quand j'aurai un peu d'énergie.
Bon, j'ai testé sur une de mes machines avec un noyau 2.6.20 et
arp_ignore=1, deux interfaces sur le même segment ethernet avec chacune
une adresse principale et un alias secondaire ethX:1. Résultat conforme
à la théorie : seule l'interface ayant l'adresse principale ou l'alias
secondaire répond aux requêtes ARP pour cette adresse et donc reçoit le
trafic IP destiné à celle-ci.
Pour le routage en sortie, j'ai plus trop d'idée.
On lui reproche que iptables n'est pas censé faire du routage.
On lui reproche que iptables n'est pas censé faire du routage.
On lui reproche que iptables n'est pas censé faire du routage.