Using tcp-check method for checking multiple local socks5 servers.

2019-06-21 Thread Hongyi Zhao 
Hi all,

I've several socks5 servers running locally on the following ports:

127.0.0.1:1081
127.0.0.1:1082
127.0.0.1:1083
127.0.0.1:1084

All of them can be anonymous accessed locally, I want to balance the
using of them for offering one robust socks5 proxy on 127.0.0.1:8889.

So, I using the following config:

--
global
maxconn 4096
daemon
nbproc 3

defaults
 mode tcp
 retries 3
 option redispatch
 timeout connect 3000
 timeout server 5000
 timeout client 5000

listen socks5-balance
   bind0.0.0.0:8889
   balance roundrobin

server socks5-1 127.0.0.1:1081 check
server socks5-2 127.0.0.1:1082 check
server socks5-3 127.0.0.1:1083 check
server socks5-4 127.0.0.1:1084 check
---

The above configuration can work smoothly, but I want to do further
health checking based on the the following google's website:

http://client3.google.com/generate_204

I know that the tcp-check option for the server line in the haproxy
can do this job for me.

Basically, I want to let the haproxy simulate the following actions
for health-checking on these socks servers:

curl --socks5 127.0.0.1:1081 http://client3.google.com/generate_204
curl --socks5 127.0.0.1:1082 http://client3.google.com/generate_204
curl --socks5 127.0.0.1:1083 http://client3.google.com/generate_204
curl --socks5 127.0.0.1:1084 http://client3.google.com/generate_204

Based on the instructions given here:

https://blog.yuanbin.me/posts/2018-06/2018-06-30_21-26-14/

I changed my config into the following

-
global
maxconn 4096
daemon
nbproc 3

defaults
 mode tcp
 retries 3
 option redispatch
 timeout connect 3000
 timeout server 5000
 timeout client 5000

listen socks5-balance
   bind0.0.0.0:8889
   balance roundrobin
