HAProxy: Rule Verständnisfrage

[superwinni2]

Ich würde es auf den Hostnamen ändern... du brauchst auf jeden fall eine unterscheidung zwischen den eizelnen anfragen / servern... Hier bietet sich eigentlich so gut wie immer der FQDN an.
Daher würde ich die Condition z.B. ändern auf "mattermost.domain.xyz" und wenn beispielsweise irgendwann noch ne Wordpress dazu kommt dann gibts ne neue regel die besagt wenn wordpress.domain.xyz aufgerufen wird soll das Backend von Wordpress greifen.


Musst natürlich soweit mitdenken, dass bei dir auch noch letsencrypt läuft
Darfst aber natürlich gerne wieder die config posten und dann schau ich mir an was du zusammen konfiguriert hast

[wirehire]

ich habe die matches jetzt mal auf host angepasst.

die erste greift , aber bei der zweiten will er das andere zertifikat nehmen. beim syntax test kommt das der backend kein frontend hat.

ich poste gleich mal die config

[wirehire]

#
# 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 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: mattermost_frontend ()
frontend mattermost_frontend
    bind 0.0.0.0:80 name 0.0.0.0:80 ssl  crt-list /tmp/haproxy/ssl/5ce7b75390d475.80894832.certlist
    bind 0.0.0.0:443 name 0.0.0.0:443 ssl  crt-list /tmp/haproxy/ssl/5ce7b75390d475.80894832.certlist
    mode http
    option http-keep-alive
    default_backend Mattermost_back
    # tuning options
    timeout client 30s

    # logging options
    # ACL: Mattermost_ACL
    acl acl_5ce7bccb5fd722.63607215 hdr(host) -i matter.example.com

    # ACTION: Mattermost_aktion
    use_backend Mattermost_back if acl_5ce7bccb5fd722.63607215

# Frontend: nextcloud_frontend ()
frontend nextcloud_frontend
    bind 0.0.0.0:80 name 0.0.0.0:80 ssl  crt-list /tmp/haproxy/ssl/5ce84c367bfcf8.98124961.certlist
    bind 0.0.0.0:443 name 0.0.0.0:443 ssl  crt-list /tmp/haproxy/ssl/5ce84c367bfcf8.98124961.certlist
    mode http
    option http-keep-alive
    default_backend Nextcloud_back
    # tuning options
    timeout client 30s

    # logging options
    # ACL: NEXTCLOUD_ACL
    acl acl_5ce84de7069a99.41039013 hdr(host) -i cloud.example.com

    # ACTION: Nextcloud_aktion
    use_backend Nextcloud_back if acl_5ce84de7069a99.41039013

# Backend: Mattermost_back ()
backend Mattermost_back
    # 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 never
    server Mattermost 192.168.1.20:80

# 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 never
    server acme_challenge_host 127.0.0.1:43580

# Backend: Nextcloud_back ()
backend Nextcloud_back
    # 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 never
    server Nextcloud 192.168.1.40:80


noch mal angepasst, jetzt kommen keine syntax fehler

[wirehire]

 Im log sehe ich das er immer auf das erste matter frontend geht.

[superwinni2]

Ahhh großer Fehler... Ich glaube der passiert jeden...
Du brauchst zwei Frontends...
 - ein http Frontend
 - ein https Frontend


Diese Frontend "reagieren" entweder auf deine http Anfragen bzw auf deine https Anfragen....
PS. Ich weiß nicht ob es funktioniert, dass man im Backend angibt die Regel "find_acme_challenge" benutzt... Ich benutze sozusagen meine eigene im Frontend... Aber auch hier führen vielleicht viele Wege nach Rom


Also ich würde folgendes machen:

Code: [Select]


"Ganz von vorne anfangen"
Frontend für http anlegen
Frontend für https anlegen
Conditions erstellen
  - host_ist_matterhost  -> Host matches matterhost.example.com
  - host_ist_nextcloud   -> Host matches nextcloud.example.com
  - find_acme_challenge  -> Pfad beginnt mit /.well-known/acme-challenge/
  - nicht_acme_challenge -> Pfad beginnt nicht mit /.well-known/acme-challenge/


Dann folgende Regeln erstellen
  - SSL_Redirect_matterhost -> host_ist_matterhost & nicht_acme_challenge -> http-request redirect "scheme https code 301"
  - SSL_Redirece_nextcloud  -> host_ist_nextcloud & nicht_acme_challenge  -> http-request redirect "scheme https code 301"
  - Backend_matterhost      -> host_ist_matterhost & nicht_acme_challenge -> Benutze backend "Matterhost"
  - Backend_nextcloud       -> host_ist_nextcloud & nicht_acme_challenge  -> Benutze backend "Nextcloud"
  - Backend_acme            -> find_acme_challenge                        -> Benutze Backend "acme"


Dann die Regeln aus deinen Backends löschen... Regeln benutze ich nur im Frontend.
Regeln für http Frontend:
  - SSL_Redirect_matterhost
  - SSL_Redirect_nextcloud
  - Backend_acme


Regeln für https Frontend:
 - Backend_matterhost
 - Backend_nextcloud


Dann nochmals probieren...
Ich hoffe ich habe nichts vergessen um alles bei dir abzubilden Falls ja bitte ich um verzeihung.. Dann suchen wir den Fehler erneut

[wirehire]

erstmal vielen Dank. Ich teste es sofort!

[superwinni2]

Kein Problem
Vielleicht kommt auch jemand und schreit "aber das geht viel besser"
Falls das jemand liest und dies denkt darf er gerne zwischen rein schreien
Ich bin immer offen für Kritik

