--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 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.i
nterfaces 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, Fran
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, Chri
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 2
nt 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
Pareil, j'utilise Rundeck dans certains cas.
C'est du java, 1 thread par job même si c'est un job remote via ssh...
à part ça, ça marche "bien" et l'interface web est agréable.
Jean-François Gigand - Geonef
Paris, France - http://geonef.fr/
Le 28 juillet 2016 à 11
