HAProxy: Kein Zugriff auf 2. Server

[browne]

Hallo,

ich verlinke hiermit mal meinen englischen Post, da ich gesehen habe, dass im deutschen Forum deutlich mehr Aktivität zu verzeichnen ist.
https://forum.opnsense.org/index.php?topic=17801

Wie bereits dort erwähnt, habe ich bisher ACME und einen Server MEX1 erfolgreich konfiguriert.
Meinen zweiten Server SQLHOST habe ich genau wie den ersten konfiguriert, lediglich die condition unterscheidet sich.
Trotzdem komme ich nicht auf den zweiten Server, da haproxy scheinbar auf die Konfiguration des ersten Servers zurückgreift, was für mich keinerlei Sinn ergibt.

Beweisen lässt sich meine Vermutung, in dem ich unter dem reiter "Reale Server" meinen MEX1 deaktiviere, dann bekomme ich beim Aufruf der URL des SQLHOST statt einem 404 Fehler plötzlich einen 503 Fehler.
Aktiviere ich den Eintrag für MEX1 wieder und ändere NUR die URL-condition des SQLHOST von "esweb" auf "owa" ab, werde ich sofort zum Exchange Server weitergeleitet, obwohl im Server Eintrag die IP des SQLHOST Servers hinterlegt ist.


Log beim Aufruf der URL

Code: [Select]

haproxy[3465]: 192.168.223.215:57161 [23/Jun/2020:13:41:54.003] MEX1_frontend~ MEX1_backend/MEX1 1/0/0/2/3 404 118 - - ---- 1/1/0/0/0 0/0 "GET /esweb/ HTTP/1.1"
haproxy.conf

Code: [Select]

#
# Automatically generated configuration.
# Do not edit this file manually.
#

global
    # NOTE: Could be a security issue, but required for some feature.
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbproc                      1
    nbthread                    1
    tune.ssl.default-dh-param   1024
    spread-checks               0
    tune.chksize                16384
    tune.bufsize                16384
    tune.lua.maxmem             0
    log /var/run/log local0 info

defaults
    log     global
    option redispatch -1
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3

# autogenerated entries for ACLs

# autogenerated entries for config in backends/frontends

# autogenerated entries for stats


# Frontend: redirect_acme_challenge ()
frontend redirect_acme_challenge
    bind 0.0.0.0:80 name 0.0.0.0:80
    mode http
    option http-keep-alive
    # tuning options
    timeout client 30s

    # logging options
    # ACL: Forward_80_to_443
    acl acl_5ede30aae5ac13.40527538 req.ssl_ver gt 0
    # ACL: no_acme_challenge
    acl acl_5ede30ead9bc68.54961199 path_beg -i /.well-known/acme-challenge/

    # ACTION: redirect_acme_challenges
    use_backend acme_challenge_backend if !acl_5ede30aae5ac13.40527538 !acl_5ede30ead9bc68.54961199

# Frontend: MEX1_frontend (my.domain.net/owa)
frontend MEX1_frontend
    http-response set-header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    bind 0.0.0.0:80 name 0.0.0.0:80 ssl no-sslv3 no-tlsv10 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 crt-list /tmp/haproxy/ssl/5edfa47f551f80.62983715.certlist
    bind 0.0.0.0:443 name 0.0.0.0:443 ssl no-sslv3 no-tlsv10 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 crt-list /tmp/haproxy/ssl/5edfa47f551f80.62983715.certlist
    mode http
    option http-keep-alive
    default_backend MEX1_backend
    option forwardfor
    # tuning options
    timeout client 30s

    # logging options
    option httplog
    # ACL: MEX1_condition
    acl acl_5ede305aa428f7.91112437 path_beg -i /owa

    # ACTION: MEX1_rule
    use_backend MEX1_backend if acl_5ede305aa428f7.91112437

# Frontend: LetsEncrypt_Frontend ()
frontend LetsEncrypt_Frontend
    bind 192.168.223.181:80 name 192.168.223.181:80
    mode http
    option http-keep-alive
    option forwardfor
    # tuning options
    timeout client 30s

    # logging options
    # ACL: Forward_80_to_443
    acl acl_5ede30aae5ac13.40527538 req.ssl_ver gt 0
    # ACL: no_acme_challenge
    acl acl_5ede30ead9bc68.54961199 path_beg -i /.well-known/acme-challenge/
    # ERROR: unsupported action type
    # ACTION INVALID:

    # ACTION: redirect_acme_challenges
    use_backend acme_challenge_backend if !acl_5ede30aae5ac13.40527538 !acl_5ede30ead9bc68.54961199

# Frontend: ESWEB_frontend (my.domain.net/esweb)
frontend ESWEB_frontend
    http-response set-header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    bind 0.0.0.0:80 name 0.0.0.0:80 ssl no-sslv3 no-tlsv10 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 crt-list /tmp/haproxy/ssl/5ee21963e60ff8.23840091.certlist
    bind 0.0.0.0:443 name 0.0.0.0:443 ssl no-sslv3 no-tlsv10 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 crt-list /tmp/haproxy/ssl/5ee21963e60ff8.23840091.certlist
    mode http
    option http-keep-alive
    default_backend ESWEB_backend
    option forwardfor
    # tuning options
    timeout client 30s

    # logging options
    option httplog
    # ACL: ESWEB_condition
    acl acl_5ee219894dbd78.15910750 path_beg -i /esweb

    # ACTION: ESWEB_rule
    use_backend ESWEB_backend if acl_5ee219894dbd78.15910750