option tcp-check
tcp-check connect
tcp-check send-binary 05020001
tcp-check expect binary 0500
tcp-check send-binary 0501000312636c69656e74332e676f6f676c652e636f6d0050
tcp-check expect binary 050106b5
tcp-check send GET\ /generate_204\ HTTP/1.1\r\n
tcp-check send Host:\ client3.google.com\r\n
tcp-check send User-Agent:\ curl/7.54.0\r\n
tcp-check send Accept:\ */*\r\n
tcp-check send \r\n
tcp-check expect rstring ^HTTP/1.1\ 204
hash-type consistent # optional

server socks5-1 127.0.0.1:1081 check
server socks5-2 127.0.0.1:1082 check
server socks5-3 127.0.0.1:1083 check
server socks5-4 127.0.0.1:1084 check
-

But, this time, when I starting the haproxy with the above config, I
meet the following errors:


$ sudo haproxy -db -f haproxy.cfg.test
[WARNING] 172/103332 (31229) : Server socks5-balance/socks5-4 is DOWN,
reason: Layer7 invalid response, info: "TCPCHK did not match content
'<05>' at step 5", check duration: 382ms. 3 active and 0 backup
servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 172/103332 (31229) : Server socks5-balance/socks5-1 is DOWN,
reason: Layer7 timeout, info: " at step 5 of tcp-check (expect string
'<05>')", check duration: 2000ms. 2 active and 0 backup servers left.
0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 172/10 (31229) : Server socks5-balance/socks5-2 is DOWN,
reason: Layer7 timeout, info: " at step 5 of tcp-check (expect string
'<05>')", check duration: 2001ms. 1 active and 0 backup servers left.
0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 172/10 (31229) : Server socks5-balance/socks5-3 is DOWN,
reason: Layer7 timeout, info: " at step 5 of tcp-check (expect string
'<05>')", check duration: 2000ms. 0 active and 0 backup servers left.
0 sessions active, 0 requeued, 0 remaining in queue.
[ALERT] 172/10 (31229) : proxy 'socks5-balance' has no server available!


How to solve this issue, thanks for your time.

Regards
-- 
Hongsheng Zhao 
Institute of Semiconductors, Chinese Academy of Sciences
GnuPG DSA: 0xD108493

June 21, 2019 - 45% Indian employees leave organizations because of lack of L D opportunities

2019-06-21 Thread TradeBriefs

Re: issue with small object caching

2019-06-21 Thread Christopher Faulet 

Le 21/06/2019 à 17:00, Senthil Naidu a écrit :

Hi,

I am using haproxy 2.0.0 , when I am using IE I can see in the logs the first 
request is reaching the real server and when I do the refresh all subsequent 
request is hitting the cache of haproxy, when I use firefox/crome all the 
request are served by real server only its not hitting the cache on haproxy.

Configuration


global
log /dev/loglocal0 info
stats socket /var/run/haproxy.stat

defaults
option httplog
cache test
total-max-size 100
max-object-size 100
max-age 240

#TESTGRP STARTS#
frontend  TESTGRP
bind 0.0.0.0:80
mode http
http-request cache-use test
http-response cache-store test
log global
option httplog
option forwardfor
maxconn 2000
timeout client 180s
bind-process 1-2
default_backend  TESTGRPBACK

#TESTGRPBACK STARTS#
backend TESTGRPBACK
balance roundrobin
mode http
log global
option httpchk HEAD /
fullconn  2000
timeout server 180s
default-server inter 3s rise 2 fall 3 slowstart 0
server vm-ayw87o 172.30.1.250:80 weight 12 maxconn 2000
#TESTGRP ENDS#

==

haproxy -vv
HA-Proxy version 2.0.0 2019/06/16 - https://haproxy.org/
Build options :
   TARGET  = linux-glibc
   CPU = x86_64
   CC  = gcc
   CFLAGS  = -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv 
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter 
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered 
-Wno-missing-field-initializers -Wtype-limits
   OPTIONS = USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1

Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER +PCRE -PCRE_JIT 
-PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -REGPARM 
-STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT 
+CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB 
-SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD 
-OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS

Default settings :
   bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=2).
Built with OpenSSL version : OpenSSL 1.1.1c  28 May 2019
Running on OpenSSL version : OpenSSL 1.1.1c  28 May 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes

Available polling systems :
   epoll : pref=300,  test result OK
poll : pref=200,  test result OK
  select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as  cannot be specified using 'proto' keyword)
   h2 : mode=HTTP   side=FEmux=H2
   h2 : mode=HTXside=FE|BE mux=H2
 : mode=HTXside=FE|BE mux=H1
 : mode=TCP|HTTP   side=FE|BE mux=PASS

Available services : none

Available filters :
 [SPOE] spoe
 [COMP] compression
 [CACHE] cache
 [TRACE] trace

Regards


Thanks. Everything seems to be ok.

Just to be sure, is there any chance that your server set the header "Vary" on 
responses to FF/Chrome but not on responses to IE ?


Otherwsise, you may try to disable the HTX by setting the directive "no option 
http-use-htx" in your default section.


It could also be helpful to have the request headers as sent from IE and from FF 
and the response headers as sent from your server.


--
Christopher Faulet

HAProxyConf call for paper extension

2019-06-21 Thread Willy Tarreau 
Hi all,

exactly like I predicted (I should have written it publicly), submissions
of talks for the conference have started to accelerate very close to the
deadline, which was today. I got some private comments saying that some
people were as busy as we were over the last week, so I was informed that
the deadline for submissions was postponed by one week, to end on Friday
28th.

However please don't see this as an indication that if it slips once, it
may slip again. If you had an idea to submit, please do it right now
without waiting. If you want to keep the process simple, just send an
e-mail to submiss...@haproxy.com with a subject "talk proposal" and with
a few lines such as :

I deployed haproxy in this unusual configuration that I thought
it would be worth sharing with the community, I think I can make
a 40 (or 10) minutes talk out of it. It's about X/Y/Z ...

If you're unsure about the interest, just propose anyway, as often what
you're used to do seems obvious to you but not to others. If you feel
really shy about your proposal and prefer to ask me before sending it,
just ping me in private and I'll give you some feedback.

Now that can also be about how you managed to optimize something around
haproxy (e.g. how to manage thousands of backends from the CLI, how to
update maps on the fly, how to reduce latency between DCs, etc).

All the details are still here :

  https://www.haproxyconf.com/call-for-papers/

Cheers,
Willy

RE: issue with small object caching

2019-06-21 Thread Senthil Naidu 
Hi,

I am using haproxy 2.0.0 , when I am using IE I can see in the logs the first 
request is reaching the real server and when I do the refresh all subsequent 
request is hitting the cache of haproxy, when I use firefox/crome all the 
request are served by real server only its not hitting the cache on haproxy.

Configuration


global
log /dev/loglocal0 info
stats socket /var/run/haproxy.stat

defaults
option httplog
cache test
   total-max-size 100
   max-object-size 100
   max-age 240

#TESTGRP STARTS#
frontend  TESTGRP
bind 0.0.0.0:80
mode http
http-request cache-use test
http-response cache-store test
log global
option httplog
option forwardfor
maxconn 2000
timeout client 180s
bind-process 1-2
default_backend  TESTGRPBACK

#TESTGRPBACK STARTS#
backend TESTGRPBACK
balance roundrobin
mode http
log global
option httpchk HEAD /
fullconn  2000
timeout server 180s
default-server inter 3s rise 2 fall 3 slowstart 0
server vm-ayw87o 172.30.1.250:80 weight 12 maxconn 2000
#TESTGRP ENDS#

==

haproxy -vv
HA-Proxy version 2.0.0 2019/06/16 - https://haproxy.org/
Build options :
  TARGET  = linux-glibc
  CPU = x86_64
  CC  = gcc
  CFLAGS  = -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv 
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter 
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered 
-Wno-missing-field-initializers -Wtype-limits
  OPTIONS = USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1

Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER +PCRE -PCRE_JIT 
-PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -REGPARM 
-STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT 
+CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB 
-SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD 
-OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=2).
Built with OpenSSL version : OpenSSL 1.1.1c  28 May 2019
Running on OpenSSL version : OpenSSL 1.1.1c  28 May 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as  cannot be specified using 'proto' keyword)
  h2 : mode=HTTP   side=FEmux=H2
  h2 : mode=HTXside=FE|BE mux=H2
: mode=HTXside=FE|BE mux=H1
: mode=TCP|HTTP   side=FE|BE mux=PASS

Available services : none

Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace

Regards
Senthil

-Original Message-
From: Christopher Faulet [mailto:cfau...@haproxy.com] 
Sent: 21 June 2019 20:23
To: Senthil Naidu; haproxy@formilux.org
Subject: Re: issue with small object caching

Le 21/06/2019 à 16:39, Senthil Naidu a écrit :
> I am testing the small object caching feature , when I am trying to 
> browse the site behind haproxy using IE the cache is working but when 
> I try the same from firefox or crome the caching functionality is not working.
> 
> Has anybody faced this issue.
> 

Hi,

Could you provide more information please ? The HAProxy version and if 
possible, a "minimal" configuration to reproduce your issue. Also, share the 
ouput of "haproxy -vv".

When you said the cache doesn't work, you mean there is no caching at all or 
you get an error ? Do you have any logs that could help to understand what's 
happening ?

--
Christopher Faulet

Re: issue with small object caching

2019-06-21 Thread Christopher Faulet 

Le 21/06/2019 à 16:39, Senthil Naidu a écrit :
I am testing the small object caching feature , when I am trying to browse the 
site behind haproxy using IE the cache is working but when I try the same from 
firefox or crome the caching functionality is not working.


Has anybody faced this issue.



Hi,

Could you provide more information please ? The HAProxy version and if possible, 
a "minimal" configuration to reproduce your issue. Also, share the ouput of 
"haproxy -vv".


When you said the cache doesn't work, you mean there is no caching at all or you 
get an error ? Do you have any logs that could help to understand what's happening ?


--
Christopher Faulet

issue with small object caching

2019-06-21 Thread Senthil Naidu 
Hi,

I am testing the small object caching feature , when I am trying to browse the 
site behind haproxy using IE the cache is working but when I try the same from 
firefox or crome the caching functionality is not working.
Has anybody faced this issue.

Regards
Senthil


Senthil Naidu
General Manager - IT Engineering
IT Engineering
Netmagic (An NTT Communications Company)
Direct: +91 +91 22 40090100
Cell: 7738784713
Email: sent...@netmagicsolutions.com
[https://www.netmagicsolutions.com/assets/images/EDM/images/ntt-com-netmagic-logo2018.jpg]
 

Data Center Services  | 
Hosted IT 
Infrastructure
 | Cloud Services 
 | Managed 
Services | 
Infrastructure Application 
| SD-WAN


[https://www.netmagicsolutions.com/assets/images/EDM/images/CIO-Choice-email-2019.jpg]

http-request do-resolve for rDNS queries

2019-06-21 Thread Luke Seelenbinder 
Hello all,

Is it possible to use the new `http-request do-resolve` to do reverse DNS 
lookups? It's left unspecified in the documentation, and I think it'd be 
helpful to clarify for posterity.

I'd like to integrate this as part of a IP blocking methodology, but that would 
depend on rDNS being supported.

Thanks!

Luke

—
Luke Seelenbinder
SermonAudio.com  | Senior Software Engineer

Re: missing table name src_conn_rate

2019-06-21 Thread Willy Tarreau 
On Fri, Jun 21, 2019 at 08:29:35AM +0200, Frederic Lecaille wrote:
> Willy, could you merge this patch please?

Now done, thanks guys,
Willy

Re: missing table name src_conn_rate

2019-06-21 Thread Frederic Lecaille 

On 6/20/19 1:02 PM, William Dauchy wrote:

Hi Fred,

On Thu, Jun 20, 2019 at 09:44:51AM +0200, Frederic Lecaille wrote:

In fact it seems I have broken something and missed this case.
Here is a patch which should fix this issue.


Thanks for the patch, it fixes the issue.


 From 1575a4bcdb52bbb8604521b6673557c178431deb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Thu, 20 Jun 2019 09:31:04 +0200
Subject: [PATCH] BUG/MAJOR: sample: Wrong stick-table name parsing in
  "if/unless" ACL condition.

This bug was introduced by 1b8e68e commit which supposed the stick-table was 
always
stored in struct arg at parsing time. This is never the case with the usage of
"if/unless" conditions in stick-table declared as backends. In this case, this 
is
the name of the proxy which must be considered as the stick-table name.


Tested-by: William Dauchy 


Thank you for this feedback William.

Willy, could you merge this patch please?

Fred.