[Linux] Deux interfaces sur le même LAN

Le
JKB
Bonjour à tous,

Dans le cadre du remplacement de serveurs de calculs, je suis amené
à monter un truc dans le genre de :

WAN
|
|
switch
| |
| |
serveur frontal
|
|
|
clusters de calculs.

Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)
eth1 est une interface de synchronisation (il y a en fait plusieurs
serveurs frontaux redondants), et eth2 donne accès aux clusters de
calculs. Ces derniers sont accessibles au travers des interfaces
virtuelles eth0:x.

eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28

Les routes par défaut sont :

Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3

Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3. Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !

Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #873326
Salut,

[...]
Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)


Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.

eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28

Les routes par défaut sont :

Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3

Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.


Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?

Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !


213.215.42.70, c'est X.Y.Z.70 ?

Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.


C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.

Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.

Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.

Pascal Hambourg
Le #873325

C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.
[...]

Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.


J'ai oublié un détail important bien que trivial. Le routage normal ne
tient pas compte de l'adresse source pour déterminer l'interface de
sortie. Toutefois on peut modifier ce comportement grâce à des règles de
routage avancé, je crois que tu connais un peu. ;-)

JKB
Le #873324
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
Salut,

[...]
Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)


Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.


Il y a une raison particulière qui n'est pas de la redondance :
sur eth0 je fais de la QoS poussée pour les clusters alors que eth3
est une interface d'administration.

eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28

Les routes par défaut sont :

Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3

Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.


Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?


Oui. Un tcpdump me montre que 213.215.42.69 et 70 tapent _toujours_
sur eth3 (213.215.42.69).

Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !


213.215.42.70, c'est X.Y.Z.70 ?


Oui ;-)

Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.


C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.

Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.

Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.


Et doc ? Je ne vois pas trop comment débrouiller le truc :-(

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


JKB
Le #873323
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
JKB écrivait dans fr.comp.reseaux.ip :
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
Salut,

[...]
Mon serveur frontal possède deux interfaces Ethernet/IP vers le
réseau Internet avec les adresse X.Y.Z.69(eth3) et X.Y.Z.70(eth0)


Y a-t-il une raison particulière d'avoir deux interfaces connectées au
même LAN ? Si c'est pour la bande passante ou la redondance, il vaudrait
mieux faire de l'aggrégation de liens.


Il y a une raison particulière qui n'est pas de la redondance :
sur eth0 je fais de la QoS poussée pour les clusters alors que eth3
est une interface d'administration.

eth3 est une interface d'administration (X.Y.Z.69/28).
eth0 possède l'adresse X.Y.Z.70/28

Les routes par défaut sont :

Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth3
X.Y.Z.64 * 255.255.255.240 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth2
heartbeat * 255.255.255.0 U 0 0 0 eth1
default purcell.systell 0.0.0.0 UG 0 0 0 eth3

Un truc me chagrine : que je fasse un ssh sur X.Y.Z.69 ou X.Y.Z.70,
à chaque fois, je me retrouve sur eth3.


Comment ça, "sur eth3" ? Tu veux dire que le trafic entre toujours par
eth3 ?


Oui. Un tcpdump me montre que 213.215.42.69 et 70 tapent _toujours_
sur eth3 (213.215.42.69).

Pire, lorsque je fais un
ping sur 213.215.42.70, je vois eth3 me répondre (alors qu'en toute
logique, eth0 devrait répondre) _même si_ (et j'insiste sur le même
si) eth0 est down !


213.215.42.70, c'est X.Y.Z.70 ?


Oui ;-)

Toute remarque sera la bienvenue, parce que là, il y a un truc que
je ne comprends pas.


C'est tout simple. Pour le routage de Linux, les adresses locales
n'appartiennent pas spécifiquement à une interface particulière mais
globalement à la machine elle-même.

Pour le trafic entrant, par défaut les deux interfaces répondent aux
requêtes ARP pour n'importe quelle adresse locale. L'émetteur de la
requête ARP utilisera l'adresse MAC de la première réponse reçue. En
gros la plus rapide gagne. Il y a quelques paramètres dans
/proc/sys/net/ipv4/*/conf/ permettant de modifier ce comportement.

Quant au fait que le trafic sorte toujours par eth3, tu vois que tu as
deux routes contradictoires vers X.Y.Z.64/28. Une seule est utilisée, en
pratique la dernière créée. Quant aux destinations extérieures, tu vois
que la route par défaut passe explicitement par eth3, donc rien d'anormal.


Et doc ? Je ne vois pas trop comment débrouiller le truc :-(


Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.

Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.



Pascal Hambourg
Le #873322

Et doc ? Je ne vois pas trop comment débrouiller le truc :-(



Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.

Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.


Ah, si en plus tu nous caches des choses... Envoie !

Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).


Voir la première question.


JKB
Le #873321
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :

Et doc ? Je ne vois pas trop comment débrouiller le truc :-(



Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.


eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).

eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).

Je voulais dire "et donc" ? Les routes sortantes sont gérées par
iproute2 avec un fwmark bien positionné, donc je pense que cela doit
aller.


Ah, si en plus tu nous caches des choses... Envoie !


Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3
Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default
Root gershwin:[/etc/iproute2] >

Maintenant, je ne vois pas comment bricoler dans les options ipv4
pour obtenir ce que je veux (d'autant plus que je n'arrive pas à
trouver de la doc sur le sujet...).


Voir la première question.


Est-ce suffisant ?

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.



Pascal Hambourg
Le #873320
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :


Et doc ? Je ne vois pas trop comment débrouiller le truc :-(



Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.



eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).

eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).


Si je reformule,
1) Trafic reçu :
- destiné à 213.215.42.70 -> doit être reçu sur eth0
- destiné à 213.215.42.69 -> doit être reçu sur eth3

2) Trafic émis :
- source 213.215.42.70 -> doit être émis sur eth0
- source 213.215.42.69 -> doit être émis sur eth3

J'ai bon ?

Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter


La précaution classique.

Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3


Ça ne montre que le contenu de la table 'main', que tu avais déjà fourni
avec le résultat de la commande 'route'.

Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default


Le contenu de la table 'public_traffic' aurait été bienvenu. Je suppose
que son but est d'envoyer par eth0. Que signifie la marque 0x1 ? Elle
marque les paquets provenant des clusters ?

Pour le 1), il faut regarder du côté du paramètre du noyau
/proc/sys/net/ipv4/conf/*/arp_ignore pour faire en sorte que seule
l'interface ayant l'adresse demandée réponde aux requêtes ARP. La valeur
1 devrait convenir. La description se trouve dans le fichier
networking/ip-sysctl.txt de la documentation du noyau, elle-même située
dans le répertoire Documentation/ des sources du noyau.

