0

I have set up a haproxy to redirect traffic to two machines. The goal is to have a scenario where sending a query from another machine to the proxy will be redirected to one of the machines 100% of the time. But for some reason, I sometimes get the case where the query just stops at the haproxy.

I know it reaches the haproxy because I tcpdump-ed it. There is logging enabled for the particular port handler and when working it sends the data to the machines and logs it in /var/log/haproxy.log. When the problem occurs I can't see any packages going out via tcpdump or being logged in the log I mentioned.

The haproxy configuration I'm using:

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # Default ciphers to use on SSL-enabled listening sockets.
        # For more information, see ciphers(1SSL). This list is from:
        #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
        # An alternative list with additional directives can be obtained from
        #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
        ssl-default-bind-options no-sslv3

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  10m
        timeout server  10m
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend nova-in
        bind 0.0.0.0:8774
        mode http
        option httplog
        log global
        default_backend nova-server

backend nova-server
        log global
        mode http
        option httplog
        option http-tunnel
        balance uri
        server db-server-01 10.3.80.248:8774 check weight 1
#        server db-server-02 10.3.93.87:8774  check weight 1

frontend nova-in-2
        bind 0.0.0.0:8774
        mode tcp
        option tcplog
        log global
        default_backend nova-server-2

backend nova-server-2
        log global
        mode tcp
        option tcplog
        option http-tunnel
        balance uri
        server db-server-01 10.3.80.248:8774 check weight 1
#        server db-server-02 10.3.93.87:8774  check weight 1

I decided to comment out one of the servers to check if there is something wrong with choosing a server it needs to redirect to, but I got the same error.

When I tested this problem the packages were properly transmitted around 40% of the time.

Does anyone have an idea why some querries stop at the haproxy and others pass without a problem ?

Edit: I forgot to say, firewall is disabled, iptables have been cleared. If someone asks talking directly to the server will always lead to a response, therefore I am sure the problem comes from the haproxy.

Malazzar
  • 21
  • 3
  • Seems to me your problems likely stem from having two frontends binding to the same port, using two different modes. How does HAProxy know which frontend a given connection to port 8774 should use? – GregL Jul 10 '20 at 00:36
  • Yes, I forgot to leave an anwser here for people in there future. Removing the improper frontend and backend, left the other working perfectly. You can't have a frontend for tcp and one for http using the same ip and port. I didn't think this would be a problem since in the same configuration file I used "listen" sections on the same IP:PORT with different modes and I had not problem. – Malazzar Jul 10 '20 at 11:47

0 Answers0