# Backend: acme_challenge_backend (Added by Let's Encrypt plugin)
backend acme_challenge_backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server acme_challenge_host 127.0.0.1:43580

# Backend: MEX1_backend ()
backend MEX1_backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server MEX1 192.168.200.12:443 ssl verify none

# Backend: ESWEB_backend ()
backend ESWEB_backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server SQLHOST 192.168.200.21:443 ssl verify none


[micneu]

Trage einfach unter Public Service in den Select Rules
Alle Server ein du du von außen erreich willst.

Damit wir besser helfen können poste doch deine Konfiguration


Gesendet von iPad mit Tapatalk Pro

[browne]

Danke!!! Das war es, ich habe jetzt nur noch ein Frontend für alle Backends mit den dazugehörigen Rules.
Ich war der Annahme, dass man für jedes Backend ein dazugehöriges Frontend benötigt.

Also ist es so, dass man für jede Subdomain (z.B. sub1.firma.de) die dahinterliegenden Server (SQLHOST, ESWEB, ...) ein gemeinsames Frontend und so viele unterschiedliche Backends wie Server benötigt?

Ist die haproxy.conf noch nicht die vollständige Konfiguration?
Welche Daten fehlen denn noch?

Grüße
browne

[micneu]

mit der text file config komme ich nicht klar, ich schaue mir immer die gui an.
lieber als bild, so kann ich meine konfig direkt vergleichen

[superwinni2]

Danke!!! Das war es, ich habe jetzt nur noch ein Frontend für alle Backends mit den dazugehörigen Rules.
Ich war der Annahme, dass man für jedes Backend ein dazugehöriges Frontend benötigt.

Also ist es so, dass man für jede Subdomain (z.B. sub1.firma.de) die dahinterliegenden Server (SQLHOST, ESWEB, ...) ein gemeinsames Frontend und so viele unterschiedliche Backends wie Server benötigt?

Ist die haproxy.conf noch nicht die vollständige Konfiguration?
Welche Daten fehlen denn noch?

Grüße
browne

die haproxy.con ist die vollständige Konfiguration. Eben in der Sprache "HAProxy" und nicht "OPNsense GUI"...


Du hast es richtig erkannt. Ein Frontend.
Theoretisch ist das eigentliche Backend der " Backend Pool". Der Backend Pool ist mit den realen Servern verknüpft.


Damit das Frontend entscheiden kann, welchen Backend Pool er ansprechen soll, müssen entsprechend Bedingungen und Regeln angelegt werden.

[browne]

Okay, danke für die Info!

In welchem Szenario würde ich denn dann ein zweites Frontend anlegen?
Bzw. Warum funktioniert es nicht mit zwei einzelnen Frontends?
Ich frage nur, um das ganze besser zu verstehen.

EDIT: Auf dem beigefügten Bild ist meine alte Frontend Konfiguration. Die Konfig für den Exchange Server sieht genau so aus, eben nur mit der anderen rule. Als standard Backend-Pool war auch noch der zum Frontend gehörige Backend eingetragen.

Jetzt habe ich ein Frontend mit den beiden rules für ESWEB und MEX1.

[superwinni2]

Gerne doch

In welchem Szenario würde ich denn dann ein zweites Frontend anlegen?Bzw. Warum funktioniert es nicht mit zwei einzelnen Frontends?Ich frage nur, um das ganze besser zu verstehen.

Ich habe zwei verschiedene Frontends im Einsatz... Einmal http (0.0.0.0:80) und einmal https (0.0.0.0:443).
Je nachdem wie meine Seite nun von extern aufgerufen wird, landet man auf dem http oder https Frontend.
Bei dem http Frontend ist beispielsweise eingerichtet, dass jeglicher Verkehr zu https umgeleitet wird.
Bei https werden meine Backends angesprochen.


Dein HAProxy Dienst lauscht auf dem gleichen Port mit 2 Frontends... Wie soll hier unterschieden werden welcher genommen wird? Bei unterschiedlichen Ports (wie bei mir) ist das dann kein Stress.

Was du mit deinem Edit sagen möchtest, kann ich nicht nachvollziehen

[JeGr]

Was winni schon schreibt.

Ansonsten: Wofür ein zweites Frontend ist tricky, denn das Frontend selbst ist "nur" dazu da, erstmal die Anfragen anzunehmen und ggf. zu verteilen (an ein oder mehrere Backends). Sprich das Frontend hört auf eine oder mehrere IP:Port-Kombinationen. Ein zweites Frontend auf der gleichen Kombo macht kein Sinn, da es nicht unterschieden werden kann - das war dann auch das Problem des OP.

Da ein Frontend auch auf mehrere Ports hören kann, kann man nicht pauschal sagen, für eine neue IP/Port Kombo ein neues Frontend. Das hängt von mehreren Dingen ab, ob das neue Frontend vllt. andere Zertifikate ausliefern soll als das andere. Wenn man bspw. reines TCP Forwarding macht, also einen reinen Port durchschleust (bspw. SAP mit dutzenden Fremdports auf denen dann HTTP oder HTTPS lauscht), dann setzt man je nachdem bspw. durchaus pro IP/Port ein anderes Frontend ein um das ggf. auf mehrere Backends zu verteilen (einfacher als in den ACLs auf Ports zu testen).

Ist also leider ein Fall von "kommt drauf an"