Pour le 2), je suppose que les règles 101 et 102 devraient se charger
d'envoyer sur eth0 ce qui doit l'être, mais j'ai besoin d'en savoir plus
sur ton routage avancé.




JKB
Le #873319
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
Le 06-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :


Et doc ? Je ne vois pas trop comment débrouiller le truc :-(



Tu veux quoi exactement ? J'ai bien une petite idée, mais je préfère te
laisser l'exprimer.



eth3 (213.215.42.69) pour le trafic à destination de mon serveur frontal
(donc ssh, dns, tous ces trucs...).

eth0 (213.215.42.70) et ses alias pour le trafix à destination des
clusters, le serveur frontal ne faisant que du NAT à destination de ces
clusters et de la QoS (limitation de trafic en fonction des ports et des
adresses).


Si je reformule,
1) Trafic reçu :
- destiné à 213.215.42.70 -> doit être reçu sur eth0
- destiné à 213.215.42.69 -> doit être reçu sur eth3

2) Trafic émis :
- source 213.215.42.70 -> doit être émis sur eth0
- source 213.215.42.69 -> doit être émis sur eth3

J'ai bon ?


Tout à fait.

Root gershwin:[/etc/iproute2] > echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter


La précaution classique.

Root gershwin:[/etc/iproute2] > ip route show
213.215.42.64/28 dev eth0 proto kernel scope link src 213.215.42.70
213.215.42.64/28 dev eth3 proto kernel scope link src 213.215.42.69
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.254
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
default via 213.215.42.65 dev eth3


Ça ne montre que le contenu de la table 'main', que tu avais déjà fourni
avec le résultat de la commande 'route'.

Root gershwin:[/etc/iproute2] > ip rule show
0: from all lookup local
101: from 213.215.42.70 lookup public_traffic
102: from all fwmark 0x1 lookup public_traffic
32766: from all lookup main
32767: from all lookup default


Le contenu de la table 'public_traffic' aurait été bienvenu. Je suppose
que son but est d'envoyer par eth0. Que signifie la marque 0x1 ? Elle
marque les paquets provenant des clusters ?


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é). Comment
obtenir la table public_traffic ? Je la remplis toujours en ligne de
commande par quelque chose du genre :

ip route add default via 213.215.42.65 dev eth0 table public_traffic

dans un script...

Pour le 1), il faut regarder du côté du paramètre du noyau
/proc/sys/net/ipv4/conf/*/arp_ignore pour faire en sorte que seule
l'interface ayant l'adresse demandée réponde aux requêtes ARP. La valeur
1 devrait convenir. La description se trouve dans le fichier
networking/ip-sysctl.txt de la documentation du noyau, elle-même située
dans le répertoire Documentation/ des sources du noyau.


Et zut, j'ai cherché des howtos et de la doc un peu partout et j'ai
carrément oublié de regardé là...

Pour le 2), je suppose que les règles 101 et 102 devraient se charger
d'envoyer sur eth0 ce qui doit l'être, mais j'ai besoin d'en savoir plus
sur ton routage avancé.


Pas de problème, mais il faut que je fasse de l'ordre dans mes
scripts (c'est un peu long...).

Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...

En tout cas, merci pour le tuyau, je vais m'y pencher ce soir et je
donnerai les résultats ici.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.





Pascal Hambourg
Le #873318

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é.

Comment obtenir la table public_traffic ?


$ ip route show table public_traffic

Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...


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.

JKB
Le #873115
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] >

Par ailleurs, tant que je suis ici ;-) Existe-t-il un moyen de
router un paquet local sur une route qui n'est pas une route par
défaut ? Par exemple router les paquets générés _localement_ sur
eth3 (route par défaut) sauf le smtp (par exemple sur eth0) ?
J'arrive sans problème à router comme je veux les paquets qui
transitent par mes machines, mais pas ceux qui sont générés
localement (j'ai même essayé la ciblre ROUTE sans trop de
succès...)...


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.


Je vais essayer. Quant à ROUTE, il existe certaines architectures
(dont celle que j'utilise) dont les cibles MARK ne fonctionnaient
pas jusqu'à récemment. Donc c'était ROUTE ou rien...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.


Publicité
Poster une réponse
Anonyme