Bonjour à tous,
Avant d'attaquer le fond du problème, je veux prévenir que je ne cherche pas une solution clé en main mais plutôt des méthodes et des avis pour m'aider à comprendre là où ça ne marche pas.
La situation : 2 box (bouygues et free) sont branchées sur un routeur debian 5.0 pour faire profiter d'un load balancing au LAN privé. J'ai mis ça en place en début de semaine à l'aide d'iproute. Ca semblait marcher impec', puisque le surf sur le net fonctionnait et qu'un peu de monitoring me montrait une bande passante bien partagé entre les deux interfaces.
Manque de bol, en local, une connexion en ssh vers un serveur distant montre un comportement étrange (latence, plantage)... Et, de chez moi, je me rends compte que la connexion vers mon routeur via ssh se passe de la même manière.
Bon ça c'était mardi et depuis je décortique tout à la recherche désespérée de la faille.
Là c'est la partie sympathique : je pars en vancances demain soir! Youpi ! Mais je ne veux pas partir sur un échec et laisser mes collègues continuer à n'avoir accès qu'à une seule connexion... alors à l'aide !
Les détails techniques affreux :
sur le routeur : des règles iptables (acceptation des connexions entrantes sur des ports spécifiques, du DNAT en PREROUTING pour aller vers le serveur apache et du MASQUERADE en POSTROUTING), des commandes "ip route add blablabla" et le load balancing avec ceci :
ip route add default scope global nexthop via $PASSERELLE-BOUYGUES dev eth1 weight 1 nexthop via $PASSERELLE_FREE dev eth4 weight 2
Dès que je remplace cette commande par un "default" unique sans "nexthop" et "wheight" tout redevient normal mais c'est naze puisque c'est pas du tout ce que je veux (et le reste du monde me direz-vous.)
Bon au moment où j'écris ça je me dis que je ferais bien d'aller voir s'il y a déjà eu une question relative à tout ceci posée sur ce forum avant de me faire taper. J'y vais.
Me voilà de retour : alors, ici http://linuxfr.org/forums/15/9626.html la personne qui répond dit justement qu'elle n'a jamais réussi à utiliser le "nexthop" à cause de problème avec SSH mais ça s'arrête là.
Et là : http://linuxfr.org/forums/12/28048.html#1082947 la personne a fait exactement ce que j'ai fais mais ne signale pas de soucis.
Question finale : Qu'en pensez-vous ? Youpi ?
Merci d'avance,
Zombinux
Forum Linux.debian/ubuntu [Réseau] Soucis de Load Balancing
29
juil.
2010
# Mes deux centimes
Posté par Kerro . Évalué à 3.
Debian 5.0.4
Je suppose que tu as l'équivalent de ça:
ip route add 192.168.1.0/24 dev eth1 src 192.168.1.10 table orange
ip route add default via 192.168.1.1 table orange
ip route add 192.168.0.0/24 dev eth2 src 192.168.0.10 table free
ip route add default via 192.168.0.1 table free
ip rule add from 192.168.1.10 table orange
ip rule add from 192.168.0.10 table free
ip route add default scope global nexthop via 192.168.1.1 dev eth1 weight 1 nexthop via 192.168.0.1 dev eth2 weight 4
Dans le doute, il ne te reste plus qu'à monter une machine toute propre et faire le test avec. Si ça fonctionne avec elle, ben tu sais qu'il te reste de longues heures de recherche :-)
[^] # Re: Mes deux centimes
Posté par Zombinux (site web personnel) . Évalué à 2.
Merci de répondre.
Oui, oui, j'ai le même type de config' iproute.
Malheureusement je ne peux pas faire de test avec une machine "toute propre", je n'ai pas le temps (les vacances c'est chouette!)
J'ai continué à chercher et j'ai trouvé, ici et là, d'autre utilisateur qui avait le même problème que moi. J'entrevoie une solution potentielle avec conntrack (il faut que je creuse mais je ne suis plus au travail, donc demain...).
Merci,
Zombinux
[^] # Re: Mes deux centimes
Posté par Kerro . Évalué à 3.
C'est ce qui permet de faire en sorte que tel flux passe toujours par la même connexion.
Attention, piège: il y a une expiration sur temporisation. Du genre après 30 minutes sans données, conntrack oublie ta connexion. Donc les paquets suivants ne passerons peut-être pas sur la bonne liaison.
Avec SSH il faut mettre en place ClientAliveInterval (c'est conseillé dans tous les cas, avis perso).
[^] # Re: Mes deux centimes
Posté par Zombinux (site web personnel) . Évalué à 1.
Après une matinée dessus je n'ai pas réussi.
J'ai viré le MASQUERADE au profit d'un SNAT dans la table nat.
J'ai bien conntrackd qui tourne alors kest-ce qui marche pas?
Tu parles d'expiration sur temporisation mais ça doit prendre un peu de temps, non? Parce que moi, ce que j'ai c'est une impossibilité immédiate de connexion en SSH sur des serveurs distants.
J'ai parcouru plein de tuto et mailing list (cf:LARTC mailing list) mais Je tourne en ronds...
Y-a-t-il des règles de marquage dans la table mangle d'iptables chez vous? J'ai essayé ça sans succès.
D'après vous conntrack fait tout le travail tout seul?
Je part en vacance sur un échec. Ouin!
[^] # Re: Mes deux centimes
Posté par Kerro . Évalué à 4.
A nom avis, la seule bonne solution est de repartir d'une machine propre. Ca permet de s'assurer que ça fonctionne. Ensuite, investigation sur la machine "sale". C'est bien plus rapide que de passer des heures avec google.
# session...
Posté par NeoX . Évalué à 3.
pour les applis deconnectees (web/email) cela va fonctionner car les transactions sont "courtes"
entendre par là que la premiere peut passer par bouygues, la 2e par free, ce n'est pas genant.
par contre en SSH, FTP sur un gros fichier, c'est un mode "connecté"
et il ne faut pas que la box de sortie change en cours de route.
d'ailleurs tu constate que ca marche comme il faut quand tu n'as plus qu'une seule route.
C'est donc une piste à explorer, il me semblait avoir lu un truc dans ce genre dans un linuxmag.
Sinon avant de partir en congé, tu peux peut-etre juste mettre une route par defaut
et un cron ou AT qui mettra une route vers free si le routeur bouygues ne repond pas et inversement.
[^] # Re: session...
Posté par Zombinux (site web personnel) . Évalué à 1.
Alors... il semble que cela puisse marcher avec l'aide de conntrack (cf: les autres réponses), je me penche dessus demain.
Pour le failover que tu me propose: je dispose déjà d'un script monitorant la disponibilité des passerelles pour faire un failover dans le cas de 2 connexions. C'est à dire qu'il vérifie la disponibilité des 2 passerelles et réécrit une règle avec une route unique en cas de pannes de l'une d'elles. Donc,merci beaucoup de me soumettre cette idée qui ne me serait pas venu à l'esprit d'ici demain soir! Car c'est facile de transformer ce script pour réaliser ce que tu me proposes.
# Contrack = tracking connection non ?
Posté par ze_lionix (site web personnel) . Évalué à 2.
http://www.mail-archive.com/lartc@mailman.ds9a.nl/msg16478.h(...)
Par contre se qui me turlupine c'est que pour faire du masquerade ( de souvenir ) fallait l'avoir compilé dans le noyo .....
Fuse : j'en Use et Abuse !
[^] # Re: Contrack = tracking connection non ?
Posté par Zombinux (site web personnel) . Évalué à 2.
C'est rigolo internet... après avoir lancé mon appel à l'aide ici, j'ai dormi un peu, mangé un bout, et continué mes recherches. Je suis tombé exactement sur la même page que tu me propose en lien... celle-ci m'a donc mis la puce conntrack à l'oreille. C'est marrant qu'il ai fallu que je demande de l'aide pour... trouver tout seul! (encore que je n'ai pas encore réussi... je ne devrais pas vendre la peau du chasseur avant de...)
Sinon, à propos du MASQUERADE:
Je m'occupe d'un serveur que je n'ai pas configuré au départ. Ce n'est pas moi qui ai inscrit cette ligne dans les règles iptables.Le noyau n'est ni recompilé ni patché. En faisant des recherches pour mon problème de load balancing j'ai potassé un peu iptables et j'ai vu cette règle proposé plus d'une fois sans jamais mentionner de re-compilation du noyau... et enfin, en faisant mes tests, je peux dire que ça marche vachement moins bien sans cette règle ;)
A+
Zombinux
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.