[Résolu] PB Routage avec bonding et iptables

Support Debian
#1

resalut a tous,

apres le bonding voici le probleme du routage et de iptables. en effet je ping l’interface bond0, mais quand je route de facon a avoir ca:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface localnet * 255.255.255.0 U 0 0 0 eth0 localnet * 255.255.255.0 U 0 0 0 bond0 default 192.168.1.180 0.0.0.0 UG 0 0 0 bond0

L’acces au net des clients est coupé net.
alors soit le pb est du au routage, mais c’est difficile de faire plus simple que ca… ou c’est iptables qui n’est pas configuré correctement… et là je pêche…

(NET)-----(routeur .180)----[-(bond0)—{iptables serveur}—(eth0)-]–(client http a mouha)

voici mes règles IPTABLES:

# Generated by iptables-save v1.3.3 on Thu Nov 30 16:55:17 2006
*nat
:PREROUTING ACCEPT [570:46757]
:POSTROUTING ACCEPT [223:17592]
:OUTPUT ACCEPT [232:18213]
-A POSTROUTING -o bond0 -j MASQUERADE
-A POSTROUTING -s 192.168.1.0/255.255.255.0 -o bond0 -j MASQUERADE
COMMIT
# Completed on Thu Nov 30 16:55:17 2006
# Generated by iptables-save v1.3.3 on Thu Nov 30 16:55:17 2006
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [48:4263]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i bond0 -p udp -m udp --sport 53 --dport 1024:65535 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -m state --state RELATED -j ACCEPT
-A FORWARD -i eth0 -o bond0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i bond0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A OUTPUT -o bond0 -p udp -m udp --sport 1024:65535 --dport 53 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 22 -j ACCEPT
COMMIT
# Completed on Thu Nov 30 16:55:17 2006
# Generated by iptables-save v1.3.3 on Thu Nov 30 16:55:17 2006
*mangle
:PREROUTING ACCEPT [14197:3016870]
:INPUT ACCEPT [13926:2999210]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [15659:3489977]
:POSTROUTING ACCEPT [15730:3502475]
COMMIT
# Completed on Thu Nov 30 16:55:17 2006

est ce qu’il y a une âme charritable pour jetter un oeil à ce probleme avec moua^^ ?

#2

Essaye

route del -net 192.168.1.0/24 eth0

Tu as deux routes pour le réseau local, il y en a une de trop…

(remplace 192.168.1.0/24 par ton localnet), je regarde les règles mais je ne connais pas le bonding :s

[edit: comme tu as tout mis à ACCEPT, je ne penses pas qu’il y ait de soucis de ce coté, je pense vraiment à la table de routage…]

#3

il y a un truc que je ne comprends pas: ton eth0 pointe sur le lan, et bond0 sur le net ?
Parceque si bond0 pointe vers le net, je ne comprends pas cette route vers localnet qui passe par bond0.
Donc comme dit fran, il y a une route en trop, mais pas celle qui passe par eth0.

#4

Tu as raison, je n’avais pas regardé le schéma du réseau en dessous, mais apparemment j’ai l’impression que c’est le gag classique de deux interfaces avec le même réseau: la gw coté bond0 avec IP 192.168.1.180 et le client avec une IP aussi en 192.168.1.??? et donc le même réseau de chaque coté. C’est pour ça que ça coince.

#5

C’est d’ailleurs pour ça que j’ai conseillé à deux trois personnes le bonding. Ca évite les problêmes liés à plusieurs cartes sur le même réseau (mais je n’avais pas noté de mon coté que bond0 avait une adresse privée).

#6

oui, vous avez tous raison , mais le probleme n’est pas là, en fait pour des raisons de continuité de service, j’ai laissé le routeur avec son IP sur le réseau normal. et je prepare le proxy comme je peux dans se b…l organisé ma mon prédécesseur.

Je m’explique, si j’ajoute un route style:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
localnet        *               255.255.255.0   U     0      0        0 eth0
localnet        *               255.255.255.0   U     0      0        0 bond0
default         192.168.1.180   0.0.0.0         UG    0      0        0 eth0
default         192.168.1.180   0.0.0.0         UG    0      0        0 bond0

