Thanks Baptiste, I will try the latest snapshot.
Mir
On Nov 7, 2011, at 10:27 PM, Baptiste wrote:
> Hi,
>
> The configuration is for HAProxy 1.5-something :)
>
> cheers
>
> On Tue, Nov 8, 2011 at 3:00 AM, Mir Islam <mislam#mirislam.com> wrote:
>> Thanks Vincent for the link. That is exactly what I was looking for. However the configuration they provided does not work out of the box. My knowledge in HAProxy is less than two days old. So if you or anyone else can tell me what the following errors mean, I will appreciate it a lot.
>>
>> First one is simple, for some reason binary type is not valid for stick-table? All I could see in web site in reference to "ip" but not binary or other types. I have compiled haproxy 1.4.18 from source on linux.
>>
>> ./haproxy -f ./haproxy-zdm-ssl2.cfg
>> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:8] : stick-table: unknown type 'binary'.
>> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:10] : error detected while parsing ACL 'clienthello'.
>> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:11] : error detected while parsing ACL 'serverhello'.
>> [WARNING] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:14] : tcp-request inspect-delay will be ignored because backend 'https' has no frontend capability
>> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:15] : error detected in backend 'https' while parsing 'if' condition
>> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:18] : unknown keyword 'tcp-response' in 'backend' section
>> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:24] : 'stick': unknown fetch method 'payload_lv(43,1)'.
>> [ALERT] 311/015412 (23710) : parsing [./haproxy-zdm-ssl2.cfg:27] : 'stick': unknown fetch method 'payload_lv(43,1)'.
>> [ALERT] 311/015412 (23710) : Error(s) found in configuration file : ./haproxy-zdm-ssl2.cfg
>> [WARNING] 311/015412 (23710) : config : missing timeouts for backend 'https'.
>> | While not properly invalid, you will certainly encounter various problems
>> | with such a configuration. To fix this, please ensure that all following
>> | timeouts are set to a non-zero value: 'client', 'connect', 'server'.
>> [ALERT] 311/015412 (23710) : Fatal errors found in configuration.
>>
>>
>> My configuration
>>
>> backend https
>> mode tcp
>> balance roundrobin
>> srvtimeout 50000
>>
>> # maximum SSL session ID length is 32 bytes.
>> stick-table type binary len 32 size 30k expire 30m
>>
>> acl clienthello req_ssl_hello_type 1
>> acl serverhello rep_ssl_hello_type 2
>>
>> # use tcp content accepts to detects ssl client and server hello.
>> tcp-request inspect-delay 5s
>> tcp-request content accept if clienthello
>>
>> # no timeout on response inspect delay by default.
>> tcp-response content accept if serverhello
>>
>> # SSL session ID (SSLID) may be present on a client or server hello.
>> # Its length is coded on 1 byte at offset 43 and its value starts
>> # at offset 44.
>> # Match and learn on request if client hello.
>> stick on payload_lv(43,1) if clienthello
>>
>> # Learn on response if server hello.
>> stick store-response payload_lv(43,1) if serverhello
>>
>> server s1 192.168.1.1:443
>> server s2 192.168.1.2:443
>>
>>
>>
>>
>> On Nov 7, 2011, at 12:00 PM, Vincent Bernat wrote:
>>
>>> OoO Pendant le journal télévisé du lundi 07 novembre 2011, vers 20:16,
>>> Mir Islam <mislam#mirislam.com> disait :
>>>
>>>> Yea that is the problem. Right now SSL is terminated at the
>>>> application level on each server. There is no way to inspect the
>>>> cookie even if the server sets one. Sticky session in TCP mode can be
>>>> done by source IP (that is why I have balance source). But that
>>>> creates the other problem as I mentioned. Folks coming from behind
>>>> NAT will hit the same server and not get load balanced. Because
>>>> HAProxy will think they are all the same. I was trying to find out if
>>>> there is something else that could be done. From my own logical
>>>> reasoning, no. :) but I have been wrong before so I was hoping
>>>> someone had similar issue.
>>>
>>> See this post:
>>> http://blog.exceliance.fr/2011/07/04/maintain-affinity-based-on-ssl-session-id/
>>>
>>> While this won't work, in theory, if client is requesting to use
>>> tickets, almost all clients keep the right session ID even when using
>>> tickets. You should of course ensure that a client will keep the same
>>> session ID all the time. This means that you need to ensure that your
>>> web server is able to resume session with and without tickets correctly.
>>> For example, with nginx, you need to configure a session cache.
>>> --
>>> Vincent Bernat ☯ http://vincent.bernat.im
>>>
>>> Keep it right when you make it faster.
>>> - The Elements of Programming Style (Kernighan & Plauger)
>>
>>
>>
Received on 2011/11/08 15:44