R: Transparent proxy

2009-05-12 Thread Carlo Granisso
 

-Messaggio originale-
Da: John Lauro [mailto:john.la...@covenanteyes.com] 
Inviato: lunedì 11 maggio 2009 18.30
A: 'Carlo Granisso'; haproxy@formilux.org
Oggetto: RE: Transparent proxy

 
 And no request were found into webserver (netstat -ntap | grep :80)
 
 After few seconds: 503 Service Unavailable No server is available to 
 handle this request. 
 

 Can you ping your webserver from the haproxy box ok?

Yes


 What does the following show from your webserver:
 netstat -rn
 Does it show the private IP address of your haproxy box as the gateway for
 0.0.0.0?

Here's the output:

Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt
Iface
0.0.0.0 192.168.0.56255.255.255.255 UGH   0 0  0
eth1
192.168.0.0 0.0.0.0 255.255.255.0   U 0 0  0
eth1


On my haproxy box I've lot of connecctions in TIME_WAIT state from haproxy
to webservers.
When I try to get default page from browser no connections were made on
webserver (haproxy open only one tcp connection in SYN_SENT state).


Thanks for your patience.


Carlo



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.325 / Virus Database: 270.12.24/2107 - Release Date: 05/10/09
07:02:00




Re: Transparent proxy

2009-05-12 Thread L. Alberto Giménez
Carlo Granisso wrote:
 Hello everybody, I have a problem with haproxy (1.3.17) and kernel 2.6.29
  
 I have successfully recompiled my kernel with TPROXY modules and installed
 haproxy (compiled from source with tproxy option enabled) and installed
 iptables 1.4.3 (that have tproxy patch).
 Now I can't use transparent proxy function: if I leave in haproxy.cfg this
 line source 0.0.0.0 usesrc clientip haproxy say 503 - Service
 unavailable.
 If I comment out the line, everything work fine (without transparent proxy).
  
 My situation:
  
 haproxy with two ethernet device: first one for public IP, sceond one for
 private IP (192.168.XX.XX)
 two web server with one ethernet for each one connected to my private
 network.
  
  
  
 Have you got ideas or you can provide me examples
Hi, I've just set up a transparent proxy with kernel 2.6.28 (the first
one with official tproxy support) and haproxy 1.3.15 (the version Debian
comes with, but rebuilding the package with the tproxy linux option
enabled).

Just make sure your backends route their outgoing traffic through the
load balancer, since the response packets with the fake address MUST
be seen by the load blancer box to undo the transparent-proxy magic.

Regards,
L. Alberto Giménez





Re: [PATCH] Fix 'tcp-request content [accept|reject] if condition' parser for missing 'if'.

2009-05-12 Thread Willy Tarreau
Hi Maik,

On Tue, May 12, 2009 at 01:36:46AM +0200, Maik Broemme wrote:
 Hi,
 
 attached is a patch which fixes a configuration mistake regarding the
 'tcp-request' option. If you have the following in your configuration
 file:
 
   acl localnet dst 10.0.0.0/8
   tcp-request content reject if localnet
 
 This will work fine, but if you change the 'tcp-request' line and remove
 the 'if' haproxy-1.3.17 will segfault, I think the following changelog
 entry in 1.3.18 addresses this problem:
 
   [BUG] fix parser crash on unconditional tcp content rules

yes precisely.

 But now in 1.3.18 the default behaviour is a bit weird. If you remove
 the 'if' statement the haproxy will reject every connection, regardless
 of matching to 'localnet' or not and the configuration seems to be valid,
 but which is definetly not what expected.

I can't reproduce the issue here. For me, what happens is the right thing :

  - the following config rejects everything :

tcp-request content reject

  - the following config rejects everything which was not accepted :

tcp-request content accept if cond
tcp-request content reject

  - the following config rejects only everything which matches the condition :

tcp-request content reject if cond

The second case above was precisely what led me to discover the segfault
bug, which was introduced in 1.3.17 with the refinement of the config
warnings. But the behaviour has not changed since 1.3.16.

 I have changed this to the following behaviour: If nothing is specified
 after accept or reject the default condition will apply (like source and
 documentation says) and if there is some parameter after accept or
 reject it has to be 'if' or 'unless' anything else will result in:
 
 [ALERT] 131/012555 (27042) : parsing [/etc/haproxy/haproxy.cfg:94] :
 'tcp-request content reject' expects 'if', 'unless' or nothing, but
 found 'localnet'
 [ALERT] 131/012555 (27042) : Error reading configuration file :
 /etc/haproxy/haproxy.cfg
 
 I think this is much more accurate. At least it took me some time to
 verify why the hell my configuration file is valid, but did not work as
 expected. :)

in fact not, that's precisely what I don't want. To workaround the bug
I encountered, I had to write that :

tcp-request content accept if cond
tcp-request content reject if TRUE

That's pretty annoying. All conditionnal actions support either
if/unless cond or inconditional execution if no condition is
specified.

Are you sure your config was OK ? Can you post the example which
causes you trouble ? Maybe your example is right and the doc is
wrong ;-)

Regards,
Willy




Re: TCP traffic multiplexing as balance algorithm?

2009-05-12 Thread Willy Tarreau
Hi Maik,

On Tue, May 12, 2009 at 01:57:47AM +0200, Maik Broemme wrote:
 Hi,
 
 I have a small question. Did someone know if it is possible to do simple
 traffic multiplexing with HAProxy? Maybe I am missing it somehow, but
 want to ask on the list before creating a patch for it.

what do you call traffic multiplexing ? From your description below, I
failed to understand what it consists in.

 Just to answer the real-world scenario question. TCP multiplexing can be
 very useful for debugging backend servers or doing a simple logging and
 passive traffic dumping.
 
 There are two major ideas of implementing it:
 
   - 1:N (Active / Passive)
   - 1:N (Active / Active)
 
 Well active means that request is going to destination and response back
 to client and passive means that only request is going to the destination.
 In configuration it could look like:
 
   listen  smtp-filter 127.0.0.1:25
   modetcp
   balance multiplex
   server  smtp1 10.0.0.5:25
   server  smtp2 10.0.0.6:25
 
 The active / active would be very hard to implement, tcp stream
 synchronisation would be a pain and I think no one will really need
 this, but active / passive is a very useful feature.
 
 In my environment it is often so, that developers need access to real
 traffic data to debug (in the example above) their developed smtp
 software. Is anyone else missing such functionality? :)

Access to real data is solved with tcpdump or logs, I don't see what
your load-balancing method will bring here.

 --Maik

Regards,
Willy