alors le réseau fonctionne.

Si je retire le route sur eth0, mon poste client SSH , qui de part les regles iptables n’a le droit d’acceder au serveur que par eth0 qui symbolise l’intranet, POF, je suis coincé et suis obligé de me connecter sur le serveur lui même en branchant un clavier. sans compter les services dns secondaire et HTTP qui tombent pour l’intranet (via eth0)…

en effet le Bond est branché sur le même réseau momentanément. mais le but est de faire en sorte que les requête GW, pour le routeur passent par le bond0 plutot que par eth0… (afin que plus tard je puisse isolé le tronçon proxy routeur par (bond0-routeur) sur un reseau a part.

Donc je pense que le soucis viens des regles iptables. je cherche d’ou le probleme peux venir mais si vous trouvez avant moi.

A moin qu’il faille expressement un réseau différent par interface… mais je ne pense pas…

voila ce qui est depuis aujourdhui:

ISDN1 |---|eth2|
2.0/24|---|eth1|   
                  \        
                   |Bond0 2.0/24| >Proxy/firewall< eth0|___[intranet]1.0/24
ISDN2 |___________________________________________/
1.0/24|

et voilà ce qui devra être…

ISDN1 ---|eth1|
                  \
                   |Bond0 2.0/24---Proxy/firewall--|eth0|---[intranet]1.0/24
                  /
ISDN2---|eth2|

il me faut une agregation des connexion internet par ISDN1 et 2… vala…

#7

[quote=“megs”]oui, vous avez tous raison , mais le probleme n’est pas là, en fait pour des raisons de continuité de service, j’ai laissé le routeur avec son IP sur le réseau normal. et je prepare le proxy comme je peux dans se b…l organisé ma mon prédécesseur.

Je m’explique, si j’ajoute un route style:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
localnet        *               255.255.255.0   U     0      0        0 eth0
localnet        *               255.255.255.0   U     0      0        0 bond0
default         192.168.1.180   0.0.0.0         UG    0      0        0 eth0
default         192.168.1.180   0.0.0.0         UG    0      0        0 bond0

alors le réseau fonctionne.
[/quote]
sans doute parce que tout le traffic se fait par eth0 dans ce cas.

[quote=“megs”]

Si je retire le route sur eth0, mon poste client SSH , qui de part les regles iptables n’a le droit d’acceder au serveur que par eth0 qui symbolise l’intranet, POF, je suis coincé et suis obligé de me connecter sur le serveur lui même en branchant un clavier. sans compter les services dns secondaire et HTTP qui tombent pour l’intranet (via eth0)…

en effet le Bond est branché sur le même réseau momentanément. mais le but est de faire en sorte que les requête GW, pour le routeur passent par le bond0 plutot que par eth0… (afin que plus tard je puisse isolé le tronçon proxy routeur par (bond0-routeur) sur un reseau a part.

Donc je pense que le soucis viens des regles iptables. je cherche d’ou le probleme peux venir mais si vous trouvez avant moi.

A moin qu’il faille expressement un réseau différent par interface… mais je ne pense pas…

voila ce qui est depuis aujourdhui:

ISDN1 |---|eth2|
2.0/24|---|eth1|   
                  \        
                   |Bond0 2.0/24| >Proxy/firewall< eth0|___[intranet]1.0/24
ISDN2 |___________________________________________/
1.0/24|

et voilà ce qui devra être…

ISDN1 ---|eth1|
                  \
                   |Bond0 2.0/24---Proxy/firewall--|eth0|---[intranet]1.0/24
                  /
ISDN2---|eth2|

il me faut une agregation des connexion internet par ISDN1 et 2… vala…[/quote]

Ah là c’est plus clair, je vais regarder.

#8

En regardant mieux, ta table de routage devrait être sur la passerelle:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 192.168.2.0 * 255.255.255.0 U 0 0 0 bond0 default 192.168.2.180 0.0.0.0 UG 0 0 0 bond0
cela est confirmé par les lignes 1270 du lien de Matt http://www.linux-m32r.org/lxr/http/source/Documentation/networking/bonding.txt?v=2.6.18

par contre là où je sèche c’est que ayant deux ISDN, tu as j’imagine deux adresses de passerelle (192.168.1.180 et 192.168.2.180), avec le bonding, tu as moyen de regrouper tout ça certes mais quelle est l’adresse de la passerelle que tu déclares à l’extérieur?? Dans les exemples que j’ai lu, le bonding était entre deux machines reliées par plusieurs interfaces réseaux, ici tu as une machine reliée à deux passerelles…

#9

Attention c’est peut être n’importe quoi

En fait plus j’y réfléchis et moins je vois comment tu peux t’en sortir:
Tout ce que j’ai lu indique qu’il faut une machine et une seule à l’autre bout des 2 interfaces (en clair la machine 192.168.2.180) donc il faudrait que les deux routeurs ISDN aient chacun la même adresse IP, mettons 192.168.2.180 qui sera l’adresse de ta passerelle. La table de routage serait celle que je t’ai indiqué. À priori là ça pourrait marcher.

Mais en réfléchissant, le bonding n’est pas si simple, vu de l’extérieur tu apparait sous la forme de deux adresses IP, celle liée à ton ISDN1, mettons IP1 et celle liée à ton ISDN2 (IP2), tu te connectes sur une machine Loin en ssh et ça passe par ISDN1, le retour se fera par ISDN1, Loin discute avec IP1, puis soudain, à un moment tu passes par ISDN2, la machine Loin verra venir des paquets venant de IP2, sa connexion étant avec IP1, ça coincera, elle refusera les paquets et la connexion sera interrompue et toi dépité. Ce problème n’existe pas dans les exemples de bonding que j’ai lu où à l’autre bout il y a une seule machine et pas de MASQUERADING. En gros, cela signifie que dès qu’une connexion est initiée en passant par ISDN1, tout le traffic lié à cette connexion doit passer par ISDN1 y compris si elle est complètement saturée. Ça doit être possible avec les règles iptables et j’ai vu qu’il y avait plein d’options dans le bonding mais ça doit être pensé sérieusement ce truc.

Ton opinion Matt?

#10

quote="megs"A moin qu’il faille expressement un réseau différent par interface… mais je ne pense pas…(…)[/quote]Ben moi, je pense que si. Le problême vient de ton maquettage.
Par contre, indépendament du réseau PHYSIQUE, si tu peux changer la frange attribuée aux clients et l’adresse d’eth0, ou au contraire l’adresse de bond0 et du routeur…
C’est d’ailleurs ce que tu présentes comme etant la solution actuelle(eth0 sur le 1.0 et bond0 sur le 2.0), sauf que la table de routage que tu fournis continue à proposer bond0 comme itinéraire pour accèder au 1.0, et qu’il n’y a aucune route associée à bond0 pour accèder au 2.0.
tu dois avoir par exemple:

[code]eth0: 192.168.1.X/24
bond0: 192.168.2.Y/24
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 eth0
localred * 255.255.255.0 U 0 0 0 bond0
default 192.168.1.180 0.0.0.0 UG 0 0 0 eth0
default 192.168.2.180 0.0.0.0 UG 0 0 0 bond0
^

Avec localred=192.168.2.0/24[/code] Ou alors je n’ai toujours pas compris ta config…

#11

J’ai cherché encore, un peu. Je ne crois pas que cela soit possible sans un aménagement de FT. Essaye de regarder http://www.datenwelt.net/oss/ibod/

[quote]5.5 Agregation de canaux.

L’agregation des canaux est elle une bonne chose, en theorie oui; dans la pratique c’est plus mitigé. En effet France Telecom facture en double les taxes lorsque nous agregeons les canaux. En plus tout les fournisseurs d’acces ne l’autorise pas à la base et souvent demandent meme une surtaxe par rapport à l’abonnement de base isdn.

Il existe au moins un outil pour gerer cela de maniere simple sous linux. Je le teste actuellement;il va donc falloir attendre avant d’en savoir plus. Si vous desirez l’essayer il vous faut prendre contact avec : Bjoern Smith, smith@Compound.SE qui en est l’auteur car je ne sais plus trop d’ou je le tiens moi meme.

Il est peut etre dans quelques distributions a vous de voir. Il porte le nom de XIBOD.

[/quote]

#12

fran, ton lien me semble concerner l’agregation PHYSIQUE de deux canaux ISDN d’un dispositif interne à la machine, et pas le bonding sur deux liens ethernet existants.

Sinon, peux tu m’expliquer comment ISDN1 et ISDN2 (les deux lignes sur lesquels sont branchés deux routeurs) peuvent être au courant de l’activité l’une de l’autre ?

Sinon, pour ce qui est de la double facturation, ben oui, quand on lève les deux lignes en même temps, forcément on paye deux communications, ça parait normal, je ne vois vraiment pas en quoi le gars s’étonne.

Bon, je dispose actuellement à la maison de deux sorties différentes vers le net (une vieille à 512K et une neuve à 30Mo/cable qui tire moins bien que la 512*). Je vais essayer cet AM si je trouve de voir si je peux me mettre dans la même config pour tester.

  • HS: c’est la première fois que je connecte en direct une machine sur le net (par un routeur cable qui fonctionne en bridge ethernet), car d’habitude je passe par des routeur non bridgé, et je viens de découvrir que j’avais un traffic de 10Ko en bruit de fond, même quand je n’avais aucune connection sur ma machine. En regardant ce qui tapait sur mon interface, je me suis aperçu que c’était de l’arp et des élections samba. C’est partout comme ça, ou c’est seulement sur le cable à votre avis ? Et pensez vous que ça diminue ma BP ?
#13

Bon, comme le truc m’intéresse, j’ai fait du bonding avec qemu (assez amusant d’ailleurs, qemu est vraiment extraordinaire quand même). Ça marche effectivement bien dans la configuration classique (le traffic est bien grosso modo partagé en 2 d’après ifconfig) mais avec une adresse IP fixe donnée sur l’ionterface bond0. Je n’arrive pas à lui faire accepter une adresse en DHCP. Sinon, un tcpdump donne l’impression que tout le traffic passe sur eth0… Je retourne à mes copies…

#14

ca yé, FT m’a enfin envoyé le firmware pour upgradé le lanbooster pour faire de l’agregation de cannaux. ca va peut être ce réglé différement du coup! tant pis…, mais si c’est possible je ferais en sorte d’obtenir un routeur qui agrege les deux cannaux, ca fera du 4*64=256 sur deux lignes RNIS.

En fait pour l’agregation de ligne, c’est FT lui même qui ma dit que c’était possible sans surcoût. enfin…je suis a mayotte aussi , c’est pas pareil…rien n’est pareil… :slightly_smiling:

pour le moment ca va faire ca. je vire le bond du coup…puis que en effet, la question était, est ce que le fait de déclarer deux GW , ISDN1 et ISDN2 passant respectivement par eth1 et eth2, informe linux qu’il doit passer sur la deuxième GW quand la premiere est saturé. et si ceci pose problème coté applicatif…ce qui est apparement le cas aux dires de fran.b.

De toute facon, j’ai besoin d’un interface muette dédié à l’écoute du trafic réseau pour l’IDS… je ferais ca avec un des eth dispo.

ISDN1 ---|eth1| (2 abo)
                  \
                   |Bond0 2.0/24---Proxy/firewall--|eth0|---[intranet]1.0/24
#15

En fait, FT doit faire du bonding mais de chaque coté. En fait Matt a parfaitement résumer le bonding en disant que ça unifiait les adresses arp des 2 interfaces, mais ça veut dire que de l’autre coté, il doit y avoir une seule adresse arp, soit par l’intermédiaire d’un switch sur lequel on branche les deux cables, soit par 2 cartes Ethernet elles mêmes agrégés en Bonding. Via mes simulations sur Qemu, ces 2 cas fonctionnent bien (du moins semblent…)

Bon, ben ton pbm est résolu…

#16

oui, enfin, je sais que tel que je voulait le faire c’est pas possible sans un switch entre les routeurs et les eth en bonding… donc oui en quelque sorte c’est résolut.