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 <j...@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é <christophed...@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é <christophed...@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 FRsAGhttp://www.frsag.org/ >>> >>> _______________________________________________ Liste de diffusion du >>> FRsAG http://www.frsag.org/ >> >> _______________________________________________ >> Liste de diffusion du FRsAGhttp://www.frsag.org/ >> >> >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
