Pb de routage sur un routeur Tri-Wan en Load-Balancing

david_capelle · Février 21, 2016, 2:31am

Bonjour,

voici un premier message de ma part sur ce forum :
J’ai créé un routeur avec équilibrage de charge sur 3 interfaces “publiques” (eth, eth1 et eth2) reliées à des routeurs WAN (des box pour être précis).
Mon routeur dispose aussi d’une interface “privée” (eth3) donnant accès à mon réseau.

J’ai réalisé l’équilibrage de charge avec une interface tourniquet (teql0), ça à l’air de fonctionner corectement. depuis mon routeur j’accède à internet, en regardant les statistiques de transfer sur les interfaces eth0 à eth2, j’ai a peu près le même nombre de paquets.

Par contre, depuis mon réseau privé, je ne peux pas aller sur Internet. Je peux pinger le routeur (toutes les interfaces) et les boxs (uniquement les interfaces de mon coté).
Je n’arrive pas à pinger les boxs sur le coté Internet. Je pense que la définition de multiples passerelles par défaut, requis par le load-balancing provoque une confusion dans le routage au-travers du routeur.

Voici ma configuration :
Fichier etc/network/interfaces .

auto lo
iface lo inet loopbakc
allow-hotplug eht0
iface eth0 inet static
   addresse 192.168.0.234
   netmask 255.255.255.248
   network 192.168.0.232
   broadcast 192.168.0.239
   up route add defautl dev eth0 gw 192.168.0.233

# idem pour eth1 en .244 sur la gw en .243
# idem pour eht2 en .254 sur la gw en .253

auto teql0
iface teql0 inet static
   addresse 192.168.0.225
   netmask 255.255.255.248
   network 192.168.0.224
   broadcast 192.168.0.231

allow-hotplug eth3
iface eth3 inet static
   address 172.16.17.2
   netmask 255.255.255.0
   network 172.16.17.0
   broadcast 172.16.17.255
   up route add -net 172.16.0.0 netmask 255.255.0.0 gw 172.16.17.1

Fichier /etc/network/load-balancing (script perso pour activer le tourniquet)

tc qdisc add dev eth0 root teql0
tc qdisc add dev eth1 root teql0
tc qdisc add dev eth2 root teql0
ip link set dev teql0 up

Voila, maintenant je sèche, si qq peux me donner un coup de pouce…
Merci d’avance.

David

PascalHambourg · Février 21, 2016, 2:31am

L’ip_forwarding est activé ?
Iptables fait le NAT source (SNAT ou MASQUERADE) sur les interfaces publiques ?

david_capelle · Février 21, 2016, 2:32am

Salut,

yes une réponse, mais malheureusement :

l’option net.ipv4.ip_forward est bien activé (à 1)
-> et cela fonctionne correctement, car je peu pinger mes box depuis le réseau interne, mais uniquement sur l’adresse “privée”. Je ne peux pas pinger une adresse sur Internet (quelqu’elle soit), sauf depuis mon routeur…

Je ne pense pas qu’il soit nécessaire de faire du NAT (SNAT ou MASQUERADE) sur les interfaces publiques depuis le réseau privé. En effet, les box le font déjà, dans l’autre sens. Et j’ai placer squid (+ squidGuard) sur mon routeur pour accélérer et filtrer l’accès Web. Mais, j’ai besoin de pouvoir router vers Internet, ne serai-ce que pour les paquets relatifs aux procoles DNS, POP, SMTP, IMAP et ICMP.

Donc, je suis dans la brume, (comme les gorilles, mais sans Sigourney ).

Merci quand même pour cette première réponse, je pense que mon sujet est assez ardu car, il n’y a pas foule…
A+
David

piratebab · Février 21, 2016, 2:32am

Pascal THe big expert réseau de ce forum.
Il a résolu des cas bien plus coriaces …
Tu es en de bonne mains!

PascalHambourg · Février 21, 2016, 2:32am

Je soupçonne qu’il n’y a pas foule pour répondre parce que l’usage de teql ne doit pas être pas très répandu. Moi-même je ne l’ai jamais utilisé. Néanmoins après m’être un peu documenté, je ne suis pas sûr que a) ce soit le bon outil pour faire de l’équilibrage de charge dans ta configuration et b) tu l’utilises correctement.

a) teql ne fait que distribuer les paquets entre les interfaces. Dans une configuration avec des box qui font du NAT cela peut marcher pour des communications simples comprenant un paquet aller et un paquet retour comme ping, mais pas des communications de type TCP qui nécessitent que tous les paquets d’une même connexion sortent par la même interface.