[wirehire]

jetzt hat es geklappt.

so macht es auch mehr Sinn von der Struktur und dem Aufbau. Jetzt kann ich es besser nachvollziehen.

ich hatte gerade noch vergessen ssl entlastung und die beiden  zertifikate beim https frontend einzustellen. dann ging es mit deiner Anleitung!

Vielen Dank

(ich werde davon eine Doku erstellen)

[wirehire]

Noch eine Frage hätte ich, wenn jetzt  ein Dienst selber seine zertifikate durch letsencrypt zieht, würde ihn dann das doppel ssl stören?


 webseite beispiel.example.com hat ssl

 und wenn ich dann im frontend auch noch ein zertifikat hinzufüge über das le plugin?

 oder würde ich dann eher eine regel machen match host =beispiel.example.com und das dann auf das http frontend packen?

sehe das es für mailcow einen haproxy Anleitung gibt.

frontend https-in
  bind :::443 v4v6 ssl crt mailcow.pem
  default_backend mailcow

backend mailcow
  option forwardfor
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
  server mailcow 127.0.0.1:8080 check

würde jetzt für mich bedeuten, letsencrypt plugin zertifikat erstellen, backend einstellen wie in der config.

richtig?

[superwinni2]

schön zu hören das es funktioniert


Also eigentlich sollte es kein Problem geben, auch intern über https zu kommunizieren.
Muss mal schauen ob ich dies irgendwo so habe, aber ich glaube ich habe intern bisher immer so gut wie nur unverschlüsselte Verbindungen...
Kann ich aber sicher auch mal noch die Tage irgendwie testen wenn ich einen freien Moment dafür finde.


Das was du vorhast, könnte etwas knifflig werden oder sogar unmöglich sein...
Du willst den Backend Server mit LetsEncrypt verschlüsseln? Was genau willst du damit bezwecken? Normalerweise ist ja nun das schöne an dem HAProxy, dass er dir die ganzen "Sorgen" mit Letsencrypt und dem Reverse Proxy abnimmt. Somit braucht es deinen Server nicht mehr kümmern ob das Zertifikat gültig ist oder nicht.
Damit dein Server zudem über Letsencrypt ein Zertifikat bekommt, muss er öffentlich mit Port 80 erreichbar sein. Aber genau das wollen wir ja nicht und verstecken deshalb den Server hinter dem HAProxy.


Bei deiner Anleitung für mailcow wird  auch das ssl zertifikat vom HAProxy gegeben. Siehe "ssl crt mailcow.pem". Ich vermute "mailcow.pem" wird das gültige zertifikat sein.
Dieses wird dann vom HAProxy veröffentlicht. Im Backend redet der HAProxy mit mailcow unverschlüsselt über Port 8080. Denn verschlüsselt wäre der Port nur mit 8443 von mailcow.


Was du mir genau mit deiner Frage fragen willst verstehe ich nicht.. vielleicht bin ich aber auch schon zu müde dafür

[wirehire]

Ich bin auch schon zu müde.

Im Endeffekt hast Du trotzdem meine Frage beantwortet.

In der Anleitung sieht man ja das es dann vonhaproxy das ssl benutzt. Und genau wie du es sagst, es ist ja der Vorteil von Haproxy das der Rest halt nicht per ssl extra ist ,sondern sich haproxy zentral darum kümmert.

also muss ich im Endeffekt es genauso einstellen wie du es mir vorhin gezeigt hast für ein neues Backend mailcow.

Teste ich aber erst morgen wenn ich wieder Fit bin

Danke für deine große Hilfe und dem dazulernen!

Ich wünsche dir eine angenehme Nacht!

[superwinni2]

Wenn ich alles beantworte ohne Fragen zu beantworten ist immer ein sehr gutes Zeichen




Wenn du intern unbedingt verschlüsselt kommunizieren willst, mach nen selbst signiertes Zertifikat, richte den BackendServer dementsprechend ein und dann sollte es passen.
ACHTUNG hier kommen noch mehr Funktionen der OPNsense hinzu: (Zertifikatverwaltung)
Wenn du dem nicht ganz vertraust oder sichergehen willst, dass das Zertifikat nicht verändert worden ist, kannst du auch eine Certificate Authority (CA) erstellen. Dann das Zertifikat für deinen Server ausstellen und dort importieren und dann beim Backend auch noch das "Überpüfe Gültigkeit des Zertifikates" aktivieren.


Falls es auch morgen noch Probleme gibt.. Einfach melden

[wirehire]

@superwinni2

ich habe es gerade mal mit einer Testinstalltion ausporobierrt und es läuft super.

Bin den gleichen Weg wie gestern gegangen und konnte damit mailcow erfolgreich zum haproxy hinzufügen!

Vielen Dank!

Werde es nachher dann auf produktiv umstellen.

[superwinni2]

Sehr gut

Wenn man die Logik verstanden hat, ist es ganz einfach

Viel Spaß

Gesendet von meinem LG-H815 mit Tapatalk

[superwinni2]

Hi wirehire


also habe eben mal bei mir nachgeschaut... Ich habe ebenfalls HAProxy mit SSL Backends / Realen Servern am laufen. Dürfte somit kein Problem sein....


Was ich noch sagen/schreiben wollte: Wenn di e Anleitung fertig hast, schau ich gerne mal noch drüber... Habe wie gesagt auch schon probiert eine Anleitung zu schreiben... Ist jedoch nicht ganz so einfach...