Rectificatif : comme la seconde règle ne match que si la première n'a pas marché, pour alterner entre 3 adresses, il faut progressivement réduire le --every, ainsi :

iptables -t nat -A POSTROUTING -s 10.0.3.78/32 ! -d 10.0.3.0/24 -p tcp -m tcp --dport 80 -m statistic --mode nth --every 3 --packet 0 -j SNAT --to-source 1.2.3.4

iptables -t nat -A POSTROUTING -s 10.0.3.78/32 ! -d 10.0.3.0/24 -p tcp -m tcp --dport 80 -m statistic --mode nth --every 2 --packet 0 -j SNAT --to-source 1.2.3.5

iptables -t nat -A POSTROUTING -s 10.0.3.78/32 ! -d 10.0.3.0/24 -p tcp -m tcp --dport 80 -j SNAT --to-source 1.2.3.6


Jean-François Gigand - Geonef
Paris, France - http://geonef.fr/

Le 25 août 2016 à 14:39, Jean-François Gigand <jf@geonef.fr> a écrit :
Parfait !
Effectivement c'est le boulot de SNAT de réécrire l'ip source, comme c'est expliqué en détail dans http://www.inetdoc.net/guides/iptables-tutorial/snattarget.html (merci David)

Ceci a l'air de fonctionner (10.0.3.78 est ici l'IP du container d'où provient la requête, 1.2.3.* sont les IP des interfaces publiques) :

iptables -t nat -A POSTROUTING -s 10.0.3.78/32 ! -d 10.0.3.0/24 -p tcp -m tcp --dport 80 -m statistic --mode nth --every 2 --packet 0 -j SNAT --to-source 1.2.3.4

iptables -t nat -A POSTROUTING -s 10.0.3.78/32 ! -d 10.0.3.0/24 -p tcp -m tcp --dport 80 -m statistic --mode nth --every 2 --packet 1 -j SNAT --to-source 1.2.3.5



Wallace : il n'y a pas de session http. En l'occurence, l'objectif est d'augmenter la fréquence de requêtes sur certaines API tout en respectant le quota en question.

MrJK : comme je disais plus haut, il ne s'agit pas de *load balancing*, mais de l'inverse, "origin balancing" si ça peut se dire. Les requêtes sont émises par un programme donné mais doivent sortir tantôt "par l'interface A", tantôt par la B (façon de parler, il s'agit d'interfaces virtuelles et de NAT).


Du coup, iptables fera l'affaire pour mon besoin, mais si on devait gérer l'IP constante par session http / cookie, ou autre aspect http-aware, alors l'approche par squid  (tcp_outgoing_address) est la bonne...



Jean-François Gigand - Geonef
Paris, France - http://geonef.fr/

Le 25 août 2016 à 10:21, Christophe Dezé <christophedeze@wanadoo.fr> a écrit :


un truc du genre :

iptables -t nat -A POSTROUTING  -m statistic --mode nth --every 3 -j SNAT --to 1.2.3.4
iptables -t nat -A POSTROUTING  -m statistic --mode nth --every 2 -j SNAT --to 1.2.3.5
iptables -t nat -A POSTROUTING  -m statistic --mode nth --every 1 -j SNAT --to 1.2.3.5


Le 24/08/2016 à 22:15, Jean-François Gigand a écrit :
Bonsoir,

Justement c'est le contraire du classique load-balancing de service...

Merci David, j'ai regardé et le mode "nth" avec --every et --packet devraient coller au besoin.

Je dois alors utiliser -j MASQUERADE (comme la route par défaut, d'ailleurs, puisque les requêtes proviennent d'un container LXC) mais je dois spécifier l'IP pour le nat sur chacune de ces règles, ce que je ne sais pas (encore) faire (d'habitude c'est la table de routage qui s'en occupe).


Jean-François Gigand - Geonef
Paris, France - http://geonef.fr/

Le 24 août 2016 à 22:03, Christophe Dezé <christophedeze@wanadoo.fr> a écrit :

bonjour,

as tu regardé du coté de docker qui peut faire du round-robin en entrée sur plusieurs docker/squid en sortie ?


Le 24/08/2016 à 19:09, Jean-François Gigand a écrit :
Bonjour,

J'ai besoin de mettre en place un proxy HTTP qui bind les requêtes sortantes à une IP source parmi une liste en round-robin.

Par exemple, ayant configuré interfaces(5) avec des ip "failover" comme ceci :

iface eth0:ip1 inet static
      address 1.2.3.4/32
iface eth0:ip2 inet static
      address 1.2.3.5/32
iface eth0:ip3 inet static
      address 1.2.3.6/32

le proxy choisira de binder sa première connexion sortante à 1.2.3.4 puis 1.2.3.5, 1.2.3.6 puis à nouveau 1.2.3.4, etc.

Idéalement, le proxy choisit l'IP dans l'ordre par domaine, ce qui dans l'exemple donnerait [domaine de destination -> IP source] :

domaine1.com -> 1.2.3.4
domaine2.com -> 1.2.3.4
domaine1.com -> 1.2.3.5
domaine1.com -> 1.2.3.6
domaine2.com -> 1.2.3.5

Le proxy doit aussi pouvoir binder en IPv6 (si la destination est accessible en IPv6, même si le client du proxy est IPv4).

Je n'ai pas l'impression que Squid ou HAproxy puissent répondre à ce besoin, mais j'aimerais en être sûr

Est-ce quelqu'un connaît une solution ou une approche à suggérer ?
Ou bien vaut-il mieux écrire un code spécifique ?
(qui devra gérer les requêtes simultanées... en NodeJS par exemple)

Merci !

Jean-François Gigand - Geonef
Paris, France - http://geonef.fr/



_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/