Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[Linux] Deux interfaces sur le même LAN

20 réponses
Avatar
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.

10 réponses

1 2
Avatar
Clement Cavadore
Pascal Hambourg wrote
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.


... sauf qu'on a un problème: Lorsque iptable marque le paquet, la décision
de routage a déjà été prise. Quand il s'agit de marquets non localement
émis, on utilise PREROUTING, ce qui permet d'avoir un paquet marqué lorsque
la décision de routage est prise. Si quelqu'un a une solution qui marche,
ca m'intéresse, j'avais quelque peu laché l'affaire à l'époque.

--
Clément Cavadore

Avatar
Pascal Hambourg
Pascal Hambourg 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.


Le même problème se produit lorsqu'une règle iptables DNAT dans la
chaîne OUTPUT modifie l'adresse de destination. C'est pourquoi il y a
une seconde décision de routage après les chaînes OUTPUT, qui tient
compte de la marque ou de la nouvelle destination.

Il reste néanmoins un autre problème : la sélection de l'adresse source
par défaut est faite uniquement lors de la première décision de routage
et n'est pas affectée par le reroutage. Le résultat est qu'un paquet est
émis par une interface en portant l'adresse source d'une autre interface.


Avatar
Nina Popravka
On Sun, 07 Oct 2007 10:52:43 +0200, Pascal Hambourg
wrote:

ROUTE c'est moche


Synthétiquement, conceptuellement, pédagogiquement, et en trois
phrases, qu'est-ce qui est moche, dans ROUTE ?
(à partir des trois phrases, j'enquêterai sur les détails pratiques)
:-)
--
Nina

Avatar
JKB
Le 07-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
JKB écrivait dans fr.comp.reseaux.ip :
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
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:320 (320.0 b) TX bytes:0 (0.0 b)
Interrupt:18

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
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:18

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 ? Je n'ai pas trouvé d'option
capable de me tirer de ce mauvais pas et google est un peu sec sur le
sujet...

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

J'avais déjà essayé une configuration à base de bridge ethernet, mais
cela ne fonctionnait pas... Une autre idée saugrenue était de faire
fonctionner eth0 en promiscuous, mais c'est un peu bizarre ;-)

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.



Avatar
Pascal Hambourg
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.

Avatar
JKB
Le 07-10-2007, à propos de
Re: [Linux] Deux interfaces sur le même LAN,
Pascal Hambourg écrivait dans fr.comp.reseaux.ip :
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) ?


Ouaips... Problème de pomme-C/pomme-V ;-)

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 ?


Oui.

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.


1: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:4f:6f:59:fe brd ff:ff:ff:ff:ff:ff
inet 213.215.42.70/28 brd 213.215.42.79 scope global eth0
inet 213.215.42.75/28 brd 213.215.42.79 scope global secondary eth0:1
2: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:4f:6f:59:ff brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1
3: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:4f:6f:5a:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth2
4: eth3: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
link/ether 00:14:4f:6f:5a:01 brd ff:ff:ff:ff:ff:ff
inet 213.215.42.69/28 brd 213.215.42.79 scope global eth3
5: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo


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.