b) D’après ce que j’ai lu, il ne doit y avoir qu’une route par défaut sur l’interface teql, et pas sur chaque interface. Le noyau Linux ne peut gérer qu’une seule route par défaut (a priori la dernière créée), les autres sont ignorées.

Peux-tu fournir le contenu de la table de routage du routeur (ip route) ?

Quant au NAT source sur le routeur, il n’est pas nécessaire à condition que les box aient une route de retour vers le sous-réseau IP du réseau local pour savoir comment router les paquets de réponse qui arrivent de l’extérieur.

david_capelle · Février 21, 2016, 2:32am

Salut,

en ce qui concerne les box, j’ai bien ajouter les routes vers mes réseaux interne. Cela permet de faire fonctionner correctement les ping depuis les profondeurs de mon réseau jusqu’au box (mais toujours sur la zone privée).

En ce qui concerne la table de routage :
#ip route 192.168.0.248/29 dev eth2 proto kernel scope link src 192.168.0.254 192.168.0.240/29 dev eth1 proto kernel scope link src 192.168.0.244 192.168.0.232/29 dev eth0 proto kernel scope link src 192.168.0.234 192.168.0.224/29 dev teql0 proto kernel scope link src 192.168.0.225 172.16.0.0/24 dev eth3 proto kernel scope link src 172.16.0.100 172.16.0.0/16 via 172.16.0.10 dev eth3 default nexthop via 192.168.0.233 dev eth0 weight 1 nexthop via 192.168.0.243 dev eth1 weight 1 nexthop via 192.168.0.253 dev eth2 weight 1 <!code> Voila, donc tu as compris que mon routeur dispose 3 interfaces coté internet eth0 (192.168.0.234/29) connecté à la box 1 (192.168.0.233) eth1 (192.168.0.244/29) connecté à la box 2 (192.168.0.243) eth2 (192.168.0.254/29) connecté à la box 3 (192.168.0.253) et une interface coté LAN privé eth3 (172.16.0.100/24) avec comme passerelle le routeur 172.16.0.10

Voila donc.
En ce qui concerne l’équilibrage de charge, je suis concient des limites des interfaces touniquets (teql), mais comme j’ai 3 box avec une ligne quasiment identique (environ 4Mb/s à chaque fois). Pas besoin de faire une recherche plus.
Remarque, les paquets TCP d’une communications sont tous reçu par la même interface, celle du 1° paquet, qui est aussi celle de la demande (et tout les paquets de la demande passe par là).
J’ai juste une “surchage” de paquets (et pas trop en octets) avec l’interface eth0, puisque c’est celle que j’utilise comme dns primaire … Donc toutes les requetes DNS transite par celle-là, mais bon…

Voila pour l’info, merci de t’interresser à ce cas. Je pense qu’il y a un pb sur le routage “au travers” de linux lorsqu’il y a une interface teql. En effet, cette interface requier obligatoirement x passerelles par défaut, qui seront utilisées chacune leur tour par l’interface teql. Mais cela fonctionne sur le papier, et est défini pour les connexion provenant de l’hôte. Que se passe-til alors si la connexion ne fait que traversé le routeur ? On ressord par où ? Surement pas par teql, j’ai essayé de définir la d° route par défaut dessu et je me fait jeter comme un mal-propre…
Donc, …

A+
David

PascalHambourg · Février 21, 2016, 2:32am

En fait il n’y a pas trois routes par défaut mais une route multipath avec trois chemins (nexthop), ce qui est plus correct. Par contre cela ne correspond pas avec le contenu du fichier /etc/network/interfaces fourni dans le premier message (à moins que les trois routes par défaut soient converties automatiquement en une route multipath, mais je n’ai jamais vu ça).

En tout cas ça explique que les communications TCP marchent : le routage utilise le même nexthop pour une même destination, donc tous les paquets destinés à un même serveur passent par la même box (du moins tant que la route choisie reste présente dans le cache de routage, ce qui n’est pas forcément le cas si une connexion reste établie pendant un certain temps). Et j’ai l’impression qu’en fait l’interface teql0 n’est pas du tout utilisée, c’est simplement la route multipath qui fait l’équilibrage.

Que les adresses côté internet des box ne répondent pas peut s’expliquer : la route multipath a une chance sur 3 d’envoyer le paquet sur la bonne box. Mais normalement ça doit être pareil depuis le routeur. Concernant l’accès internet depuis le LAN, il se peut que les box ne soient pas capable de NATer des paquets dont l’adresse source est en-dehors de leur sous-réseau, donc il faudrait tester en ajoutant des règles SNAT ou MASQUERADE sur les 3 interfaces du routeur.