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.h (merci David)tml 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.
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
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...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 :
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).Merci David, j'ai regardé et le mode "nth" avec --every et --packet devraient coller au besoin.Bonsoir,Justement c'est le contraire du classique load-balancing de service...
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 :
Merci !(qui devra gérer les requêtes simultanées... en NodeJS par exemple)Ou bien vaut-il mieux écrire un code spécifique ?Est-ce quelqu'un connaît une solution ou une approche à suggérer ?Je n'ai pas l'impression que Squid ou HAproxy puissent répondre à ce besoin, mais j'aimerais en être sûrLe proxy doit aussi pouvoir binder en IPv6 (si la destination est accessible en IPv6, même si le client du proxy est IPv4).domaine2.com -> 1.2.3.5domaine1.com -> 1.2.3.6domaine1.com -> 1.2.3.5domaine2.com -> 1.2.3.4Idéalement, le proxy choisit l'IP dans l'ordre par domaine, ce qui dans l'exemple donnerait [domaine de destination -> IP source] :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.Par exemple, ayant configuré interfaces(5) avec des ip "failover" comme ceci :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.
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
domaine1.com -> 1.2.3.4
_______________________________________________ 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/