C'est une possibilité, mais je n'arrive pas à la mettre en place
(j'ai essayé il y a quelque temps sans trop de succès). J'ai bien
bricolé des choses avec la table mangle, mais je n'arrive à router
correctement qu'en passant par PREROUTING et non par OUTPUT.

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.


Avatar
Pascal Hambourg

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.


Avatar
Pascal Hambourg

Synthétiquement, conceptuellement, pédagogiquement, et en trois
phrases, qu'est-ce qui est moche, dans ROUTE ?


On lui reproche que iptables n'est pas censé faire du routage. La pile
IP a des décisions de routage à des endroits déterminés du cheminement
des paquets, en fonction des tables et règles de routage, en dehors de
Netfilter. Là dessus, ROUTE vient tout casser en ignorant tout ça alors
que dans la majorité des cas on peut obtenir le même résultat plus
proprement avec la cible iptables MARK et le routage avancé.

Il y a néanmoins une application pratique de la cible ROUTE liée à son
option --tee qui duplique le paquet et route le paquet copié et non le
paquet original. Cela permet d'alimenter un analyseur de paquets ou un
IDS. Mais ça ne marche qu'avec le trafic IP(v4) puisque les règles
iptables ne concernent que ce protocole, mais pas avec le trafic ARP
donc ça ne vaut pas un vrai tap ethernet.

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

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.


En fait, le problème est assez simple : le firewall sortant doit
fonctionner sur l'interface _initiale_ et non sur l'interface de
sortie puisque les règles sont OUTPUT et non POSTROUTING. De plus,
il y a un effet de bord quelque part dans la pile IP (je n'ai pas
plus investigué) qui fait que pour que cela fonctionne, il vaut
mieux rebooter la machine avant...

J'ai planché sur le problème une semaine pour obtenir un résultat
impécable, que je poste ici. Je pense que cela pourra aider
quelqu'un.

eth0 -> route par défaut et interface d'accès aux clusters sur le
LAN (route par défaut des serveurs frontaux)
eth1 -> heartbeat entre les deux serveurs frontaux (et rsync des
disques systèmes)
eth2 -> LAN
eth3 -> tous les paquets localement générés par les serveurs
frontaux sortent par ici. Par contre, avec la cible CONNTRACK,
on arrive à faire sortir par eth0 toutes les connexions TCP
entrantes sur eth0.

Bref, cela donne pour ifconfig :

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
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:229 errors:0 dropped:0 overruns:0 frame:0
TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19941 (19.4 KiB) TX bytes:8048 (7.8 KiB)
Interrupt:18

eth0:1 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.71 Bcast:213.215.42.79 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:18

eth0:2 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FE
inet addr:213.215.42.72 Bcast:213.215.42.79 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:18
...
eth1 Link encap:Ethernet HWaddr 00:14:4F:6F:59:FF
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2796 errors:0 dropped:0 overruns:0 frame:0
TX packets:2756 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:687466 (671.3 KiB) TX bytes:223341 (218.1 KiB)
Interrupt:19

eth2 Link encap:Ethernet HWaddr 00:14:4F:6F:5A:00
inet addr:192.168.1.254 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:20

eth3 Link encap:Ethernet HWaddr 00:14:4F:6F:5A:01
inet addr:213.215.42.69 Bcast:213.215.42.79 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3065 errors:0 dropped:0 overruns:0 frame:0
TX packets:2878 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:279762 (273.2 KiB) TX bytes:1014504 (990.7 KiB)
Interrupt:21

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:426 errors:0 dropped:0 overruns:0 frame:0
TX packets:426 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:38664 (37.7 KiB) TX bytes:38664 (37.7 KiB)

et pour le reste de la configuration :

Root gershwin:[~] > route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
213.215.42.64 * 255.255.255.240 U 0 0 0 eth0
213.215.42.64 * 255.255.255.240 U 0 0 0 eth3
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 eth0
ROot gershwin:[~] > ip route show table local_traffic
default via 213.215.42.65 dev eth3
Root gershwin:[~] > ip rule show
0: from all lookup local
100: from 213.215.42.69 lookup local_traffic
101: from all fwmark 0x1 lookup local_traffic
32766: from all lookup main
32767: from all lookup default
Root gershwin:[~] >

Les règles iptables/iproute2 sont définies par :

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

# Default rules

$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -p icmp -j ACCEPT
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state INVALID -j DROP
$IPTABLES -A OUTPUT -p icmp -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# Heartbeat link

$IPTABLES -A INPUT -i eth1 -j ACCEPT
$IPTABLES -A OUTPUT -o eth1 -j ACCEPT

# Public interface (local traffic). Warning: all locally generated packets
# are sent via eth0 before SNAT rules that change outgoing interface.

$IPTABLES -A INPUT -i eth3 -p tcp -m tcp --dport ssh -j ACCEPT
$IPTABLES -A INPUT -i eth3 -p tcp -m tcp --dport domain -j ACCEPT
$IPTABLES -A INPUT -i eth3 -p udp -m udp --dport domain -j ACCEPT

$IPTABLES -A OUTPUT -o eth0 -p tcp -m tcp --dport ssh -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p tcp -m tcp --dport ftp -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p tcp -m tcp --dport www -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p tcp -m tcp --dport domain -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p udp -m udp --dport domain -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p tcp -m tcp --dport ntp -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p udp -m udp --dport ntp -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p tcp -m tcp --dport svn -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p udp -m udp --dport svn -j ACCEPT

# Local network

$IPTABLES -A OUTPUT -o eth2 -p tcp -m tcp --dport ssh -j ACCEPT

# Gateway for slave host

$IPTABLES -A FORWARD -i eth1 -o eth3 -p tcp -m tcp --dport ftp -j ACCEPT
$IPTABLES -A FORWARD -i eth1 -o eth3 -p tcp -m tcp --dport www -j ACCEPT
$IPTABLES -A FORWARD -i eth1 -o eth3 -p udp -m udp --dport ntp -j ACCEPT
$IPTABLES -A FORWARD -i eth1 -o eth3 -p tcp -m tcp --dport domain
-j ACCEPT
$IPTABLES -A FORWARD -i eth1 -o eth3 -p udp -m udp --dport domain
-j ACCEPT
$IPTABLES -A FORWARD -i eth1 -o eth3 -p icmp -j ACCEPT

$IPTABLES -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -m state --state INVALID -j DROP
$IPTABLES -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth3 -j MASQUERADE

# Mount network interfaces

$IFUP eth0 >& /dev/null
$IFUP eth1 >& /dev/null
$IFUP eth2 >& /dev/null
$IFUP eth3 >& /dev/null

# eth0 : default route. All routed traffics use eth3 with iproute2.

$ROUTE del default dev eth1
$ROUTE add default gw $GATEWAY dev eth0

# Start servers routing tables

$IPROUTE2 rule add from 213.215.42.69 lookup local_traffic priority 100
$IPROUTE2 rule add fwmark 1 table local_traffic priority 101

$IPROUTE2 route add default via $GATEWAY dev eth3 table local_traffic
$IPROUTE2 route flush cache

echo 0 > /proc/sys/net/ipv4/conf/eth3/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth3/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth3/arp_filter

# Local traffic routes

$IPTABLES -t mangle -A PREROUTING -s 192.168.0.0/24 -j MARK --set-mark 1

$IPTABLES -t mangle -A PREROUTING -i eth0 -j CONNMARK --set-mark 2

$IPTABLES -t mangle -A OUTPUT -d 192.168.0.0/24 -j RETURN
$IPTABLES -t mangle -A OUTPUT -d 192.168.1.0/24 -j RETURN
$IPTABLES -t mangle -A OUTPUT -o lo -j RETURN
$IPTABLES -t mangle -A OUTPUT -m connmark --mark 2 -j RETURN
$IPTABLES -t mangle -A OUTPUT -j MARK --set-mark 1

$IPTABLES -t nat -A POSTROUTING -o eth3 -m mark --mark 1 -j SNAT
--to-source 213.215.42.69

$IPTABLES -A INPUT -m tcp -p tcp --dport 22 -j ACCEPT

# Virtual interfaces

for((i=1; $i<=8; i=$((i+1))))
do
$IFCONFIG eth0:$i 213.215.42.$((i+70))
netmask 255.255.255.240 up
done

# Public interface (routed traffic)

for i in ftp www
do
$IPTABLES -A FORWARD -i eth2 -o eth0 -p tcp -m tcp
--dport $i -j ACCEPT
done

# $MDADM $DEV -R /dev/md8
# $MOUNT $DEV /export/home

Cordialement,

JKB, qui présentement essaie de faire fonctionner un raid1 over
iSCSI et tout ce bazar...

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



Avatar
Nina Popravka
On Mon, 15 Oct 2007 12:01:39 +0200, Pascal Hambourg
wrote:

On lui reproche que iptables n'est pas censé faire du routage.


Ah oki, j'avais pas capté que c'était partie intégrante d'iptables...
Vu sous cet angle, c'est certainement très mal.
(je suis une âme simple, ipfilter arrive à mon niveau de conscience,
iptables j'ai du mal ;-> )
--
Nina

1 2