Merci Christophe, c'est précisément ce que je cherchais.

Du coup j'ai le choix entre l'approche par proxy http et le nat iptables...

Je ferai un retour dès que c'est en place :)

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

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

a priori il y plus simple avec squid

https://xiehang.com/blog/2014/03/21/squids-outgoing-ip-round-robin/

Le 24/08/2016 à 22:03, Christophe Dezé 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 FRsAGhttp://www.frsag.org/

---

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

Yop,

Moi je regarderais du coté de keepalived: - VRRP pour tes IPs flottantes - LVS pour la partie load balancing.

Pour tes VIPs, tu devrais pas avoir de soucis. Pour la partie LVS, tu peux tenter l'approche natting, avec marquage du packet (fwmark). Quand tes paquets sont marqué, tu peux les rediriger sur la bonne interface de sortie avec une regle iptables (rien de moche, LVS implique souvent des regles iptables).

Cette solution fonctionnera "simplement" si tes Load Balancer sont des machines distinctes, et si c'est la GW par défaut de ton réseau. Si tu n'es pas dans ce cas de figure, il y'a toujours moyen de faire, mais tu peux rentrer dans des setups qui commencent à devenir compliqué. Pour moi, c'est la méthode élégante, mais peut-etre pas la plus simple.

C'est une approche, mais je serais curieux de savoir s'il y'a d'autres solutions L2 du type. Perso, je fais l'apologie de cette approche dans mon milieu pro, mais ça a du mal à prendre, les gens preferent du HAProxy, mais perso j'aime moins: - Faire de LoadBalancing L3, c'est que bon pour le HTTP quasiment - LVS utilise les fonctionnalité du noyau, alors que HAProxy pas - KeepAlived conf beats HAProxy conf

-- MrJK GPG: https://jeznet.org/jez.asc

Le 24 août 2016 à 16:15, Jean-François Gigand jf@geonef.fr 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 FRsAGhttp://www.frsag.org/

---

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

---

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

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 FRsAGhttp://www.frsag.org/

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

---

Liste de diffusion du FRsAGhttp://www.frsag.org/

Yop, en effet, le premier besoin d'une telle solution est pour une solution de LoadBalancing entrant (sur lequel tu peux rajouter la couche LB sortant). En général les le second implique le premier, mais j'ai du assumer trop vite ;-)

Et en lisant ta solution, finalement, ca marche aussi. Le seul inconvéniant que je vois, c'est que tu est obligé de préciser l'IP source de ton container (mettons que tu en spawn 200, tu devra mettre à four ton iptables). Avec fwmark (implémenté par KeepAlived); je trouve que ca serait une solution un poil plus élégante. Anyway, ça ne correspondrait plus trop à demande initiale, et vu que KISS c'est bien, bah faisons simple ^^

@+

-- MrJK GPG: https://jeznet.org/jez.asc

Le 25 août 2016 à 09:57, Jean-François Gigand jf@geonef.fr a écrit :

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 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/